phantom

An infinitely better example would be an static-inheritance class giving access to something like the graphics device.

No, that would be another example of a massive design flaw...

Question; why wasn't the first suggestion in this post to break out nSight or something like it to profile precisely what is going on?

So far this thread pretty much seems like a bunch of people trying various forms of voodoo to try and get things working...

(btw, it looks like you are rendering your post passes with a quad; try swapping it for a triangle, it might help your black line problem and would also improve performance every so slightly as you are no longer splitting pixels along the diagonal.)

@phantom:
 
So is this how your entire rendering architecture works, or is it some part put on top of everything? It doesn't seem like a bad idea, but it appears to not being really compatible to my current rendering architecture, which works by submitting a render instance (state changes + sort key + draw call), but I'm not sure...

Ah yes, I should have been a bit more clear about that; we build the same kind of list too and its that which is processed in side the "render each visible model" bit (by 'render' it means 'record these draw calls into a command list to execute on the device later'), this list is just established per unique camera in the world and used with the scenes which require it.

and i'm trying to stick with fixed function for maximum compatibility.

Compatibility with what?
2002 - ATI releases the R300 GPU. No fixed function hardware.
2004 - NV release the NV40. No fixed function hardware.

Heck, everything you've written about being worried about smacks of problems from nearly 10 years ago...

Games tend to have some form of 'particle editor' which allows you to setup various parameters (which might change in a linear fashion or on a curve of some sort) for emitters and then those emitters would be combined together for an 'effect' of some sort.

So a fire + smoke effect might be made up for 3 emitters (fire, smoke, embers) all with varying parameters.

But even at these extremes, it was still hard to tell what was wrong -- it just didn't feel like a 60Hz game (although Fraps will tell you it's rendering at 60Hz). It's only when I record a video of the game at 60Hz and then step through the video frame by frame that it's obvious that every 3rd frame is a duplicate of the one before it.

For various reasons I wouldn't really trust fraps to be telling you the whole truth of what is going on anyway; http://anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps

It is highly likely that the driver will detect this and no actual sampler binding will take place; in fact this is so basic that re-binding a texture will likely cost close to nothing.

It might not cost you GPU time but it WILL cost you CPU time; due to a lack of redundant state checking on texture bindings for a while on our last game (which was targeting 60fps...) we were losing a lot of CPU time each frame due to repeatedly setting the same texture and taking a trip into the driver.
(We, of course, fixed this... and by 'we' I mean 'me'... ;))

Doing redundant work and hoping the driver will 'sort it out' isn't a good plan at all.

A resounding no here as well.

The effort you put into supporting all the other non-game ready formats (be it textures or mesh data) could be directly sunk into a command line tool to convert the source data from the start.

You'll be doing no more 'real work' - infact you'll do less as you won't have to remove it later from the runtime.
You won't get tempted to leave it in 'for now' - because we all know it doesn't work that way in reality
You'll speed up your start up times - data is built rarely, but if you are transcoding on every start up your start up times can/will suffer, certainly in debug mode if you are doing any heavy lifting with containers etc and memory allocations.
You'll simplify your engine code - with 'one way' to get data in you won't have to deal with debugging multiple paths.

This isn't to say you can't have code at runtime to construct small assets, in our new renderer most of our 'test demos' use internally generated vertex data and texture data in lieu of disk based assets. Even the resource system testing demos do that (although they present the data as if it came from disk).

But everything is treated as if it is a 'game ready' format once it hits the engine.

However, note that a nerfarious programmer can still create a "null reference"...

People have pointed this out to me before as an example of why pointers are better than references, to which I normally point out "Yes, and I can always turn up at said programmer's home in the small hours with a pointy stick to help me teach them the error of their ways" ;)

Unfortunately the geometry shader is horrendous when it comes to performance and the general IHV advice is generally "really, don't use it..." - if you are doing a particle system then you'd be better off instancing a single quad or indeed doing the work in the tessellation stages rather than us the geo. shader.

(I've promised people at work that if they use a GS in the shaders the very first thing to happen is I will appear behind them with a flaming sword demanding the reason why they need to use it... )

AMD have GL4.2 support, so while some 4.3 functionality is currently missing there is no reason to only focus on 3.x...

This... is a horrible idea...

You have 3 'button' widgets; you run the code to get the instruction pointer - what makes you think this will be different for each instance, given they are running the same code...

Just use an int and have someone increment it each time you create a control... if you really think 32bit is too small then you could always use a 64bit int..

Apoch has covered design nicely, but I think this is still worth calling out.

But games are complicated. Objects interact with each other and the entire game's state regularly throughout the game. Units collide, one unit attacks another, a building makes units, a unit can create projectiles, and those projectiles can affect a large number of other units, etc. In other words, when programming this, you need a way for one object to be able to affect another object (or the game state itself, possibly by creating other units or projectiles). But it's not just a one-time case; many different units have different affects and interactions, which can result in messy code when trying to make all these possible interactions and events possible.

The bold section, in particular the end, is key to this I feel; a single object in the game is not going to touch the whole game state. Not ever and certainly not directly. This is something you go on to basically say yourself with the list of interactions below and this is a key place to start when thinking about it - each object has a pre-defined interaction with the world. If you were going to make an RTS game, for example, your 'tank' super-object (super-object => collection of parts) isn't suddenly going to be marrying The Hulk any time soon ;)

If we take a closer look at one of the examples you gave, "a building makes units", as a typical factory in an RTS game.
While this might look complicated it isn't really, at the highest level the building does one thing 'creates a unit', at which point beyond throwing out a few notifications it is done.

Its output might simply be a message (in the generic sense, not a 'message system' sense) which says "I've made vehicle <type> at location <here> for <player>". Other systems would be listening for that event and respond accordingly; a player's unit collection might update and the unit spawner might create a new object so it can be rendered.

At which point the messages could ripple further afield (unit collection => UI to display message/icon; spawner to any AI and physics systems to insert it into their world view; and so on) but the key interaction is done.

As to how you expose this... well, there is the erstwhile mentioned 'message system' which you could route all the messages to - however this global routing might not be what you want. Your 'factory' super-object might contain a list of delegates/functions to call when certain events happen and systems 'subscribe' to them or you could abstract the whole thing and come up with a processing graph which represents spawning in data; this would require your super-class still outputs events but the hookup of those input and output pins becomes data driven and potentially modified per level.

The key thing, however, is that each unit has a predetermined level of interaction with the world so it can't mutate all the state itself nor does it have to deal with every possible thing that can happen. Even something as simple as 'collision' isn't really the units problem as it is a problem for the physics under the hood.

The funny thing is with the speed difference between CPUs (and the fact they are out of order monsters) and memory access you are probably better off worrying about your memory layout before worrying about every CPU cycles.

Sure, don't do more work than is required but often data access patterns can make a bigger difference than your instruction count.

But I also know that a lot of games (not sure of the percentage) are developed on the XBox and then ported over (I know Skyrim was, hence it's terrible UI for PC).

Ugh... I hate how this myth persists... in most cases the console and PC games are developed at precisely the same time from the same code base and the same basic asset sets - there is no 'porting' of code going on. In our games ~95% of the code base is the same between platforms and at any point during development you could compile the game for the target platform and it would run.

If the UI is 'bad' it is because it was a design choice made which probably had very little to do with what platforms were being targeted.

I put up with this myth/misunderstanding on gamer forums, because frankly those guys are laughably clueless at times, but it shouldn't be something which persists on a development forum...