GS 0.8.9 Game Engine Memory Leak
smc1979
Member Posts: 48
In testing my game it would crash after you loaded a number of scenes.
I started doing some testing.
Watching the memory growth it was always the game engine. When I did a reset scene it would jump by 5 to 10 mb and never go back down, if I did a change scene instead of a reset the memory only grew by 2mb but still grew and never went back down.
The game engine was in the 60+mb when the game would finally crash.
Reading over the forums I seen that the makers of GS rarely respond it seems, so I am curious if others have seen this.
So in trying to find out what was causing the giant gain in memory I went through everything and tried to clean things up. After I removed a few timers the memory stopped growing so fast. Something with the timers is causing the giant memory leap.
So now it takes about 3 times longer for the memory to grow and crash like it did before thanks to removing multiple timers. But the problem is it still grows, never goes back down and will eventually crash the game.
The memory barley grows 1 to 2 mb during game play in the game engine. It is the reset and change scenes that are killing it.
Anyone else have any ideas how I can try to keep it low? or am I going to have to release a game with this know bug and have user give bad rating dues to the game crashing.
Also other memory usage is nice and low.
Graphics is at 1.9mb
sound is at 412kb
and other memory is at about 9 to 11 mb.
All other memory is in the game engine.
I have 20 levels, all using the same actors and rules. So I don't understand why the game engine is growing.
I need to see if I can get my hands on 0.8.7 and 0.8.8 and see if the problem is there as well. If they are not perhaps I should release the game under one of those versions.
I started doing some testing.
Watching the memory growth it was always the game engine. When I did a reset scene it would jump by 5 to 10 mb and never go back down, if I did a change scene instead of a reset the memory only grew by 2mb but still grew and never went back down.
The game engine was in the 60+mb when the game would finally crash.
Reading over the forums I seen that the makers of GS rarely respond it seems, so I am curious if others have seen this.
So in trying to find out what was causing the giant gain in memory I went through everything and tried to clean things up. After I removed a few timers the memory stopped growing so fast. Something with the timers is causing the giant memory leap.
So now it takes about 3 times longer for the memory to grow and crash like it did before thanks to removing multiple timers. But the problem is it still grows, never goes back down and will eventually crash the game.
The memory barley grows 1 to 2 mb during game play in the game engine. It is the reset and change scenes that are killing it.
Anyone else have any ideas how I can try to keep it low? or am I going to have to release a game with this know bug and have user give bad rating dues to the game crashing.
Also other memory usage is nice and low.
Graphics is at 1.9mb
sound is at 412kb
and other memory is at about 9 to 11 mb.
All other memory is in the game engine.
I have 20 levels, all using the same actors and rules. So I don't understand why the game engine is growing.
I need to see if I can get my hands on 0.8.7 and 0.8.8 and see if the problem is there as well. If they are not perhaps I should release the game under one of those versions.
Comments
http://www.gsproforum.com/viewtopic.php?f=18&t=2
I still use a few timers and I will try replacing them with this trick and see how the memory goes.
I will post back with my findings.
http://gamesalad.com/forums/topic.php?id=8829
From what we can tell...it may be associated with the animation behavior. Are you using those?
Gendai asked for a copy of my game...perhaps they will ask for yours as well...or you can offer it to them via a bug report.
I am still going to test out this timer problem as I had it make a big difference with the game engine memory. At this point I am curious.
Simply telling support that there is a memory bug isn't good enough. For me finding out what is causing the memory bug is more helpful.
So fingers crossed :-)
All the optimization in the world isn't going to help the fact that GS won't release used memory. They have a bug and Gendai needs to fix it...otherwise...ALL GAMES will be susceptible to crashing. This is why I used such harsh copy in my thread.
Hopefully they find the leak and start paying attention to memory issues in GS's GE.
On another note however...optimization is still critical in your game dev...as it will help the FPS...but not so much the RAM issues that is causing your crashes.
I wrote the timer tip...it works pretty good for the most part...and now I rarely use timers anymore...(unless I get lazy on a simple actor or scene).
I'm starting to use the actor time to also control animation sequences...which allows a more COMPLEX animation to occur without adding the sprite frame overhead.
For example (on a spawned bomb actor):
when self.time < 3
.....[ animation sequence of bomb countdown ]
when self.time > 3
.....[ animation of explosion ]
.....[ interpolate width ] (to adjust size...such as an expanding blast)
.....constrain height to width
when self.time > 4
.....[ interpolate alpha to 0 in 1 second ] (to fade out)
when self.alpha = 0
destroy this actor
Its a simple example...but the potential is quite limitless.
So FPS isn't a problem, I have fine tuned everything. Been programming for 15 years so I am in that mind set of fine tuning lol.
Drives me nuts I have no control over the memory.
But going from years of programming software and going to making my first game, GS seemed the best first baby step. (was going to go to Unity 3.0 when it comes out)
Anyways on my testing, I removed my 3 animations and removed my timers.
Still climbs like mad. From things I did, it seems like GS is loading all the rules from all the actors (I have about 150+ actors on screen)
When the scene is loaded or reset it reloads all the rules into memory without cleaning up the old rules. So lets say a scene is loaded and with all actors and all rules I have 300 rules loaded into memory. Now when the scene resets instead of having 300 rules in memory I now have 600 since it didn't clean up.
I was able to tell this by loading a blank scene with 1 actor with one rule, to reset the scene. The memory doesn't climb no matter how many times I reset the scene.
And the fact that when I cleaned up some rules which lowered the amount of rules for the scene the game engine memory wasn't climbing as much as it was before.
So from what I can tell it looks like that is what it is. But then again only the developers of GS will know for sure.
I've been trying to think what is causing synthesis's problem.
For my current game, I am using a massive amount of art and sound assets, and I have to be extremely careful with the RAM usage. I am limiting each Scene to about 40MB of RAM. But unlike you guys, when I do a Change Scene, it flushes out all the RAM back down to the original level. I am not getting any memory creep.
I am not using any collision physics in my new game. So the problem could be lurking there. But I am using all of the other heavy hitters: Timers, Interpolate, Animate, large Rule sets, etc...
My first game, though, Danger Cats!, also didn't have a memory problem. And that used a lot of Physics - as much as I could get away with anyway.
I was able to play Danger Cats! for 2 and a half hours straight on my iPhone 2G - which is the worst of the worst. That device would crash if the RAM got anywhere close to 40MB, but I never noticed a problem with memory creep.
You guys seem to be creating some sort of perfect storm!
I made a quick demo on my wall of a spiral by spawning 1400 rotating actors. Just trying to tax GS. Every time I spawn an actor, the Game Engine section of the memory climbs. This test doesn't crash my 3GS, but it comes close.
It seems that the Game Engine section of memory is tied to the amount of Actors somehow.
In my new game, I am making it almost entirely with Instances. I only have 9 actors in my library. My Game Engine memory stays locked at 8MB the entire time.
I too have been programming for a long time, so I know how you feel.
I will keep making tests to try and find the culprit. It will be very satisfying to plug this leak!
Anyway, I wish you good luck!
I am sorry you guys are having these memory problems.
I am flying my wife and 4 young kids out to my sisters wedding and I want to release this game before the trip.
I will just have to release it as is and as soon as GS gets fixed get the game updated.
Also in my tests after a ton of collisions have happened and I reset the scene the memory jump is at its highest.
Perhaps helping pinpoint it for the GS developers will help get a fix out faster if they know where to look :-)
Have you published your physics games recently? Curious to know if Danger Cats (or similar) has memory creep in the new GS build.
If you didn't have a problem back then...do you now if you publish with v0.8.9?
It sounds as though the leak is connected to actors that have physics settings applied to them (such as collide behaviors). Perhaps Collide is a "Trigger" to the GE to store the rule sets.
Then when the change scene or reset scene behavior is executed...the RAM is NOT dumped and thus lingers (and builds with each change or reset) until it runs out. The more actors you have with physics...the more GE RAM is used (and not dumped). The GE RAM seems to be the only RAM that is creeping.
If Danger Cats has this problem on scene resets or scene changes...then its definitely a NEW bug.
The test will be where I will leave all rules but remove all collisions and see how the memory plays out.
Gravity is off. I use accurate to move my actors. I am curious with collides all gone how it does.
I will post my findings :-)
Wish they would chime in on threads like this and lend a hand once in a while.
BTW:
In my game (TOXIC ROACH)...I use NO gravity and all of my actors are propelled by the MOVE behavior. I use NO acceleration. I am using a fair amount of constraints though.
I wonder if FMG is using constraints with no ill will.
My actor counts are about 60 or so for the scene.
I made two Scenes and a button to jump between the two.
I did not notice any memory creep.
I'll do a new test of Danger Cats! in a little bit, and see if it still behaves under 0.8.9
First I made a copy of my game. Then I had 2 actors with about 15 collisions each and then 2 more actors with 4 each.
Removed all collisions, nothing else at all.
Every time I changed scene or reset the memory barley moved if at all.
After changing the scene multiple times the game engine would normally be at 50+mb was holding at 26mb and not growing with each change.
From this test I feel pretty sure that the memory leak is in collisions.
If you guys can see if you can test and confirm as well.
I will test TOXIC ROACH tomorrow (heading to bed now). I will remove collisions and see what happens.
And yup, Gendai coders really should pipe in & be getting involved, and working with you, instead of leaving you in the dark. The issues have been around for far too long, and surely theres a much better chance of getting things fixed quicker by working hand in hand with the dedicated members of the community that are trying to figure this out.
But yup... thanks...and keep up the good work. Your efforts are really appreciated by the non-coder users
In all my software I can't fix a bug unless I am able to replicate it. If my findings are confirmed then this should be the hammer on the nail for the developers and they should be able to get it worked out.
Fingers crossed :-D
"Food Fight!" has a massive amount of collisions, spawns and destroys, and timers with random setting going on. I'm not having the problem. Here are two screen shots:
The first shows the common action, the chef jumps and throws the pot. The chef is animated and the pot is spawned. When it collides with a vegetable, the veg is destroyed and a new actor is spawned in it's place with usually at least 1 to 4 additional actors spawned (pieces flying off, etc.). When the pot hits a veggie, it is destroyed and a new one is spawned (to bounce off). They all have .caf sound fx as well. All graphics are 24 png with transparencies, and all different sizes, including odd pixel dimensions. I gave no thought to the power of 4 thing. I have changed every graphic to "Fixed" for the Harizontal and Vertical Wrap in the graphics. I have some invisible walls for trigger actions, and two invisible actors for spawning rules.
It also uses gravity with move, timers and acceleration for the movement and random movements. The entire game has 52 scenes.
The second screen shot shows the free for all game play mode where the veggies (more than shown) constantly attack. As one is destroyed, a new one is spawned. There is usually 8 veggie actors on stage.
So, I've played this over and over and it never gets above 36 meg total memory. When I hit menu, which changes scene, it drops down to 29.
I do get fluctuations in memory from 29-about 38, but it always goes back down.
If you want to see this in action, this is a free iPhone game you can get here: http://itunes.apple.com/us/app/food-fight/id352646643?mt=8
Hope this helps.
For me when I removed all my collides the memory leak stopped.
You confirmed that you have collisions and no leak.
This means that there is a combo effect. Something in my rules, or a certain rule combined with the collide must be causing the memory leak.
But now to find out what is in the combo with the collides to cause it.
Is it rules with the same actor as the collides or is it a rule elsewhere in the scene.
The way I could test this is to keep all the collides and start removing the other rules instead.
Trying to find the 2nd half of the culprit.
But here is what it really comes down to. If I was able to see each component and the memory it was taking would make this a 100x easier.
A feature request for GS would be a more detailed memory view. A better breakdown of what is using what.
I am trying to get my internet meter updated for a customer and I will try to find the time to try more tests. Getting tests from others will truly help as well.
I leave in a week and will be releasing my game, with the bugs in a day or so.
The main nose unit is a constant animation (inhale and exhale), but the spinning translucent white saw blade thingy is constrained to the nose and always spinning, as well as slowing and reversing direction. The 4 gear things are also independent actors and constrained to the nose unit. They have animation (spinning motions) that activate depending upon motion direction. There is also a constrained invisible actor at the tip of the nose that pushes away the orb actors from the nose tip. There is also an invisible constrained actor below the nose that is the inhaled trigger.
This tests perfectly with no memory problems on my 3gs right around 60 fps. It fluctuates a few meg up and down for the total memory, but never goes above about 26 total, and the game engine never increases.
I don't know what I'm doing different other than my graphics settings (changing the Wraps to "Fixed"), but I'm just not experiencing these memory issues.
Oh, and if you want to see this game, there are codes at the end of this thread: http://gamesalad.com/forums/topic.php?id=8097
I also tested my mouse avoidance demo on my wall that has 210 Constrain Attributes and there is no memory creep there as well.
Hmmm.
I just got home from the gym so I will start doing more in depth tests to try and find the combo.
I will then see if I can recreate the memory leak in a demo app and upload for others to test as well.
Post back soon.
-Shane
From the testing I am doing nothing is making sense. There is something in my game that is triggering this.
The next test I did was to put the collisions back in, then remove other attributes. First I removed all particles that where used when things collided. And the memory stopped growing on reset scene but kept growing during game play, only a little at a time but always climbed and never went back down. This could explain why when I took collisions out the memory stopped growing because the particles also stopped. So I though to my self what else is happening a lot of, and when things collide? sounds! So I removed them as well.
Now with particles and sounds out of my game the memory has totally stopped growing.
So I think to myself, ok now lets remake this in a new project and replicate it.
I make a new project, use the same sounds, particles and rules. Nothing else.
Memory stays fine! Yet when in my game the memory climbs.
From what I can tell it doesn't seem to be just one thing. And the fact that I can not replicate it in a new project means there is something in the project files that is throwing things off.
The difference between the test projects and mine as well is my project takes about 30 sec to open and then slows down to a snail after 10 min in GS.
All the test projects open instantly and never slow down, granted they are much smaller.
I also noticed I was using GS viewer 8.8 instead of 8.9. Updated to that and the game engine memory usage also dropped by about 8 mb.
I am starting to think the viewer is not the best method of reading memory.
My next test is to get the game complied, run it straight on the ipad and then read the memory through xcode and get a better idea.
It is POSSIBLE that the memory climbing is a GS viewer issue only and isn't with a complied game. Only one way for me to tell, use the game without GS viewer.
-Shane
Although I do not have 150+ actors in my Scenes, I do push GameSalad pretty hard.
Still, I have experienced no memory creep whatsoever in any of my games or demos.
I hope you are able to narrow your memory issue down.
Sounds might be an avenue to check as they can exist 'globally'. For example, you are able to play a sound as you change Scenes.
Uploaded and complied my game, I then transferred it into my ipad.
Open instruments and start first a memory leak watch.
Not a single memory leak. And the total memory drops when I change or reset a scene.
Then ran instruments with activity monitor.
Memory never climbs above 36mb and it cleans up every time I change or reset the scene.
This is the total opposite that happens in the GS viewer.
From what I can tell the problem is simply in the viewer and not in the finished game!
This requires more testing, but this first finding is making me VERY happy about releasing my game.
-Shane
QS
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
Then opened xcode, went to the organizer and then the iPad, under installed apps I clicked the + and had it put the .app file on.
Tested that.
-Shane