Slow loading
by Jordan Hirsh · in Torque Game Builder · 04/16/2007 (8:34 am) · 3 replies
I'm sure this has been covered before, but I cannot for the life of me find it in the forums. Problem is the editor is loading very very slowly. The first time I open the editor it takes around 8 minutes until I am in the editor. I have 37MB worth of art in the initial data blocks file. There are 37 animated sprites, 14 particle effects, and 15 tile maps.
I would like to make a list of optimization techniques. Techniques for speeding up load times and frame rate. I believe this would be a valuable resource for anyone planning on using TGB.
If you have a technique you like to use please chime in. It could be something as simple as your own art size restrictions to your loop unwrapping techniques.
Jordan
I would like to make a list of optimization techniques. Techniques for speeding up load times and frame rate. I believe this would be a valuable resource for anyone planning on using TGB.
If you have a technique you like to use please chime in. It could be something as simple as your own art size restrictions to your loop unwrapping techniques.
Jordan
#2
When I first started developing my game I really used the engines capabilities as guide lines of proper asset sizes. In retrospect this was not the best way to set my asset size limitations. I used high resolution (512x512) tiles for all of my environment textures. 512 for each frame of animation, etc. What would you suggest as a realistic asset constraint for a standard platformer?
When we plan for a target audience and machine spec how does one know the actual memory footprint? is there a standard formula one could use such as number of art assets * asset memory * uncompressed constant...?
Is 500mb of ram too much for a modern 2d game? What about the low resolution NeoGeo carts that held around 90mb when one increases the resolution from 304x224 to 1024x768 it seems reasonable. I image the NeoGeo used a rather elegant system for loading art assets into memory.
04/16/2007 (10:39 am)
Thanks for the info David, good stuff. Brings up another good topic. When dealing with a high resolution game how does a developer balance load times with modern graphic standards? When I first started developing my game I really used the engines capabilities as guide lines of proper asset sizes. In retrospect this was not the best way to set my asset size limitations. I used high resolution (512x512) tiles for all of my environment textures. 512 for each frame of animation, etc. What would you suggest as a realistic asset constraint for a standard platformer?
When we plan for a target audience and machine spec how does one know the actual memory footprint? is there a standard formula one could use such as number of art assets * asset memory * uncompressed constant...?
Is 500mb of ram too much for a modern 2d game? What about the low resolution NeoGeo carts that held around 90mb when one increases the resolution from 304x224 to 1024x768 it seems reasonable. I image the NeoGeo used a rather elegant system for loading art assets into memory.
#3
As for resolutions, 512x512 tiles in a Platformer seems quite unrealistic and unnecessary ... a Platform usually displays anywhere from 32x32 tiles or more on a single screen ... and your resolution is most certainly not 32x512 in width or height ...
Take your targetted game resolution, for most 2D games ... 800x600 ... for higher res games, 1024x768 ... if your really trying to push the limit, go 12801024 (nothing higher then that, not all monitors can support past that, especially newer wide-screen LCDs for example which have like 1540x1330 resolutions, etc ... and dont like 1600x1200) ... take that, then divide the screen into tiles ... the more tiles you have on the screen, the more you can do with the overall look, and the less artwork you need (ironically, heh) ... take for example ... a side-scrolling platform game ... you can have a simple 32x32 tile size ... and create 10 different 32x32 tiles that represent the ground beneath the player ... with a bit of creativity and some well though out tile making ... you can have an almost non-repeating ground just be re-using the same tiles over and over, in different orders and configurations ...
Even in real life, we see the same thing, repeated over and over ... the floor beneath you is covered with, usually, the same pattern (rug, tiles, etc) over and over ... sometimes changing from room to room, but not always ... almost always done in such a fashion as to be utilized for a specific purpose (rug for softer walking, tile for easier clean or cooler (temperature wise) rooms) ... outside ... the sidewalk is the same, over and over again, some sections have cracks, but in most good situations they all more or less look the same ... the road, in most cases, the same for fairly good distances (miles and miles in some cases, with very few variations [from the large perspective])
Trying to add too much art to a game, in the hopes to make the game more "realistic" ... can actually cause the complete opposite effect ... and is usually not necessary ... People play games because they are fun, not because they look absolutely stellar ... stellar looking games with awesome gameplay go further then ugly games with great gameplay ... but both games go places ...
04/16/2007 (11:48 am)
Jordan, the NeoGeo most certainly did use an elegant system for loading images into memory, it also most likely was aware of quite a few concepts that your PC is not ... the PC understands image data in a very specific way ... the video card expects the data to be in a specific format, otherwise it doesn't work ... or looks bad ... the NeoGeo may have possibly (most likely did) have a custom video card, taylored to the graphic display and the graphic format ... therefore reducing the overall memory footprint dramatically ... we do not have that luxury, since our PC's are designed for general all-around use, not a finite specific purpose such as a NeoGeo ... As for resolutions, 512x512 tiles in a Platformer seems quite unrealistic and unnecessary ... a Platform usually displays anywhere from 32x32 tiles or more on a single screen ... and your resolution is most certainly not 32x512 in width or height ...
Take your targetted game resolution, for most 2D games ... 800x600 ... for higher res games, 1024x768 ... if your really trying to push the limit, go 12801024 (nothing higher then that, not all monitors can support past that, especially newer wide-screen LCDs for example which have like 1540x1330 resolutions, etc ... and dont like 1600x1200) ... take that, then divide the screen into tiles ... the more tiles you have on the screen, the more you can do with the overall look, and the less artwork you need (ironically, heh) ... take for example ... a side-scrolling platform game ... you can have a simple 32x32 tile size ... and create 10 different 32x32 tiles that represent the ground beneath the player ... with a bit of creativity and some well though out tile making ... you can have an almost non-repeating ground just be re-using the same tiles over and over, in different orders and configurations ...
Even in real life, we see the same thing, repeated over and over ... the floor beneath you is covered with, usually, the same pattern (rug, tiles, etc) over and over ... sometimes changing from room to room, but not always ... almost always done in such a fashion as to be utilized for a specific purpose (rug for softer walking, tile for easier clean or cooler (temperature wise) rooms) ... outside ... the sidewalk is the same, over and over again, some sections have cracks, but in most good situations they all more or less look the same ... the road, in most cases, the same for fairly good distances (miles and miles in some cases, with very few variations [from the large perspective])
Trying to add too much art to a game, in the hopes to make the game more "realistic" ... can actually cause the complete opposite effect ... and is usually not necessary ... People play games because they are fun, not because they look absolutely stellar ... stellar looking games with awesome gameplay go further then ugly games with great gameplay ... but both games go places ...
Associate David Higgins
DPHCoders.com
The Level Builder is great for laying things out and designing the overall look of your levels and game in general, but you can not rely on the Level Builder to be intelligent enough to know when to load and when not to load objects, etc ... if you try to load 37mb of JPEGs into the Level Builder ... you have to think to yourself ... 37mb of JPEG's is 37mb of COMPRESSED image data ... which, when uncompressed, consumes a MUCH LARGER amount of memory ... my development machine has 1gb of physical ram ... after trying to load a +100mb set of art resources into Level Builder, TGB_DEBUG.EXE was using OVER 700mb of RAM ... why? Is TGB poorly written? No ... Does TGB do bad things when it loads artwork? Possibly, but I doubt it ... So ... whats the reason? When the image is uncompressed and placed in memory, it has 4 channels RGBA even though JPEG's have no real "A" channel ... it's also uncompressed, which means ... when the JPEG compression algorithm strips a few pixels here and there and replaces them with a simple "these pixels were there" signature ... those smaller signatures no longer exist and the pixels are put back into place ... so a 100k JPEG file ... 512x512 consumes just as much memory as a 250k JPEG at 512x512 ... why? Because ... theres 512x512 pixels ... the fact that the first one used alot of the same colors and compressed to a smaller size is irrelevant ...
So ... to summarize ... in short ... my solution for over coming large art assets is ... split them up ... there's no need to load them all into Level Builder, especially if 10mb here is for Level 1 and 10mb there is for Level 2 ... etc, etc (which in my case, it was). It's also a good idea to remember that, even though it's 2D ... if you have a lot of art assets and are attempting to load them all at once ... whether they are required for your level or not ... you may want to rethink your overall art approach ... 2D games should not require 500mb of RAM :)