Game Development Community

TGB crashing when adding a lot of sprite objects

by Steve D · in Torque Game Builder · 03/02/2009 (6:40 pm) · 20 replies

I have about roughly 200 (maybe 250) static sprite objects added to my project. Once I added the last the editor crashed and won't even load again. The game crashes as well.

I had to delete the static sprite objects to get both the editor and the game to start up. Is there a static sprite limit built into Torque? These assets total about 17 megs in size, low resolution, each one is less then 100k.

And does anyone know a way around it? At the end of the day I'm actually going to need a few thousand static objects but I won't need them all on the same level.

Any suggestions, thoughts or help would be greatly appreciated since this is a pretty serious problem for me.

#1
03/02/2009 (6:54 pm)
I suggest you use tilemaps, it will greatly reduce the amount of objects in your scene and help reduce space taken.
#2
03/02/2009 (6:56 pm)
I don't understand how that would help - I need to control the objects on an individual basis, not paint them as part of a background scene.
#3
03/02/2009 (7:14 pm)
I know I've done tests with thousands before, so it shouldn't be that. Maybe it's video memory, what sort of video card are you running this on, also is anything useful in the console.log.
#4
03/02/2009 (7:27 pm)
Matt I tried on both my laptop (2 gigs of main memory so video memory is shared, geforce 8200, running Vista) and my desktop which has dual nvidia 7600 cards, I think it's a total of 512 video memory, it's running on XP.

I looked at the console.log and the last script file it tried to load is -

Torque Game Builder (v1.7.4) initialized...
Compiling F:/Tae/Tae/game/managed/datablocks.cs...

Datablock.cs is where I had to delete all the sprite objects I created to get the editor and game to work again.
#5
03/02/2009 (7:41 pm)
Also, is there a way to stop TGB from automatically creating scroller images from the sprites I am creating?
#6
03/02/2009 (7:51 pm)
I don't know if this is useful or not but TGB was taking up about 700 megs of RAM before it crashed (while I was adding on the sprite objects). I also noticed that when I added 8 sprite objects, which take up about 60k each on the hard drive, about 50 megs of additional RAM were getting used up.

Is that normal? Are there any settings to check so they don't actually get loaded into memory until used?

Don't mean to be a paid but my game is going to require I have several thousand sprite objects in total (mostly animations in different directions) so I need to know what direction I need to take on this, thanks in advance for any help!
#7
03/03/2009 (7:36 am)
I did some more research to try and figure this out - if anyone can give me some help I would really appreciate it.

My game will have 13 levels in total and each with probably a few hundred static sprites. I just read through some TGB docs and if I'm reading it right, when you create an imagemap and it gets assigned to a sprite or a scroller object, it gets loaded into memory. In the TGB editor when I create a new image map it is automatically creating a sprite and scroller object which I assume is bringing the imagemap into memory. While adding objects using this method I see TGB memory use go up to about 800 megs before it crashes.

In total, counting the animated sprites for each direction, I am probably going to need a few thousand but only a few hundred will be in place on each level. I'm really desperate on trying to find out how do I do this? Do I not place the static sprites in the editor? And load and delete them on a per level basis? The sprites that will actually be in camera view at any given time will only be a few dozen at most.

Matt you said you tested with a few thousand objects before but did you do it differently then how I'm doing it? Is there a way to just create image maps and not load them as sprites in the editor? Is there any other way I can do this, obviously I'm missing something here, there has to be a way! Please help my overloaded brain! :)
#8
03/03/2009 (7:39 am)
If you're only going to need a few hundred per level, why not just arrange them into groups, then load and unload them and get away from the managed datablocks?
#9
03/03/2009 (7:41 am)
Jason, I'm still pretty new to TGB so how would I do that using the TGB editor? Create a script with the image maps and only load it when the level loads?
#10
03/03/2009 (8:41 am)
Steve, you should try to make tilemaps with your same size static sprites, so instead of load maybe 30 images, you will load a single image than then you will split in 30 individual sprites in the editor.
#11
03/03/2009 (8:52 am)
Steve,

I had the same issue, adding in a bunch of animated sprites and then suddenly the editor was crashing. For my crashing, it was because I messed up one of the datablocks, so make sure all your datablocks are setup correctly. Even once I got the editor to load, it was way too slow to be usable. I made a small update to the editor, were I could mark an image map datablock as animation only, which simply tells the editor that I am only going to use those images in animations, so it won't display them in the static sprite section of the editor. This at least made the editor run at a usable pace.

I think the ultimate solution through is going to be updating the editor to handle "level packs". Where I can specify for any particular level which sprites I want to use and have the editor only load those sprites. I haven't started working on that code yet, but I should be getting to it soon. I'll let you know once I have that working.

If Melv happens to drop by this thread, I think working in something similar would be great for the text version. Being able to manage a large number of sprites from within TGB will be most useful I think.
#12
03/03/2009 (9:04 am)
Hi Eric, thanks for the input. I am using the editor to create a new imagemap so I'm not manually touching the datablock code. As I mentioned in my other posts I see the memory usage start jumping up alot as I am adding the sprites sheets. Buuuuutttt, I'm still doing some testing but I think I realized part of the problem. I am using SpriteWorks to turn my 3d models into sprite sheets and I was making 25 images per sprite sheet (the default setting). I think that means that TGB will load 25 seperate images into memory with each spritesheet? If that's a yes, I didn't know that so I think that's why there is so much memory usage when I am adding these sprite sheets.

As far as level packs I agree that would be great to have, is it possible to do that in script? To only load the imageblocks for that particular level? Or is something like that best suited for engine code?
#13
03/03/2009 (10:27 am)
I'm going to attempt to do it script only, which should be possible, I don't think it will be a performance hit or anything so I don't think I will have to go into the code to do it.

I'll keep this thread updated on my progress
#14
03/03/2009 (10:29 am)
oh this has been happening to me to! Just last night whenever i added a new image to the scene, when i tried to save, teh game would crash.
#15
03/03/2009 (10:51 am)
Eric please keep me posted, thanks! I've been toying around with it all day, but one item I'm curious about - If you have level A in the editor, place an object, then switch too level B and delete that object out of the library, it gets deleted from Level A as well. Do you have any quick thoughts on how you would handle that?

I see now that everything gets loaded from the datablock.cs in the managed folder, I think I can understand how to unload and load datablocks based on the level but if it's going to delete it from the game in the editor that I'm not sure about.
#16
03/03/2009 (11:53 am)
The problem is that everything is stored in that single datablocks.cs file, you so only have one of those for the entire game. My current idea, is to update the editor to allow it to understand the concept of level specific datablock.cs files. This way, you can have within that datablock file only the items specific to that level, and removing that item from within the editor will only remove it from that levels datablock file. Then, I'll still have the main datablocks.cs file where you can put common items, like ground textures, trees, etc. in that file and have it available to all your levels.
#17
03/03/2009 (12:52 pm)
Ok I learned a lot today about TGB startup routines and how the editor works.

I just did a quick test of putting several hundred imagemap datablock definitions in a custom datablock.cs file and launched the game and editor just fine and I was able to choose them for a sprite.

What I wasn't aware of when I first posted this is I thought you had to create a imagemap in the editor to place the sprite in the game. According to the Imagemap document, once the imagemap becomes a sprite it gets loaded into memory. Once I had created 50 or so imagemaps (sprites) in the editor that would explain why the memory use shot up and it crashed.

So if anyone cares - I created a few hundred image map datablocks but didn't place them in the /managed/datablock.cs fileThey were still available to use in the editor to define a sprite but just don't show up (and take memory) under the sprite section in the editor.

Thanks for everyone's help, I really do appreciate the time. If my findings change I will post it.
#18
03/17/2009 (12:51 pm)
Hi everyone! I worked with Melv at GG today and he asked me to post the results in the forums.

After adding a lot more sprites to TGB editor it crashed (again). Melv sent me an updated executable for both the actual game application and editor.

My game had a memory footprint of about 550 megs, with the new exe it now has a footprint of 60 megs, huge difference!! This is with nothing preloaded and everything set to auto-unload.

I didn't have TGB Pro so I had to upgrade to get the editor to work but the results are good. It was showing memory usage at about 700 megs or so before the crash and now it's taking up a little more then 200 megs. More importantly it's not crashing so it was well worth it.
#19
03/21/2009 (11:21 am)
are you guys sharing the code modifications or the new exe?... because thats one concern of mine here too... right now my game has a memory footprint of 600+ MBs.
#20
03/21/2009 (1:53 pm)
Michael Perry said he was going to see what iTGB fixes could be released in code form so we can implement them ourselves before the actual release. Some fixes apply to TGB also, so maybe bug him about it next week.