Creating sprites causes hiccups
by Vern Jensen · in Torque Game Builder · 06/08/2009 (7:55 pm) · 58 replies
I've found that creating a sprite and adding it to the sceneGraph is really slow. Enough to cause the creation of even 10 or so to generate a noticeable hiccup on slightly older systems. (i.e. 1 GHz processors) I did some tests with this method:
I added key bindings to call this any time a key was pressed. In one version, I left it as-is, where only *one* sprite is created, but then the code above is called on it 500 times. This was a test to see if executing these lines of script 500 times was what was creating the noticeable slowdown.
In the second version, uncomment the "new t2dStaticSprite" code inside the loop, and change it to loop only *50* times, not 500. This version is *significantly* slower than the other. It creates noticeable lurches in the animation every time I push the key that invokes this function. This is on a 2 GHz dual-core Intel Mac. Only 50 sprites. Even far fewer sprites can create a noticeable lurch in the animation if created at once on a somewhat older computer. (As I mentioned before, even 10 is enough to see the delay.) That's just 5 bullets with glows attached to them. In a shooter, this is a common occurrence. You *need* to be able to create (and delete -- also slow) lots of sprites in a single frame of animation in some instances.
The problem is not script. The problem is "new t2dStaticSprite" -- something internal to the engine is quite slow for this. I have the engine source, and can make mods, but I don't even know where to start. What files should I be looking at to consider trying possible engine-level speed-ups?
function doStarFieldTest()
{
$gMyTestStartTime = getRealTime();
%newSprite = new t2dStaticSprite()
{
scenegraph = gameSceneGraph; // NOTE: This name must be set in Torque's GUI editor!
// class = Asteroid;
imageMap = "star2ImageMap";
layer = $gAsteroidLayer;
size = "0.3 0.3";
};
for (%n = 1; %n < 500; %n++)
{
/*
%newSprite = new t2dStaticSprite()
{
scenegraph = gameSceneGraph; // NOTE: This name must be set in Torque's GUI editor!
imageMap = "star2ImageMap";
layer = $gAsteroidLayer;
size = "0.3 0.3";
};
*/
%newSprite.setLinearVelocity( 0, 15 );
// Set a random location
%xLoc = GetRandomFloat(-70, 70);
%yLoc = GetRandomFloat(-70p, 70);
%newSprite.setPosition( %xLoc, %yLoc );
}
echo(" Time to create 50 stars: " @ (getRealTime() - $gMyTestStartTime));
}I added key bindings to call this any time a key was pressed. In one version, I left it as-is, where only *one* sprite is created, but then the code above is called on it 500 times. This was a test to see if executing these lines of script 500 times was what was creating the noticeable slowdown.
In the second version, uncomment the "new t2dStaticSprite" code inside the loop, and change it to loop only *50* times, not 500. This version is *significantly* slower than the other. It creates noticeable lurches in the animation every time I push the key that invokes this function. This is on a 2 GHz dual-core Intel Mac. Only 50 sprites. Even far fewer sprites can create a noticeable lurch in the animation if created at once on a somewhat older computer. (As I mentioned before, even 10 is enough to see the delay.) That's just 5 bullets with glows attached to them. In a shooter, this is a common occurrence. You *need* to be able to create (and delete -- also slow) lots of sprites in a single frame of animation in some instances.
The problem is not script. The problem is "new t2dStaticSprite" -- something internal to the engine is quite slow for this. I have the engine source, and can make mods, but I don't even know where to start. What files should I be looking at to consider trying possible engine-level speed-ups?
#22
06/10/2009 (4:20 am)
@Ronny: I just sent you the files to the email address in your profile but it bounced back with an invalid DNS error.
#23
06/10/2009 (11:51 am)
Melv, I'd be happy if you would send me code as well. Thanks in advance!
#24
If anyone requests this then please make sure your profile email is correct or just send me an email request to:
melvm (at) garagegames dot com
06/10/2009 (11:56 am)
@Stefan: Same as Ronny. Your profile email seems to be out of date.If anyone requests this then please make sure your profile email is correct or just send me an email request to:
melvm (at) garagegames dot com
#25
06/10/2009 (12:22 pm)
ok... mail sent your way, Melv. hope you get it.
#26
06/10/2009 (12:27 pm)
Same here, sent from a different mail address.
#27
Just wanted to mention that you really should back-up the files before you replace them in case you do have any problems whatsoever.
It is unlikely that I could spend much time trying to help you out at the moment as things are cccrrraaazzzzzzzzzzyyy busy.
I don't think you should have problems but I would ensure that you can run a stock compiled build first before replacing with these files.
The next release of TGB will not suffer from this problem.
Good luck and post your results.
06/10/2009 (12:30 pm)
Files sent.Just wanted to mention that you really should back-up the files before you replace them in case you do have any problems whatsoever.
It is unlikely that I could spend much time trying to help you out at the moment as things are cccrrraaazzzzzzzzzzyyy busy.
I don't think you should have problems but I would ensure that you can run a stock compiled build first before replacing with these files.
The next release of TGB will not suffer from this problem.
Good luck and post your results.
#28
Prior to memory savings (windowed mode):
Insectoid at start-up: 213.19 MB real, 468.91 MB virtual
Playing Asteroid Colony: 198.59 MB, 463.75 MB
After memory savings (windowed mode):
Insectoid at start-up: 117.75 MB real, 362.80 MB virtual
Playing Asteroid Colony: 114.50 MB, 366.57 MB
Great!
I do have a couple-second delay now when using setScreenMode() to change resolutions, but that's a very acceptable trade-off for the memory savings.
The improvement, with practically no tradeoff, is almost too good to be true, Melv. Thanks. :-)
06/10/2009 (12:42 pm)
My game was never a memory hog before (I've trimmed down my texture sizes many times in the past, by doing through the dumpTexture results and analyzing each one), but even so, I like to keep things as efficient as possible. My results:Prior to memory savings (windowed mode):
Insectoid at start-up: 213.19 MB real, 468.91 MB virtual
Playing Asteroid Colony: 198.59 MB, 463.75 MB
After memory savings (windowed mode):
Insectoid at start-up: 117.75 MB real, 362.80 MB virtual
Playing Asteroid Colony: 114.50 MB, 366.57 MB
Great!
I do have a couple-second delay now when using setScreenMode() to change resolutions, but that's a very acceptable trade-off for the memory savings.
The improvement, with practically no tradeoff, is almost too good to be true, Melv. Thanks. :-)
#29
Also (with this fix) you should see considerable memory reduction in the level-builder as well.
06/10/2009 (12:46 pm)
Good stuff. Just wanted to let you know that you won't suffer from image-maps recalculating in the next version of TGB so you'll get low memory consumption and fast video switching.Also (with this fix) you should see considerable memory reduction in the level-builder as well.
#30
06/10/2009 (2:48 pm)
I'm sending you another mail, but the mail address in my account is my active one. I think there has been a DNS issue with one of my providers (domain hosted in Norway, actual webspace and mail servers who knows where). Cheers!
#31
could it possibly be that when you copy the emails from this site that you did not notice the word "null" added to the address (as the reason why they were failing) ?
06/10/2009 (3:16 pm)
A bit on and off topic:could it possibly be that when you copy the emails from this site that you did not notice the word "null" added to the address (as the reason why they were failing) ?
#32
thx once again.
06/10/2009 (3:59 pm)
thx Melv. now i need to instal Visual Studio to recompile this... pretty handy stuff here man.thx once again.
#33
06/10/2009 (11:18 pm)
Melv, did you you get the mail from my other address?
#34
06/11/2009 (12:03 am)
I sent the files in reply to the emails I got so everyone should have them.
#35
06/11/2009 (12:38 am)
Sorry for the confusion Melv, I finally found your mail in a hidden IMAP spam folder :)
#36
Good luck and post your results if you can.
@Vern: I never said sorry for taking this thread *way* off topic! ;)
06/11/2009 (12:53 am)
No problem at all, glad you've got it.Good luck and post your results if you can.
@Vern: I never said sorry for taking this thread *way* off topic! ;)
#37
Virtual memory before: 384 MB
Virtual memory after : 243 MB
That's about 1/3 off - thanks a lot Melv!
06/11/2009 (3:16 am)
Just did some quick tests with our game:Virtual memory before: 384 MB
Virtual memory after : 243 MB
That's about 1/3 off - thanks a lot Melv!
#38
06/11/2009 (1:52 pm)
I would like this fix as well please.
#39
06/12/2009 (12:24 am)
@John: It would help if I had a way to send it to you. ;)
#40
Thanks!
06/15/2009 (7:15 am)
@Melv: I'd really like these files as well, please and thank you! I've got the Pro version of TGB w/source.Thanks!
Torque 3D Owner Ronny Bangsund
Torque Cheerleaders
(Or maybe post a resource so you don't mail them out all day!)