|
After our discussion around eye-candy-effects and where to place stuff i noticed something. Generally you have like a gamecontroller and a menucontroller. but when you place eye-candy stuff in view they aren't associated with a controller anymore. how do you handle memory for this stuff? do you always have everything loaded or do you handle gamestate in model and load/unload stuff in view and model depending on it? it feels like moving stuff into view further complicates things as you now have to control memory in all three parts depending on gamestate and which controller is active instead of it happening automatically when setting a controller active or changing a state in model. |
Submitted by SolidBenny
Sat, 09/12/2009 - 11:37
|
I generally keep everything loaded :)
When it comes to visual assets and sounds, I tend to keep everything in memory at all times. This is completely true for all my games currently on hUb except for UfoPilot II.
UfoPilot II differences:
This has been a really good test project for going from "the old way" to MVC. While porting it from a "gamestate" style architecture I noticed that I removed lots of redundant asset loading in the process.
On the Model side I only have a single map / level loaded at once, so there is a MegaMap* (it's a huge pixel buffer) in Model that gets recreated depending on what level you are running.
On the Controller / View side there is a MegaMapDrawer* that gets renewed per level.
Other than that I think that everything is in memory at all times. This tends to work out fine, running a big map (4 x 4 screens) uses under 40MB of ram.
I agree that if something is only ever used in a single Controller it really has no place in View (since you never reuse it in other Controllers), but on the other hand even my Controllers are also in memory at all times (statically allocated).
I have found that the more stuff you can simply statically allocate, the better. That way you don't have to check and / or worry about pointers being invalid.
/johno
"you can't stop the change"
okay good info thanks. this
okay good info thanks. this probably only works as long as we keep doing these small games but i guess for quite a while memory won't be a problem and its just stupid to try to manage something that doesn't need to be managed. i've dynamically handled everything before and it sucks. since i made the MVC change i've statically created lots of things and it really simplifies a lot.
---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)
Updating view state
another thought regarding this.
the view stuff now needs to be updated and drawn like everything else since it completely controls effects. since there's only a present function in your example in our first thread i wonder if it is normal to also have an update function for the view? it feels malplaced to do that in present
---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)
update / present
These days I tend to do the "updating" in the same function / pass as the "rendering".
For example in Astro-Creeps, the PlayController will call drawExplosions(), and that method will iterate the Explosion instances, calling draw() on each one. Explosion::draw() returns a boolean, and if that is false the Explosion has timed out and the instance is deleted.
PlayController does this call from doOutput(), so that's where the instance management (Explosion objects being deleted) logically happens. However, I guess you could say that this is the "presentation stage", as the call to PlayController::doOutput() is in between a D3D BeginScene() / EndScene() pair.
In Astro-Creeps each controller has pretty exacting control of the number of draw calls (as I'm using a few different fixed function render states for blending). Thing like Explosion will in effect draw to a software vertex buffer, and then the Controller chooses exactly when to render / flush these buffers with the correct rendering settings. So the whole thing is like a small wrapper around D3D Fixed Function and DrawIndexedUserPrimitive().
Personally I would say that the need to "update something" before rendering is just a detail of implementation. hObbE has for example been messing around for a while with stateless particle systems, and in that case I assume he calculates the required data at the same time as he "renders" the particles.
/johno
"you can't stop the change"
i had a feeling that would
i had a feeling that would be your answer. maybe i'm starting to get a feel for this
detailed and clear as always. thanks.
---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)
Post new comment