Jump to content

  • Log In with Google      Sign In   
  • Create Account

Hodgman

Member Since 14 Feb 2007
Offline Last Active Today, 08:49 AM

#5178629 Geometry shader-generated camera-aligned particles seemingly lacking Z writing

Posted by Hodgman on 06 September 2014 - 07:59 PM

Sounds like plain old alpha blending issues - they have to be sorted/drawn back to front. You'd have to sort your particles (using a compute shader, etc) before this billboard pass.
Alternatively you can disable depth-writes, and instead of z-test artifacts, deal with blend order artifacts instead.


#5178431 Very fast 2D frustum culling

Posted by Hodgman on 05 September 2014 - 08:09 PM

You can probably remove the acos (and toDegrees) by keeping all the math in the realm of linear algebra, instead of switching over to trigonometry half way through.

And yes, if implemented correctly, this is a valid approach - treating the camera as an infinitely long cone instead of frustum, and treating your objects as spheres. As above you need to find the solid angle subtended by those spheres. You also want to use the angle from the centre of frustum to one corner - not the angle from centre to top or side.


#5178305 Porting from DirectX9 to DirectX10 questions

Posted by Hodgman on 05 September 2014 - 08:12 AM


That fails silently for me ... All my attempts to recreate the swap chain resulted in the display driver crashing.
Do you check every single HRESULT return value? During devleopment, it's also good to pass the D3D10_CREATE_DEVICE_DEBUG flag when creating your device, which should cause errors to print useful messages too.

1. Swap chains are just for render-targets that you're going to display to the screen. Often you just have one swap chain in the app.

2. Depends how many of the effect features you rely upon. If you use techniques/passes/states/etc and rely on setting all your constants by name, then switching away from Effect might be a lot of work...

3. What does "ruins the device context" mean?

4. DX9 and DX10 support both... bur RGBA is preferred. e.g. in D3D9 D3DDECLTYPE_UBYTE4N was an RGBA vertex format, but D3DDECLTYPE_D3DCOLOR was a special BGRA alternative.




#5178281 Intrinsics to improve performance of interpolation / mix functions

Posted by Hodgman on 05 September 2014 - 06:20 AM

http://www.humus.name/index.php?page=Articles&ID=6

http://www.humus.name/index.php?page=Articles&ID=9


#5178215 How to manage costs to match sales expectations?

Posted by Hodgman on 04 September 2014 - 10:10 PM

How about a situation where the dev studio has the funds to create a game, has created a game, and is looking for a publisher to distribute the game?
So the publisher has paid the dev studio nothing. I would imagine in this game, the publisher will split revenue to the dev right?

They'll probably try to negotiate similar terms, where they'll start splitting the profits with you after their costs have been paid off. If you're not careful, you could end up in the same situation where you never receive a cent in royalties.

 

There's no standard deals. It's all down to the specific contracts that you agree to.

 

There's a bit of a change recently with digital distribution, where many developers are self-publishing -- i.e. selling games to consumers without a traditional publisher at all. From what I hear, it's fairly common in these deals for the middleman (Steam/etc) to take about 30% of the customer's money, with the developer receiving 70%.

Keep in mind that in this kind of deal, you'll also have to pay for your own marketing/advertising/support.




#5178214 GOTO, why are you adverse to using it

Posted by Hodgman on 04 September 2014 - 10:06 PM

IIRC, "goto considered harmful" was authored in the 60's, and made the argument on the comparison between structured and unstructured programming.

 

At the asm level, everything is a goto, so they're obviously not the devil. The argument is that certain uses have a structure -- if/then/else, for/break/do/while, switch, call -- and that this structure makes programs easier to reason about. Without any structure, programs are just spaghetti.

This is obvious at the time, but it was something that actually had to be explained back then -- structured flow control is better than spaghetti. High level flow control patterns are a good thing.

 

Goto usually isn't required in high-level programming because we've formalized all the useful uses of it into flow control keywords already.

 

The main remaining use of it in C is to implement error handling with cleanup -- e.g. when there's multiple exit points in a funciton, but they all need to perform the same series of cleanup tasks to avoid resource leaks.

 

In newer languages, this pattern is available by the use of RAII/destructors/stack-unwinding/finally, so goto isn't required for that particular structure any more either.




#5178208 How to manage costs to match sales expectations?

Posted by Hodgman on 04 September 2014 - 09:51 PM

Yeah, if you're producing a boxed product, you will know what prices are involved. That information is confidential / commercially sensitive, so you're not likely to find accurate info as an outsider.

 

Typically 0% of the money you pay at retail goes on to the pocket of the developer - that's not how things are typically structured tongue.png

The developer will be paid up-front by the publisher to create the game (typically in milestone payments).

The retailers buy each box from the distributor at a wholesale price, and then they increase it to a retail price.

The platform-holder (Sony/etc) take a fixed cut per disc, charged at the time that you print the discs.

The distributor will have a cost to deliver each box to the store, and the rest goes to the publisher.

 

The publisher will then internally do accounting to determine whether those profits have paid off the advertising, marketing, support and development costs.

 

If the developer is lucky, they have a royalty agreement with the publisher. Usually, these agreements state that royalties only begin to be paid after the publisher's initial costs have been repaid. This is where Hollywood accounting comes in. Say the publisher originally paid the developer 10x $1M milestone payments during the development phase, and also spent $10M on advertising. You might think that the developer will begin getting royalties after the publisher has made $20M... but no. The publisher will also add on the costs of their internal publishing, accounting, marketing, social media, financial and quality assurance services. They might claim that these are worth $30M -- who are you to argue. They might also claim that printing and distrubuting the boxed products cost them $5M. Now, the royalties only begin to flow after the publisher has received $55M in profits.

 

So if, just for example we say that 50% of the retail price goes to the publisher, and a game costs $50 at retail, that's $25 to the publisher per sale. You have to sell ($55M / $25 = ) 2.2 million copies before the publisher has "broken even" and received their $55M in profits.

After that point, the royalty contract is active. Say the dev has negotiated to get 25% royalties on each sale. From now on, for each sale, the publisher gets $18.75 and the dev gets $6.25.

 

If the game goes on to sell 3 million copies total, that's a total retail revenue of $50 * 3M = $150M.

However, the dev only gets royalties on (3M - 2M = ) 0.8 million of them, for a total of $5M in royalties, plus the $10M they were paid in advance = $15M revenue for the dev -- which is 10% of the retail revenue.

 

On the other hand, if the game only sells 1 million copies total, then the publisher hasn't "broken even", and the developer gets zero royalties, only getting the $10M they were paid up-front to create the game. In that case, the total retail revenue is $50 * 1M = $50M, so the dev received 20% of the total revenue!

 

As you can see, it's not entirely useful or meaningful to ask what percentage of the retail price goes to the developer ph34r.png




#5177960 DX12 - Documentation / Tutorials?

Posted by Hodgman on 03 September 2014 - 07:12 PM

D3D12 will be the same, except will perform much better (D3D11 deferred context do not actually provide good performance increases in practice... or this is the excuse of AMD and Intel which do not support driver command lists).

Fixed :cool:
AMD support them on Mantle and multiple game console APIs. It's a back end D3D (Microsoft code) issue, forcing a single-thread in the kernel mode driver be responsible for kickoff. The D3D12 presentations have pointed out this flaw themselves.


#5177848 DX12 - Documentation / Tutorials?

Posted by Hodgman on 03 September 2014 - 08:17 AM

It's not going to be out for quite a while, and no one is yet sure whether it will be compatible with older GPUs (feature levels) or older OS's (worse case is Win9+)... so I would definitely recommend learning D3D11 in the meantime biggrin.png

 

D3D9 -> D3D11 jump will be similar to the D3D12 jump, so this will still be a helpful learning exercise for you.

 

In D3D9, you have a lot of render-states, set with SetRenderState / SetSamplerState / etc... In D3D11, these have been replaced with a much smaller set of immutable state objects.

D3D12 will likely go further in the same direction, with an even smaller again set of immutable state objects. 

 

D3D11 is also multi-thread friendly in design (so you can get used to using an 'immediate' and 'deferred' contexts now), whereas D3D9 only provides a single thread/context.

D3D12 will be the same, except will perform much better (D3D11 deferred context do not actually provide good performance increases in practice).

 

The way that you bind resources to shaders will be completely different in D3D12 than in earlier D3D versions... The closest publicly available API at the moment is GL with all the "bindless" extensions...

However, the new D3D12 model of binding resources is more flexible than the current one, which means it's possible to implement D3D9/11 style resource-binding in this new API -- you just have options to do it other ways as well biggrin.png




#5177819 Compile shaders in build time with common functions

Posted by Hodgman on 03 September 2014 - 04:02 AM

The #include command should let you move common code into shared header files, like we do in C/C++.




#5177815 How Does a Noob Start Creating a Simulator?

Posted by Hodgman on 03 September 2014 - 03:22 AM

Sim could be anything from a 3d flight sim including intense physics, to a mil-sim that's basically as complex as an FPS game, a management sim that's basically a 2d isometric game, or a spreadsheet based accountancy simulator!

What kind of sim specifically do you want to create?

 

What have you created before? Sounds like you're completely new to programming? If so, and if your sim has any complexity, you should probably start with pong and other arcade games as practice cool.png




#5177751 COLLADA vs FBX... Are They Worthwhile for Generic Model Formats?

Posted by Hodgman on 02 September 2014 - 05:33 PM

These are just some of the reasons we created the Open Game Engine Exchange format (OpenGEX):
http://opengex.org/

Interesting. Can you save the file as binary? That would be an important feature.
For an interchange format it's not really that important -- games don't use Collada/FBX/ogex files directly, so they don't have to be optimized for loading. You should always convert from your interchange formats to a binary format that's optimal for your specific engine.

It might be interesting for OpenGEX to additionally define a game-ready binary format that's useful for 90% of devs though :)

When I started using Collada I was worried about simple 1MB models being stored as 60MB of text/xml... But it seems to work fine as all the decent repository systems compress text files before storage/sync anyway.


#5177746 For-loop-insanity

Posted by Hodgman on 02 September 2014 - 05:06 PM

Why would one redefine the language like that? Too much to type? It is almost like you need to learn a new language inside the language you already know, lol... Unless I completely missed a point.

What do you mean? Everyone I know codes in Better C!


#5177737 Culling out-of-frustum models that contribute shadows

Posted by Hodgman on 02 September 2014 - 03:59 PM

Lots of engines seem to test all the frustra at once, storing the results in a bitmask per entity --
E.g.
For each model
  Model.visible = 0
  For each frustum, i=index
    If model in frustum
      Model.visible |= 1<<i
Unless you're doing a huge number, say 100k, of these tests, it should run fine without any acceleration structures :)


#5177733 COLLADA vs FBX... Are They Worthwhile for Generic Model Formats?

Posted by Hodgman on 02 September 2014 - 03:47 PM

Especially considering there is a straightforward ISO standard for the format you can know what to expect. Anything that doesn't conform to the standard is a bug. 

What do you do when you come across these bugs? Report them to Autodesk and then hold your breath for 5 years? :D :lol:




PARTNERS