When it comes to creating a graphics engine (opengl or Directx), should I load all my models and textures at the very beginning of the game, or only load and unload them when they are needed?
I'm not sure how professional game companies do it, but I want to make sure that I do it right.
What if I have a gigabyte worth of data to load? Even if it was 64 bit, would it be ok for me to load all the resources, or would that be bad for my ram?
I'm not familiar with openGL or DirectX just yet, as I'm a newbie like you. But what I know is that a program is a set of processes that you want to keep to an absolute minimum at all times. You don't wanna use unnecessary processing power in redundant areas when you can instead use that same power on something else that makes more sense. As long as you can get the information easily from the library, there's no reason why it should be stored in memory when it's not used.
For huge multi-threaded programs, this becomes especially important because you're already running several processes at once. It becomes easier to crash the program for having run too many processes simultaneously. So in general, everything should be rendered and called upon when needed. For instance, in a voxel-world game like Minecraft, Castle Story or Cubeworld, only the textures on the cube sides that are actually visible to the player, are rendered (afaik). All resources are (or should be) treated this way, afaik. It should be there when you need it and not when you don't. If you render all six sides of 29 million blocks (which is a full 360* Far Distance world of Minecraft), that gonna take some serious resources. Especially when each side consists of 16x16 pixels (a whopping 7.4 billion pixels rendered per tick).
If any of you Pros could mention any inaccuracies of my reply or otherwise situation where this minimization is not as important, relevant or even the best method, please comment. I'm curious myself as to the details of this.
Do we speak of loading from mass storage to main memory, or from main memory to video memory? Do we speak of a general game engine (as "engine" usually is understood) or of an engine dedicated to a specific game or at least genre? Do we speak of a game with levels or other breakpoints? Do we speak of PCs or other platforms? Do we speak of a game with very large resources, e.g. virtually indefinite terrain? Is the path through the game world fixed, reverse walkable, or is there an open world? What kind of mass storage the resources are eventually to load from? ...
Obviously, there cannot be a yes / no answer to the OP. Even if all of the above issues are answered, I probably would still reply "it depends". My solution to this problem looks generally like so:
* dedicated loading / unloading for specific resource kinds (e.g. streaming for terrain in seamless large worlds)
* for all other resource kinds: loading / unloading by triggering, chosen by the designer: on game start/end, on level N start/end, on demand, ... (where "demand" may include scripted request and in-game triggers)
* also, the designer may choose whether a resource is managed by a LRU cache
When it comes to creating a graphics engine (opengl or Directx), should I load all my models and textures at the very beginning of the game, or only load and unload them when they are needed?If you are talking specifically about a game/graphics engine like unity, ogre3d etc., and not a game itself, I'd rather leave room for the user of this engine to implement a resource management that fits his needs. Though I don't know how said professional engines handle this, I'm sure there is at least some room for managing the resources as needed, since different games need different solutions. For a small game like a pong clone, you are best to load all resources on startup. For something like Minecraft and World of Warcraft, you need dynamic loading and streaming. A tower defense game might load on level startup all resources the level might need.
From my own experience, I can add this: Start as simplistic as possible, in your case, indeed load everything on startup. Move to more advanced techniques later on when it becomes necessary, if you feel it the old system doesn't fit your current developement stage anymore, or if you simply want to improve on your knowledge about resource handling.
generally speaking, its usually considered desirable to just have one load at program start, vs multiple loading screens in-game.
if load times are long, streaming may be a strategy to reduce the amount of time to load enough to get the player started, and load the rest while they start playing. you'd load just enough to get things going as fast as you could (binary uncompressed). then you'd stream the rest.
if in-game load times are short, they can be considered acceptable.
if you're building a generic engine you'd want to support all methods:
1. load at program start
2. multiple loads in-game
3. streaming
and make it so you could mix and match and use any combo you wanted for anything.
to do this you're basically implementing two types of loading: fast foreground loading, and slower background loading. load at program start and in-game loading use foreground loading. streaming uses background loading.
You need some items immediately. You must show the user something when the game loads up. You need to load some resources to display your menus, play the clicks as they navigate the UI, change the options, and otherwise manipulate the game's front end.
So yes, you need to load at least a few items immediately. I recommend you keep those items to a minimum.
How you manage resources is up to you. You might load resources in bulk at the beginning of a level. You might stream them in as needed during gameplay (this is harder but is necessary for some games). Or you might choose to load every resource for the entire game during the initial load; it may anger your users to have a very long splash screen, but it is a choice you can make.
Ah, I was thinking of using streaming, but wasn't sure how to do it. Do you mean stream as in on a single thread?
If you can *fit* everything in memory without causing the system to start paging to the harddrive about it, then load everything at the start.
If everything that needs to go into GPU memory will fit too, then load it in at the start as well.
Otherwise, load only relevant assets at relevant times - typically based on a per-level/map setup.
This is taken to the extreme with id Tech5, constantly refreshing the textures present in GPU memory based on where in the game the player is at any given moment - virtual texturing / megatexture... The point of that is to allow the game to have extremely high resolution unique texturing everywhere, which will definitely NOT fit into any memory anywhere, and must rely on a streaming system.
If your game is a tiny 2D side-scrolling type game, or an isometric RTS, I'm sure that even a mobile device could safely load everything at program start and have no problems. I would always keep any level/map loaded only when it is the current one being played on, though.
