Weird preload-related speed problem
by Vern Jensen · in Torque Game Builder · 07/05/2008 (11:21 am) · 0 replies
I just discovered a new problem in my space game that didn't exist before: when I push left or right to move the player's ship, it now has a noticeable (esp. on old computers) pause in the entire animation. Two pauses to be exact: one when the ship switches to its "turning left" animation, and another when it finishes that, and switches to its "turning left loop" animation.
After a bit of tinkering around, I discovered this does NOT happen if the ship's "preload" option is turned on for the imageMap. I had turned preload off and turned "Allow unload on", since I have 4 different ships the player can choose from, and I figured it's best for the game to have only one ship around at a time if it needs the extra RAM.
My game does have a fairly large number of art assets, but for most of the bigger ones (i.e. 512x512 background images), which aren't used every scene, "preload" is turned off, and "Allow unload" is turned on.
So this brings me to a new question: why does turning preload on my player's ship eliminate the HUGE pauses I get on older computers, and still very noticeable pauses on modern (2.0 GHz dual-core) computers? Or a better question would be: why is it pausing when preload is turned off?
I can think of two possibilities:
A) There is a shortage of texture VRAM, and without preload, the ship is getting lower priority for what gets put on the graphics card. Other textures are getting uploaded first, and so by the time the game tries to load other "optional" assets that aren't marked as preloaded, it must swap something else out of VRAM first, in order to fit the new item.
B) One other piece of info: I have a fairly complex "title screen" with a number of large sprites. But these are all marked with preload OFF and allow unload ON. I've assumed Torque would get rid of them when it comes time to play the game and more VRAM is needed, but apparently I may be wrong. It seems that perhaps Torque cannot differentiate between a non-preloaded sprite that is currently being used in the animation, versus one that was used in a previous scene and is no longer needed. And so the former sprite, which is currently being used, keeps getting swapped in and out of VRAM constantly.
I'm not sure A is a reasonable possibility however, since when I switch from full-screen (1280x1680) to windowed mode (600x800) the problem still happens if preload is turned off for the current ship. This leads me to believe the problem is not a shortage of VRAM.
Another interesting thing is that ALL frames for the player's ship are in a single imageMap, which if I dump for debugging purposes, is all on one texture. So how then would changing from an animation using a set of 4 or so "straight" frames to a different animation using a different set of 5 or so "turning" frames cause a problem? Doesn't the whole texture have to be on the card if any of it is on the card? If so, why does turning on Preload improve things so dramatically?
It may sound like I am making a huge deal about nothing, but in reality, I think this problem is the cause of probably ALL the slowdown issues I've been having with my game! And it's something I've only just realized what the "cause" is -- a simple checkbox.
[A little bit of background: in the past, I've realized that creating a couple dozen sprites at once caused major slowdown on older computers. So I tried implementing a "caching" system where I just removed a sprite from the sceneGraph when it was done, and added it back when I wanted a new one, but that turned out to not help hardly at all. But with this new discovery, it's obvious: just turning on "preload" for those objects will most likely solve the problem I was having!]
If anyone can shed any light into what is going on under the hood in the Torque engine, to explain why Preload has such a dramatic effect... it will be much appreciated! It may help me with other slowdown issues I've had with the game.
BTW, these problems happen on systems with plenty of RAM: 1 GB and 2 GB.
After a bit of tinkering around, I discovered this does NOT happen if the ship's "preload" option is turned on for the imageMap. I had turned preload off and turned "Allow unload on", since I have 4 different ships the player can choose from, and I figured it's best for the game to have only one ship around at a time if it needs the extra RAM.
My game does have a fairly large number of art assets, but for most of the bigger ones (i.e. 512x512 background images), which aren't used every scene, "preload" is turned off, and "Allow unload" is turned on.
So this brings me to a new question: why does turning preload on my player's ship eliminate the HUGE pauses I get on older computers, and still very noticeable pauses on modern (2.0 GHz dual-core) computers? Or a better question would be: why is it pausing when preload is turned off?
I can think of two possibilities:
A) There is a shortage of texture VRAM, and without preload, the ship is getting lower priority for what gets put on the graphics card. Other textures are getting uploaded first, and so by the time the game tries to load other "optional" assets that aren't marked as preloaded, it must swap something else out of VRAM first, in order to fit the new item.
B) One other piece of info: I have a fairly complex "title screen" with a number of large sprites. But these are all marked with preload OFF and allow unload ON. I've assumed Torque would get rid of them when it comes time to play the game and more VRAM is needed, but apparently I may be wrong. It seems that perhaps Torque cannot differentiate between a non-preloaded sprite that is currently being used in the animation, versus one that was used in a previous scene and is no longer needed. And so the former sprite, which is currently being used, keeps getting swapped in and out of VRAM constantly.
I'm not sure A is a reasonable possibility however, since when I switch from full-screen (1280x1680) to windowed mode (600x800) the problem still happens if preload is turned off for the current ship. This leads me to believe the problem is not a shortage of VRAM.
Another interesting thing is that ALL frames for the player's ship are in a single imageMap, which if I dump for debugging purposes, is all on one texture. So how then would changing from an animation using a set of 4 or so "straight" frames to a different animation using a different set of 5 or so "turning" frames cause a problem? Doesn't the whole texture have to be on the card if any of it is on the card? If so, why does turning on Preload improve things so dramatically?
It may sound like I am making a huge deal about nothing, but in reality, I think this problem is the cause of probably ALL the slowdown issues I've been having with my game! And it's something I've only just realized what the "cause" is -- a simple checkbox.
[A little bit of background: in the past, I've realized that creating a couple dozen sprites at once caused major slowdown on older computers. So I tried implementing a "caching" system where I just removed a sprite from the sceneGraph when it was done, and added it back when I wanted a new one, but that turned out to not help hardly at all. But with this new discovery, it's obvious: just turning on "preload" for those objects will most likely solve the problem I was having!]
If anyone can shed any light into what is going on under the hood in the Torque engine, to explain why Preload has such a dramatic effect... it will be much appreciated! It may help me with other slowdown issues I've had with the game.
BTW, these problems happen on systems with plenty of RAM: 1 GB and 2 GB.
