I ahave made a basic engine for my new game - not yet announced - and when running it the debgger tells me that there is currently 86MB of memory being used!! Is this extravagant?
My engine consists of 2 actives so far the first being the camera and the second being a red 32832 square. my frame is 4800*4200 and the window is 800*600. any ideas how i can reduce it as i plan to have somewhere in the region of 60+ actives all doing their own thing all over the frame.
Yes! My project runs at 28mb after optimisation. 86mb! Jeez!
I say you should pinpoint where that memory is going. Try putting the engine into a smaller frame, remove all backdrop objects. If you're using groups in your engine then try shutting them off one by one until you notice any memory improvement.
like i said it is a VERY basic engine. 1 group to control the frame scrolling and only 5 events in that. that is all the code there is.
NVM - i removed the backdrop and it dropped to 9MB. problem is i don't want to have to manually drag and drop 32*32 tiles into my frame to create the level that would work out at some stupid number of tiles. how else can i create my level?
If you have a project that loads all of its data externally, it tends to be dramatically smaller, whereas if you use the built-in architecture for MMF it will be incredibly large, inefficient, and impossible to mod. For example, some popular click games (not to name names) that have rather basic coding but good and large art, will have gigantic filesizes such as 50mb or so, which is a huge turnoff to popularizing your game, since its more difficult to host, and less people are willing to download a large file.
Meanwhile, if you instead make your game from the ground up using an engine that loads level data from say .INI files or arrays, you will find you might reduce your filesize to less then 5% of what it otherwise would have been. For example, my current project gridquest runs in a single frame engine that takes 5mb, but has about 80 fullsized areas that are loaded from .INI files. That way each level takes only about 20kb instead of 5mb each; if I needed to copy/paste the game code for every level, it could easily have exceeded 100mb in size.
The easiest to happen upon pitfalls and problems you'll encounter that bloat your filesize like that are one of two things usually:
A) Large active objects and such graphics
B) Poorly compressed sounds
If your engine is running on 800*600 size active objects, that means that the animations for each object take up a ridiculous amount of memory to store. Instead its incredibly more efficient to use programming tricks to simulate this. Try to absolutely avoid using large backdrops, and instead use "Quick Backdrop" objects instead, even if it looks a little worse. Even if all your is is a repeating set of 32x32 tiles, if you store each of them as a seperate backdrop object, that means the game has to store information for EVERY single pixel across your entire 4800x4200 map.
Say you are running in 16 million colors mode. You have 4800x4200 pixels each saved by location. Thats 20160000 pixels. Assuming each pixel takes 24 bits for its color (rough approximation), thats 59 megabytes of information for your BACKGROUND alone, not even counting your actual game.
Also, check the size of sound effects before you add them to your game. You should be able to use the built-in sound editor with TGF to change the compression format of .wav files; if you encounter a 400kb file in PCM 48KHZ/16BIT/Stereo compression, running at 187kb/second, you might be able to convert it into a 8/8/mono filetype, reducing the file size from 400 kb to 15 kb.
Events take up more than you might think too, so having multiple frames with the same events starts to make your game much bigger than it should be,
also it's more of a chore to make changes to them with one frame per level...
Yes, copy/pasting your events between frames is both inefficient and timeconsuming; all serious projects should really be engine based. But events don't take up all that much space; I've got something in the realm of 2500-3000 in a single frame and all the memory used is 706kb, compared to some 2500 sounds and 2500 graphics
~ I really like the idea of being able to just get a big fat backdrop object about 2000*2000 and draw in the level so you know there are no "bad" collisions.
Then gettin a new layer and puting all your tileset/graphics on top.
Remember though, if your gona do that any "blank space" that the player cant get to has got to be nothingness (transparent) so you useing the least amount of pixels as possible.
So id go around with the line tool making a 4 pixel line whereever the player can touch.
OR (filterd)
You could make loadsa little backdrops wich are just peices of floor and walls and slopes. which is great! But i seem to loose on level design that way.
yeah thanks for your post! it makes me feel more serius about the amount of data consumtion im useing!
Originally Posted by Zephni ~ I really like the idea of being able to just get a big fat backdrop object about 2000*2000 and draw in the level so you know there are no "bad" collisions.
Then gettin a new layer and puting all your tileset/graphics on top.
Remember though, if your gona do that any "blank space" that the player cant get to has got to be nothingness (transparent) so you useing the least amount of pixels as possible.
So id go around with the line tool making a 4 pixel line whereever the player can touch.
NO! a 2000x2000 bitmap, even with a lot of blank data, will still take up way too much memory. Whenever possible you should use tiles - just like in professional development (except then you can dynamically unload and load tiles into memory).
Tiles are way faster to work with anyway... Unless your level was hand painted Braid style, then you'd have too many unique tiles anyway.
EDIT: Also, that's just silly to make a 4 pixel line... You should just make a 1px line and have an engine that can get out of walls or not get into them in the first place.
I agree with what's been said already - tiles are the way to go. You'll need to make a level editor aswell obviously, but that's actually pretty straightforward. I did write a whole article on why tiles are so great ("Tile Based Games" - unfortunately all the images and examples are currently down, so I'll look into fixing that soon), but in a nutshell;
* Smaller filesizes - more people will download your game.
* Uses less memory - may run faster, especially if scrolling.
* Quicker - actually shortens development time in large projects.
* Map Editor - allows players to create their own levels.
* External Map Files - allows release of addons and sharing of player created content at a later date.
Originally Posted by Sketchy I agree with what's been said already - tiles are the way to go. You'll need to make a level editor aswell obviously, but that's actually pretty straightforward. I did write a whole article on why tiles are so great ("Tile Based Games" - unfortunately all the images and examples are currently down, so I'll look into fixing that soon), but in a nutshell;
* Smaller filesizes - more people will download your game.
* Uses less memory - may run faster, especially if scrolling.
* Quicker - actually shortens development time in large projects.
* Map Editor - allows players to create their own levels.
* External Map Files - allows release of addons and sharing of player created content at a later date.
The only downside to an editor is making it, in my opinion. If CT added the ability to create objects from expressions though the work would be much less - I might look into make a general purpose level editor/loader example.
Advertisement
Post Reply
Is this extravagant?
Edited by the Author.
