Its rather hard to exclusively use the stack for everything, for example if you have even a basic kind of resource manager(especially if its loading a lot of data) it has to be able to control the lifetime of objects, even if you know the size of everything ahead of time you don't necessarily know how many of the thing you want. Anytime you're using a container class like vector even you're already working with heap memory, since vector has to be able to allocate as much space as it needs when it needs to resize.
for this sort of thing, i'll use a static array of structs that is "big enough". in turn, member variables of the structs will be d3dpointers to d3d resources allocated on the heap.
some examples:
(i'll be nesting code in my reply, and code blocks don't work when i do that, so code is in blue, not a code block)
mesh database:
-----------------------------
#define maxmeshes 400
struct Zmesh
{
IDirect3DVertexBuffer9 *vb;
IDirect3DIndexBuffer9 *ib;
int numverts,numfaces;
};
// meshDB record
struct meshrec
{
char name[100];
//LPD3DXMESH mesh;
Zmesh mesh2;
};
// mesh DB
extern meshrec mesh[maxmeshes];
originally, a meshrec was a name and a d3dxmesh object pointer. i later replaced the d3dxmesh with the Zmesh struct, which contained just what i needed out of the d3dxmesh. meshes are loaded as d3dxmeshes, then their vb's, ib's, etc are copied to a Zmesh struct, and the d3dxmeshes are discarded. so they're just a handly file format (.x) for loading meshes basically.
max meshes is set to 400. caveman currently uses 321 meshes.
texture database:
---------------------------------------
#define Zmaxtextures 400
struct Ztexrec
{
char name[100];
LPDIRECT3DTEXTURE9 tex;
int w,h;
};
extern Ztexrec Ztex[Zmaxtextures];
maxtextures is 400, caveman currently uses 386 textures.
other brief examples:
-------------------------------
models database: max_models=200, caveman currently uses 171.
animations database: max_animations=200, caveman currently uses 165.
wavs database: max_wavs=300, caveman currently uses 200.
render queue: 5000 total entries max. render queue index: 400 textures by 5000 meshes per texture max. total entries is small as no single pass makes more than 5000 draw calls.
I'm not sure its fair to same a game like Braid actually should be boasting that it uses a ton of dynamic memory or something
agreed, lots of runtime allocation and dealloaction tends to be a bad thing (overhead, error prone, etc). thus my question, as it seems folks do it a lot more than i do.
I've watched the person you're talking about before and to be honest hes a bit of an essentric with a lot of his theories about games and programming sometimes
so i've heard, yet much (other than the memory stuff) rings so true...
as i said, i'm only half way though the second video, so i'll reserve my judgement call as to whether he's full of it or not until the end. but frankly at this point, i'm no longer watching it so much for the "new game language stuff" as i am for the things he mentions in relation to that, such as factorability (as opposed to re-factorabiity), the concept of friction free programming, the large number of observations about the pitfalls and short comings of conventional methods made by him and others such as Carmack, and the evolutionary nature of game software (IE the fact that games constantly evolve ad change over time due to the fact that almost none are pure clones and therefore are technically a new program that's never been done before, thus usually requiring some experimentation).
In terms of AAA games and large engines you get into completely different territory, in that case the number of resources spirals to ridiculous levels really quickly
so there, you need to load and discard resources in real time. and that means memory use. and i take it that dynamic is seen as a simpler way to make sure data structures are always "big enough"? although there's really no reason static couldn't be used, or one of the methods mentioned above by Haegarr.
