SetImageMap too slow when running TGB with no editors

#1 Argiris ... is the image map already in memory when you call this function ...

When you are running the editor, the image map is already is memory when the play test starts (this is not true with 1.5 Beta though, I think)

It is possible that the 'many seconds' you are experiencing is actually the loading of the Image Maps into memory as your datablocks.cs is parsed when the engine starts ... when you start TGB with Editors it reads this datablocks.cs to build the list of thumbnails for your Create tab ... this is usually overlooked and not considered a performance issue because your running with the editor ... many people fail to put into consideration that the Editor is just a series of GUI controls that are placed on the screen and that the project you have loaded is 'loaded' when the editor starts ...

So ... what I would suggest is ... first ... time the difference between starting TGB with an empty project and with your project ... is there a 'many seconds' difference?

Second ... I would suggest put an echo("Start: " @ getSimTime()); before the setImageMap and an echo("End: " @ getSimTime()); after the setImageMap ... wrap the calls you think are performance heavy with these echo statements (make them 'error' statements to highlight them better) and then subtract the difference ...

Start Time is 1000
End Time is 1000
There's a 1 second difference between the beginning of the call and the end of the call ... in a game, 1 second is a major choke ...

Start Time is 1010
End Time is 1013

There's 3 milliseconds of difference ... for a setImageMap call, this seems adequate ... although, it probably runs a lot faster then that ... I believe all that setImageMap does is change a pointer reference in the t2dSceneObject to point to a new Image Map ... if I remember correctly, Scene Objects don't hold an actual copy of the texture data (the imagemap) within them ... but rather just a pointer reference to the 't2dImageMapDataBlock' data ...


Perform these quick and easy debug steps, and report back ... then we can track down your overhead ...

#2 Hi David.

Thank you for your reply. We tried some things and it seems to work much faster now.

Is there an article or something on common optimizations on TGB games?

#3 Argiris, not to my knowledge ... but general programming techniques apply to TGB ... most 'how to optimize your code' articles that are not language specific apply.

But hey ... optimizing your game code ... sounds like a perfect TDN article ;)

#4 Graphics optimation parts:

1. Square power of 2 are the fastest, even to ultra high GPUs. On bad GPUs they are a must, not optional, as you lose much power. Don't know if TGB takes care of the square (it does of the power of 2)

2. The smaller the image, the better for the bandwidth

3. Try to reduce overdraw. particles with large images are one of the worst causes of massive slowdowns for example. With the overdraw caused by that you can even kill GF8 GPUs. Either many particles or large particles, but not both.

4. Manually force to load and unload graphics at level start and end. That way you don't risk that stuff is loaded / unloaded during the level which can cause some "funny" and highly undesired slowdowns.

#5 Marc, when you're referring to dimensions being the square power of 2, do you mean that an image of 225x193 should be made into 256x256 for optimized results?

#6 Actually, an image of 225x193 will be made into 256x256 for you. More importantly, an image (for example) of 225x270 will be turned into an image of 256x512, with all the "wasted space" that entails.

The reason is that many video cards will only accept textures that are powers of 2, but TGB allows you to use whatever you want. The way it does this is by expanding up to the next power of 2 in each dimension.

What Marc is describing are artist/developer optimizations based on knowledge of both the video card capabilities and what TGB does "under the sheets".

#7 Marc,

How do you do #4 from your list? (Manually force unloading of graphics at the end of a level? And force loading of the new level's graphics?)

-Vern