My game has a mysterious slow-down issue...

[Snake]

I was wondering, besides big objects and a poor machine, what can cause the game to run slow? The game is at 320x240 resolution.

My game is Castle of Fire - where you run from bridge to dungeon collecting the treasures. If you've played the past versions you'll know what game.

I'm thinking it's my computer because it never slowed down before. The only time it did was when the player was sent back to the beginning after completing all the levels and doing this about 3 or four times. I can understand why this may cause slow-down.
I have taken this aspect out of the game for the new version but now it is running slow again.

It only runs slow during the dungeon rooms and not until about the 5th or 6th dungeon.
Is it possible that scripts from other rooms are still being executed? I haven't heard of this before if so.

I have 1 room with 1 enormous object that is animating (Huge Lava Pit), 1 room with 4 lava pits animating (not really that big, but big enough to tell about I suppose), and 2 rooms with 1 room-sized object being turned on and off.
I should mention though, that these rooms never ran slow before. It seems it is happening way before these rooms are loaded.

Recently I turned the memory back down to default (20mb) and am convinced I need to turn it back up again.

If I choose to split the recource files, should this gain speed? From what I've read, yes, but I figured I'd ask while I'm here.

What else can be making the game run slow?

Like I said, I have a feeling it's my computer (it's been running slow lately), but I was wondering what else it could possibly be?

I have no means of testing this game on a different computer unless I have someone from here test it.

I remember Chris telling me he wanted to take a look at it when it was finished (from when I had posted about this from the last version). If you still want to, Chris, if you have the time, then you are more than welcome.

//--EDIT--//
I just turned the memory back up to 100mb but now the whole game is jittery and skips. There is also a big pause before sending the player to the next room.

Thanks in advance,


--Snake

[GarageGothic]

Are you using any DrawingSurface/RawDraw routines? Do you use DynamicSprites? Are you using any kind of custom made collision detection code? Any 'while' loops in the repeatedly_execute, anything else going on there? Also, what's the color depth of the game?

[Snake]

For the hell of it I just unplugged the internet and that seemed to do the trick until I got to the final black dragon where it slowed down conciderably. Even after the game was reset (putting in highscore) I played quickly again and it was still slow.

GG:
*Nope, no DrawingSurface/RawDraw routines or DynamicSprites.

*I'm using the Pixel perfect collision detection module v1.01.

*The color depth is 16bit - which doesn't nessessarily have to be, I have a few sprites that are transparent (dungeon fireballs) and transparent GUIs (1 during the whole game which displays your lives (miniscule)). I also have several transparent GUIs in the mini game, but I have yet to experience slow-down in that.

*And no while loops.

I have one repeatedly_execute_always() in the global script but it is only used during the mini game and is shut off otherwise.

I forgot to mention before that there are at least 10 animated objects (treasures) in each dungeon scene.


--Snake

[GarageGothic]

Could you please try turning off the pixel perfect detection and use AreThingsOverlapping instead and see if that speeds things up. If you're using the collides-with-anything setting for the collision detection module it could slow things down with that many objects on-screen. If that's the case, it may be possible to do some kind of optimizing, for instance not checking pixel perfect for the treasures. Or sorting the items into an array by y-coordinate so that only those in the player's vicinity will be checked for overlapping (as the treasures aren't moving it shouldn't be necessary to update the array every loop, so you could store characters in a separate array).

Edit: Forgot to ask. Does the game also slow down at the dungeons if you skip directly to the room in question, or does the problem only appear during a playthrough?

[Snake]

I'm glad you asked. It gradually happens during a play through. If I start in any dungeon it's fine. There isn't any dungeon in question. One that was slow before might not be next time, or it might happen earlier.


--Snake

[GarageGothic]

I remember you posted about this problem earlier, and it's annoying that we still haven't found a solution. Do the dungeons come after the minigame? If so, could the repeatedly_execute script from that still be running in the background?

Do you have ANYTHING at all that may accumulate throughout gameplay such as a struct or array filling up?

[Snake]

The mini game is unlockable through Practice Mode. Practice mode is seperate from the actual Castle of Fire game.

I can't remember who it was, but he got through the game 4 times and eventually killed himself to stop playing. He never mentioned anything about the game running slow after a while. If it should have happened to anybody else but me, it should have been him. I'm now more convinced that it's my computer.
This slow-down thing never happened unless you played through (continuously) 3 or 4 times (v1.0 & 1.1). Now it's only a one shot deal, and it's slowing down not even half way through. It doesn't make sence.

The only thing that is continuously running in the background is during the mini game when the player is standing still. I have a counter adding to itself and checking to see if it's past a certain number, if yes, it is reset. If the character is moving, it's reset.
Other than that, no, I have none of those things.

Would you like to test it yourself and see if it slows down at all on your computer?


--Snake

[Pumaman]

Which version of AGS are you using? It's possible there's some sort of memory leak going on that gradually takes effect as you play.

Would it be possible to upload the game along with instructions on how to reproduce the problem, so that I can look into it?

[Snake]

I just finished testing again, and this time (like earlier) the whole game was fine until the fourth (last) Black Dragon. But once I selected "continue" to face the black dragon some more, it was back to normal - no slow-down at all. After dying I started to play again and I noticed the slow-down early on in the game (once I got to the Double Dragons).

Chris:
Yes, I can upload it for you. Do you only want the compiled folder or would you like the whole raw thing (beware though, my scripting is awfully sloppy)?

I'm using AGS v2.72 (Build 2.72.652), btw.


--Snake

[Pumaman]

Just the compiled folder would probably be fine to begin with -- if you could PM me the link that would be great.

Just one question first though -- next time you start experiencing the slowdown, can you try saving the game and seeing if it speeds up afterwards? When you save the game, AGS does some tidying up of memory and it would be interesting to see if that was the cause of your problem.

[Snake]

GG and Chris (if you got my PM):

I tested in the repeated black dragon room with character[1].IsCollidingWithObj....

This in fact seemed to help, but the second time around (after the reset) was still slow.

While testing this I remembered why I wanted Pixel perfect collision for the treasures. They're so hard to get with out it. I found myself circling around and trying numorous times to pick them up.

I was going to try AreThingsOverlapping like you suggested, GG, but it said that it does a quick triangular test. So if the player wasn't actually touching the treasures, they would be collected anyway (it counts the transparent regions). I didn't like this idea and so went with IsColliding.

I will try AreThingsOverlapping as well. I just wanted to give you an update.

Like I told Chris in PM:
The bridges do not seem to slow down at all - it is dungeon specific and is gradual.
Now from further analizing, when starting fresh, the game seems to run fine until I get to the final dragon. After exiting this room and choosing to continue playing, this is where it gets gradually slower. Now, if I choose to restart the game or if I die, once the game restarts and I play again, every dungeon is slower.
So whatever is slowing the game down is still processing. I don't get this aspect because I don't have anything that constantly runs - and especially after the game is reset, why should anything still be running and it still be slow?

If the pixel perfect detection module does have anything to do with it, shouldn't the game speed back up once the treasures are all collected (they're not on the screen anymore)?


--Snake

[GarageGothic]

I never was very fond of IsColliding for generic collision detection due to it's dependency on baselines. What you could do for making the treasures easier to pick up using IsColliding would be to temporarily change their baselines while doing the check to (character.y-treasureobject.Y)/2 and then reset it after the check. This would make the vertical distance at which you can pick up the item twice as big. This assumes that both character and object baselines are 0 by default.

I would like to see your game in action, to see if I could find any pattern in the slowdowns. But I'll wait to ask until CJ has determined if it's an engine issue.

[Snake]

Yes, sounds good to me too.

I have to be honest here. What you have suggested sounds very cool, but sounds a little past my scripting ability as of right now. And what really sucks, is that I'm going to need to do this to every dungeon room. Ergh.

I know that the end result would be good, but I'm just so sick of this damn game


--Snake

[GarageGothic]

It's really a very minor change. If you revert to doing IsColliding checks for testing anyway, just put this around it:

Code: ags

//Replace "treasureobject" with the proper object pointer.
treasureobject.Baseline = (player.y - treasureobject.Y)/2;
if player.IsCollidingWithObject(treasureobject) {
   //Do your stuff, remove the object, add score etc.
   }
treasureobject.Baseline = 0; //only relevant if it will eventually be turned on again

Edit: Hmm, not too sure about the correct calculation of the baseline, it could have weird effects. Perhaps it would be better to:

Code: ags

//Add or subtract a percentage of the object's height. The number "20" I just picked at random. You can always experiment.
int percentageheight = Game.SpriteHeight[treasureobject.Graphic]*20/100;
if (player.y < treasureobject.Y-percentageheight) treasureobject.Baseline = treasureobject.Y-percentageheight; 
else if (player.y > treasureobject.Y+percentageheight) treasureobject.Baseline = treasureobject.Y+percentageheight;
else { //within these coordinates the player is bound to collide with the object. If not for drawing order, we could just set baseline=player.y
   if (player.y>treasureobject.Y) treasureobject.Baseline = player.y-1;
   else treasureobject.Baseline = player.y+1;
   }

Then do IsColliding.

[Pumaman]

Ok, I've investigated the slowdown issue and it seems to be caused by an engine bug with the script managed object pool, which was fixed in AGS 3.0.

If you don't want to upgrade to AGS 3, you might be able to avoid the problem by tweaking the script -- would you care to upload your rep_exec and rep_exec_always functions?

What you're looking for are lines like this that would run every game loop:

lblMyLabel.Text = String.Format("%d", score);

basically, any line that allocates a string but never captures it in a variable. So you could replace this line with:

String scoreString = String.Format("%d", score);
lblMyLabel.Text = scoreString;

if you ensure that you do that for all string allocations that get run repeatedly, it should avoid the issue.

As I say though, this bug is fixed in AGS 3 so if you were to upgrade, you wouldn't need to change any script.

[Snake]

Awesome, Chris, I'll try upgrading it to AGS 3 and see what happens.

I'll be sure to get back to you as soon as I do so,

Thank you once again,

//--EDIT--//
Good News: I upgraded CoF with AGS 3 and played through. I played just like I did in AGS v2.72 and I did not experience any slow-down - great! Seems like that did the trick

Bad News: I can run the game from within the editor, whether it's run with the debugger on or off, but once I try to run the game from the compiled folder I get the following messege:

Could not load sprite set file ACSPRSET.SPR
This means that the file is missing or there is not enough free system memory to load the file.

I tried "upping" the MBs to 100mb in the setup program but I still get this error messege. What's going on? Am I missing something that I need to do fully upgrade the game to AGS 3?


--Snake



--Snake

[Gilbert]

Did you just upgrade to the official V3.0.2?

There's a serious bug just discovered, try using the patch CJ posted, or wait for the official distribution files to be fixed.

[Snake]

Gilb0rto:
Yeah, that's the one.
Thanks for the link, it worked indeed. Thank you!


--Snake