Question about what's loaded

#1 Eric, yes -- by default, they are ... the 'allow unload' and 'preload' options are supposed to help reduce the amount of memory consumption required by art assets that aren't yet being used ... however, I've run into issues where this didn't work out the way I wanted it too ... so what I do is actually use my own custom 'level' format, which loads all the required assets for the level, and stores a reference to the datablocks in a SimSet ... and when I end the level, I simply go through the SimSet of loaded datablocks and delete them (which unloads them for freeing up memory)

I'm working on a 2D side scroller that has ... oh ... I dunno ... roughly over 100mb of art work (were working on trimming the artwork done, but currently all the levels are designed in Level Builder and all the artwork is added to the datablocks.cs in the managed folder of the game -- takes me like 10 minutes to load the project in TGB)

So yeah ... I use a custom level format, the above mentioned 5-10 minute load time ... is now 1-5 seconds ... and to load a complete level ... which, as it is currently, comes in around 10-12mb of mixed JPEG, PNG and DTS Shapes ... takes about 1-4s (Depending on how fast my HDD responds)

I personally believe this is one of the major 'gotchas' with TGB, especially with art heavy games ...

it's easy enough though, to manage all of this through script though ... just makes designing in level builder a bit more complicated ... :)

#2 Yea, this is depressing. Why should my Pine trees, waterfalls, snowy pine trees, snow patches, bridges, different types of roads, castles, valcanos, boats, etc all be loaded on level 1 which is an island that only requires about 1/10th of the graphics??

and that's not to mention the characters. all are loaded into level 1 but you only see two or three of them.

Why? jeesh...

So what is pre-load? if its all loaded why would I need to pre-load things?

Man... so my other big concern is the maps. I have like 30 maps. ALL of those maps seem to appear in the editor... all of those are loaded as well? What where they thinking when they designed it that way?

EDIT: ACtually each map has multiple layers like underwater map, top level items like fences, and the ground level. So with 30 levels loaded into memory thats actually like 120 maps

hmmm.... what to do...

#3 Layers are not loaded the same way, the Level Builder looks at the tileLayers folder and loads any tile layer it finds in there, same thing with Shapes ...

you can have a quick glance at what is actually being loaded into memory when you game starts by looking at the gamemod/managed/datablocks.cs which is executed prior to the game actually starting, and is in charge of loading all your resources ...

For Tile Layers, layers are only loaded if they are referenced in a new t2dTileLayer() { layerFile = "file.lyr"; } statement ...

so your layers won't be loaded until your layer is loaded ... however, layers are actually the smallest thing in memory ... cause they just make references to all your other artwork ... ;)

and pre-load is, to my knowledge, a way to sort of prevent TGB from loading all these resources at the start of the game, and to only load them when they are asked for ... however, I've not dug into the code for this, nor have I heard it really described or discussed in the docs anywhere that I've read ... so, I don't really know what it's overall intent is for ...

Allow Unload and Preload ... are for resource management control ... not sure if TGB tries to do some 'garbage collection' in the background or not, but if it does ... it's not intelligent enough to know that Snow Pines are not needed in the Desert level ;)

#4 Well it should know that it doesn't snow on a sandy beach!! j/k

ok. So you advise that I always check preload/unload on my graphics and check the gamemod/managed/datablocks.cs . I'll go back and change all those that arent and check it out. Thanks

oh yea,

Quote:however, layers are actually the smallest thing in memory ... cause they just make references to all your other artwork ... ;)

yea my programmer would laugh at me about that... They are only a couple hundred KB. went chicken little for a few minutes there. lol.

#5 Eric -- heh, t2dTileLayer files (lyr) should only really be storing a very small amount of information, the bulk of it is the name of the imageMap, the frame number and the tile X/Y coordinates ... three integers, and a variable length string ... in addition, it also stores the customData field, and the tileActionScript field ... but otherwise, it's a very low memory object ... if you take the entire object ... including all of it's references, it's quite large ... but all of those references are just pointers to the imagemap thats already loaded in memory ... compared to the memory consumed by the imagemap ... the tile layer is, for the most part ... nothing ;)

as for the unload/preload ... I always check unload and uncheck preload ... but like i said, I'm not even really sure if that helps at all ... and when I was faced with +100mb of art resources ... I was forced to create a custom level loader that was able to handle the large number of resources ... we've since cut the +100mb of resources down to around 80mb ... by cropping some unnecessary stuff out, and resizing some stuff (we had some 512x512 images that were resized to around 300x300 ... so we just resized the image file itself ;p)

But hey -- good luck with your resource management, let me know if you come up with anything nifty ... ;)

#6 Oh and yeah I checked my levels are only around 15-20kb not 100, lol.

I only have about 15mb of graphic images not including the huge avi's and music we havent yet loaded. but i guess we should be able to stream that kinda stuff and not keep it loaded.

hmm.. so preload is still mysterious.

Quote:by cropping some unnecessary stuff out, and resizing some stuff (we had some 512x512 images that were resized to around 300x300 ...

I always try to keep my stuff like 32x32, 64x64, 128x128 or 256x128 and what not but it ussually gets chopped into cells that are square as well. I had one image that was not on the same scale as everything, something odd like 172x134 and it looked like it was jittering a bit when it was scrolling, so I fixed it by conforming it to match the standards of the other images by re-rendering out to a different size.

Again, im just a designer/producer so im not really very technical but I'll let you know how we turn out with resource mgmt.

#7 By jittering when scrolling, I assume you mean you used the image as a 'scroller' ... 't2dScroller' ... this is the only time i've seen the 'power of two' requirement being used ... for sprites in general, there is no requirement for them to be a power of 2 ... so ... 37x131 and 32x128 ... doesn't make a difference ... you'll save both disk space and memory if you can crop anything out of your images ... it was pointed out in a fairly recent blog post that TGB doesn't do the greatest job of reducing the memory consumption by 'zeroing out' unused pixels ... can't remember the post, but the poster made modifications to the C++ to optimize the storage of cells in memory so that they were more ... confined ...

I too stick to the power of two (32, 64, 96, 128, 256, etc) for my sprites ... but only during prototyping and simple testing ...

#8 Actually, the requirement for powers of 2 textures is a hardware issue with a very large majority of video cards.

If you do not use power of two textures, TGB actually will inflate them to the next power of 2 in each dimension to ensure they can be uploaded to any video card--which, if you aren't careful, can cause quite a bit of waste.

There is a PDF in your /documentation directory that goes into image/texture management in detail, if you are interested in a more in-depth explanation of all the topics mentioned above.

For more specific details: once the texture is pushed to the video card, a 32x128 texture will still take up 32x128 worth of memory on the video card. However, a 37x131 texture will take up 64x256 worth of texture memory, with the rest padded out to empty space (and not displayed).

EDIT: What the post probably referred to was the concept of using texture sheets, which pack multiple small images into a single texture, and then provide reference points to where in that large texture each image is stored--effectively "filling up" the space that TGB by default makes with an off sized texture.

#9 Stephen ... yeah ... your follow up edit is correct ... the post was referring to sprite sheets (more specifically KEY'd ones I believe) ... and ... thats actually quite interesting ... I did not realize that video cards had that requirement still ... and I had no idea that TGB made that compensation ... I think I have to revisit some things ... ACK!

Soo ... basically ... it's a best practice to ensure that your image is a power of two, and the minimal of the two ... so for a 37x131 image ... it'd be best to try to downsize it to fit into a 32x128 image so it doesn't get bloated out? If I understand your response properly ...


Very educational, as usual ... ;)

so ... probably a dumb question ... but a 150x150 image would be up sized to 256x256?

#10 I would make it 128x128 and slightly scale it up in the editor actually, since it is closer to 128x128 and farther away from 256x256

Actually my post was referring to everything. I keep everything power of two. An apparantly healthy habit that has lingered since my Gameboy/Gameboy Color/Gameboy Advance days.

Quote:EDIT: What the post probably referred to was the concept of using texture sheets, which pack multiple small images into a single texture, and then provide reference points to where in that large texture each image is stored--effectively "filling up" the space that TGB by default makes with an off sized texture.

Who's post? I only make texture sheets when I am making animations. And since my animations are always powers of two I am in the clear.

Quote:By jittering when scrolling, I assume you mean you used the image as a 'scroller' ... 't2dScroller' ... this is the only time i've seen the 'power of two' requirement being used ...

No, when I made a tile map, i wanted to see what the trees looked like on it. So I quickly rendered out one of our trees into an off size .png. Then I just plopped them down and made various scales and such and when the character started trucking accross the map I noticed (very slight but i still caught it) that there was a little jitter with the tree sprites. When it came time to decorate my map with static sprite items that where powers of two I haven't really noticed this.

Quote:If you do not use power of two textures, TGB actually will inflate them to the next power of 2 in each dimension to ensure they can be uploaded to any video card--which, if you aren't careful, can cause quite a bit of waste.

AWESOME! (sorry Higgs) I sort of had a feeling about this. Plus since I am making a tile game, thinking in powers of twos is really kind of standard.

curious... Have you guys ever used iBeta (www.ibeta.com) or someone to test out the system on multiple specs? I am sure you have since you have hardware requirements.. just curious. Shouldnt there be some kind of consumption read-out? Like, I know there are specs as to what system should be the minimum, but it seems like there should be some kind of limit that I can use to gauge where I am at. Perhaps I need to read those mentioned docs.

I have 1 tile layer for Underwater, which basically is everything you see under the water with slopes that lead up to the land.

I have 1 tile layer that I use for the water, but I make that 1 tile and just use repeat x,y bounds. That should be saving me a lot.

I have 1 tile layer that I use for land which takes up the majority of my tiles images.

Then I have 1 tile layer for bridges, fences and walls.

But my tiles are rather large it ends up looking like this:

Underwater: 8 tiles of 128x 128
Water:8 tiles of 128x128 (the water animates)
Land:20 tiles of 128x128
Bridges:16 tiles of 128x128

Thats a lot of 128x128 tiles.

EDIT: eek! thats like 52 very large tiles... but you dont see them all at once. I wonder if I could push it to 64 since you dont always see them on the screen at once.

oh, and we are zoomed in almost 1 to 1 so they dont display more than 6.1x4.8 tiles per layer on the screen at once, but that doesnt matter right? its what is loaded into vid mem right?

#11 Eric, heh ... I scope these forums out for two reasons ... to be helpful where I can, and to learn from what I can ... sometimes what I think is right, is so wrong, it's not even funny ... but I learn from it ... so it's all good :)

I was really surprised to hear about the video card thing ... totally shocked ... now I know, and knowing is half the battle ... G.I. Joe!!!!

Oh and ... the post I was referring to is this, Spritesheets and Video Memory in TGB ... I believe I misplaced some of what I read in there, and generalized it ... ...

Eric ... far as your follow up question ... reducing your tiles from 128x128 to 64x64 will help with memory, BUT, you'll loose quality ... thats a 50% quality decrease ... and 52 tiles really isn't that bad ... especially if you have them in a sprite sheet ... cause I'm pretty sure that 52 128x128 sprites takes up more memory then 1 1024x1024 (8x8 tiles @ 128x128) sheet... with tile sheets, it becomes 'one texture' and only a specified section of the texture is drawn to the screen at the location specified ... from my experience with programming in SDL sheets are both easier to work with, and consume less memory ... cause you don't have the overhead of 51 additional bitmap objects and all the added crap involved with them ... rather ... you have a single bitmap object and just say "I want to draw 256,512,256,768" or whatever ...

But ... I could be wrong about that too ... but I don't think so ... I can't see TGB splitting each cell into it's own bitmap in memory ... that just wouldn't make sense to me ...

#12 Well for what its worth I dont doubt that you have a lot of good info just because you learned something. you've helped me out plenty and are invaluable. but let me please revel in this one time im right a little bit... www.fenslerfilm.com/moviesF/PSAsmall/FenslerFilm_PSA02_small.mpg

oh ok. I see that post now. One thing they (GG) REALLY need to do, is make their sprite system more advance. If you look in my .plan you can see the sprite editor that I designed and had poor Gary Linscott build for me back in 2001.

Basically when we made Earthworm Jim for GBA (and we had to re-make it since Interplay didn't give us any assets) our programmer actually had to make different x,y offsets for each animation frame!! he had to hardcode those offsets. (an offset would be for each frame that has different sizes.) that had to change if we where going to make 4 more GBA games in 3 years so we had to change our methods.

The Sprite Editor for TGB is a little naive. It doesnt think of an animated sprite as an entity. instead it treats it as one animation. Let alone you cant animate different size frames and then have intellegent grouping of those frames into various animations, you cant control the speed per frame, you cant create animated frames via placement that take up virtually no memory since it is just an offset within the animation. They need to spend a little more time with that.

nice catch GG, but too bad your a## got saaaaacked... J/K!!! I am in a play-fool mood today. I love TGB. They did a great job with the link points and stuff and the engine rocks. But there really needs to be a Sprite Editor with more complexity or a seperate entity where you can create a complex sprite and then just import that bad boy and all its animations and frames and what not into the game. but thats a different post.

Quote:But ... I could be wrong about that too ... but I don't think so ... I can't see TGB splitting each cell into it's own bitmap in memory ... that just wouldn't make sense to me ...

Our old system made sheets as well that where loaded into the GBA rom. It did it much like that post, based on the GBA system of sprites being 8x8, 8x16, 16x8, 16x16, 16x32, 32x32, 32x16, 64x32, etc.

edit:we called this sprite compression. basically gary would search out blank areas that still alowed the sprite to be within reach if they where chopped out and then make them into one sheet when it was done, saving each frames bounding boxes. He just contacted me recently as a reference, i could ask him for that old compression algorythm. its quite standard to the kind that packs textures in 3d.

#13 I'll pass this along--some very good ideas, and now that TGB is well established in the 1.xx release, I'm sure the next major version number will contain concepts like this one!

#14 Eric -- good info ... and the video was amusing ;)