@Tiny_Ideas said:
If it had been back a year ago, I would have stayed and spent some time tying to provide examples etc. But I have reached a point where time is more important than money.
It really is strange that you are still experiencing crashes to this extent, because the majority of known crashes have been resolved. Personally, the latest two versions haven't crashed on me at all. It might be worth doing a clean install and seeing if it changes anything. Are you running the OS X Yosemite?
Nightly and RC version projects will turn into folders if you don't have an old RC or Nightly installed. All GS projects, if you don't have any version of GS installed (also most likely on a clean OS, if you've installed GS, but haven't run it). That's because a GS project basically is a folder.
The most straightforward solution is to rename the folder and add .gameproj to the end of it. Changing the extension will make the system see it as a GS project file again (as long as you have GS Creator installed).
Simply put, nothing changed with the projects, OS X just didn't know how to display them correctly.
I haven't experenced any crashes lately. I would check to see if somewhere you're accessing a zero row column or have an error in an expression as these will now cause crashes. As GS fixes things, the software becomes more exacting and is more sensitive to errors that would slip through before.
I've probably sent in 10-20 Bug Splat crash reports for the last few releases alone. The crashes only occur when Game Center behaviors are active (post score, show leaderboards, show achievements), it's a bit random. All those behaviors test 100% ok via adhoc build and the crashes only occur when those behaviors are active (I've got a rule that turns them all off so I can test other things via preview without random crashing).
GS is accomplishing things much, much faster than ever before, thanks to it's new direction. People need to withhold their complaints for a bit, and just observe, as GS isn't the same as it use to be.
Nightly and RC version projects will turn into folders if you don't have an old RC or Nightly installed. All GS projects, if you don't have any version of GS installed (also most likely on a clean OS, if you've installed GS, but haven't run it). That's because a GS project basically is a folder.
The most straightforward solution is to rename the folder and add .gameproj to the end of it. Changing the extension will make the system see it as a GS project file again (as long as you have GS Creator installed).
Simply put, nothing changed with the projects, OS X just didn't know how to display them correctly.
Yea it's all good now. Like I say it took a restart and all those folders did in fact display back to a single "file"...project. Whew !!
@BlackCloakGS has anything been said about addressing the table memory leak issue? We are about to launch our first game and this is the only problem we face. Game runs fine at start, but memory keeps stacking up after each scene change or death... I had a tester today tell me he was playing the game for an hour, the first thirty minutes was great, but by the end the game became unplayable... really not good.
I know people make a lot of requests but I have seen others asking about this and can't imagine it not being a top priority.
Thanks!
-Eric
@RossmanBrothersGames said:
BlackCloakGS has anything been said about addressing the table memory leak issue? We are about to launch our first game and this is the only problem we face. Game runs fine at start, but memory keeps stacking up after each scene change or death... I had a tester today tell me he was playing the game for an hour, the first thirty minutes was great, but by the end the game became unplayable... really not good.
I know people make a lot of requests but I have seen others asking about this and can't imagine it not being a top priority.
Thanks!
-Eric
This has been addressed and the leaks are not due to tables. If there are leaks it's coming from somewhere else. See this thread.
Thanks @The_Gamesalad_Guru I do hope the figure it out soon. I just tested my project that was built with the latest version of Gamesalad. In Xcode Instruments Allocations, after each scene change you see a clear jump in memory, playing for a long period of time makes a steady incline.
Hate to beat a dead horse with all the progress being made but I have to agree with @RossmanBrothersGames unfortunately without an updated roadmap it's difficult to tell what is a priority at any given time, and memory issues are putting my game on hold along with many others. Hopefully we'll see this be fixed very soon!
Hello Game Salad, could you please make it so we can shut down that initial popup window when opening Game Salad?
I just want my project window open, and not that popup "Open Recent Projects" window. I just like to shut that straight away. Currently (and for some time now) it hangs around and can't be closed.
@Hymloe try the following: when your 4th mission starts then save attributes that needs saving and then trigger the "reset scene" behavior, it will flush the RAM that has been built up. Do the same after the next 3 levels and so forth. This principle is how I've worked around the memory build up issue to avoid app crashing on a hungry app.
Well then it is something else as @Hopscotch proved via instruments it isn't the issue. You can't argue with science. You have to prove things out. Assuming something is an issue doesn't help narrow it down. That issue i mentioned is fixed so we need to move on to see what exactly is causing the memory build up in peoples games. Some are reporting it happens during a scene change so maybe GS needs to flush memory on scene changes.
I know how you feel @Hymloe. I needed to fill up my pool for my kids today. I filled my bucket, tossed it in the pool and all it did was wet the bottom. WTH! I know it is a 4 year old bucket but nearly 23% of all household buckets are that old.
As a side note, I tested your current version yet again. On an iPhone4s which is technically comparable with the iPad2 you used. I wasted another good 45 minutes of gameplay in the hope of finally crashing it. Nothing. Mission after mission running fine.
Now, your game footprint is about 130Mb as times, which IS high for a 512Mb RAM device, no matter what development environment you use. As a rule of thumb, you should not exceed half of the available RAM.
If you target old devices, then you must cater for their limitations and reduce the amount and size of art and sound assets. This is NOT a GS bug. It is called engineering responsibility on your behalf.
What does get me huffy is that you obviously only tested on the Viewer again if it crashed so soon for you.
To @BlackCloakGS, just for the record, there still are memory leaks somewhere in the system, as you are aware. There is a small increase over time, but as shown before, it is not as game breaking as stated by some and not related to the usual suspects. I will keep experimenting as time allows.
This is exactly how bad info gets spread. This is a major issue on this forum. As soon as something goes wrong people jump on the forum as say it's a bug without doing proper and extensive testing. The irony is they always say, "it's not my code. i know what I'm doing." Which is crap because we all make coding mistakes. It's just that the power users assume they made a mistake first and go looking to narrow it down. I test eveything i do to be sure it works. i add stuff then test it out. i don't just sit and code for hours and not test. That leads to major bug hunting which wastes time. You can't rush through things. At some point you have to get some discipline and be more methodical about ones work. In the long run it saves time and effort.
After testing what I think might be a bug, the first thing i do is make a bug report. Then I'll come to the forum and post to see if anyone experenced the issue. I don't scream ITS A BUG. I will usually ask if anyone can see anything wrong with how I am doing something. I always assume first that I am missing something and 90 times out of 100, I did mess up something stupid.
Even 130 shouldn't cause a crash on an iPad 2. 150 is more crash range for that device.
Yes, as a developer these are fundamentals that one needs to understand or research. GS can make development easy but not help you break physical boundaries.
Here a quick mockup of why memory spikes and crashes your system if your assets (images, sound, music) are very big.
With the new rendering engine with its large fixed image sheets, even this worry will be taken out of our hands.
@hopscoth I agree with your thoughts on the memory leak. It definitely shouldn't be causing someone's game to crash after a short play time. It is a build up over time, that hasn't caused me any crashes, just choppy performance after the game has been used for hours. The problem is the memory build up stays when the app is left open in the background. So if people play the game throughout the day, and the app never fully closes, they will start to get slightly worse game play.
I would disagree with you saying this isn't game breaking. I think @BlackCloakGS needs to know this is definitely affecting games very negatively. While it isn't game breaking in causing major crashes (I think if you are experiencing that the problem is in something else, like your code) it is game breaking in the sense that it creates a bad user experience that I as the game creator has no control over. My game is a tough platformer where you die a lot with many scene changes and requires precision controls. The game will play fine for like 30 minutes, however after memory build ups even the slightest lag that starts coming (not major choppiness, just noticeable choppyness when spawning an actor or jumping on an enemies head) makes the game very frustrating. Myself and others have been posting about this problem for years, I hope we can see an solution. If there was a way to flush game RAM usage at scene changes that would be amazing.
@GeorgeGS is looking into the issue. If you want to help speed up the fix he needs more simple (one two actors at most) project that demonstrate the issue clearly.
@RossmanBrothersGames said:
I think BlackCloakGS needs to know this is definitely affecting games very negatively.
This is why I end nearly every post regarding this issue with the confirmation that there definitely IS some leaking going on.
I have made dozens of projects trying to isolate the issue in various ways, but unable to reproduce it.
I have scene and graphics heavy projects myself which have a 200Mb+ footprint. These show a very slight memory increase over time, which then suddenly dissipates and drops back to normal after a few minutes. Probably not behaving as expected, but not causing problems.
Nothing to the extent of crashing after a few minutes.
I do see projects which crash on old devices because resources are pushed to the limits, but that is another story. If your project does not fall into this category the there is obviously some special interplay of circumstances which orphan memory.
As @BlackCloakGS suggests, look at your particular implementation, build a mini version of it and try to reproduce it that way. Then we can point GS in the right direction.
@tmann said:
Hopscotch There is no garbage collection in iOS your diagram seems to be trying to blame the memory issues on the OS !!
Semantics, @tmann, the OS just does it for you now once there is no reference to an object.
The point is that it is not instantaneous, actually there can be a larger delay under ARC before memory is really freed up for reallocation than before.
We do not use ARC in the iOS engine. We have three memory management systems that all create and destroy memory in our engine. The lua GC, manual retain release objective-c , and new/malloc and delete/free from C/C++.
Comments
It really is strange that you are still experiencing crashes to this extent, because the majority of known crashes have been resolved. Personally, the latest two versions haven't crashed on me at all. It might be worth doing a clean install and seeing if it changes anything. Are you running the OS X Yosemite?
@Thunder_Child
Nightly and RC version projects will turn into folders if you don't have an old RC or Nightly installed. All GS projects, if you don't have any version of GS installed (also most likely on a clean OS, if you've installed GS, but haven't run it). That's because a GS project basically is a folder.
The most straightforward solution is to rename the folder and add .gameproj to the end of it. Changing the extension will make the system see it as a GS project file again (as long as you have GS Creator installed).
Simply put, nothing changed with the projects, OS X just didn't know how to display them correctly.
I haven't experenced any crashes lately. I would check to see if somewhere you're accessing a zero row column or have an error in an expression as these will now cause crashes. As GS fixes things, the software becomes more exacting and is more sensitive to errors that would slip through before.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
I've probably sent in 10-20 Bug Splat crash reports for the last few releases alone. The crashes only occur when Game Center behaviors are active (post score, show leaderboards, show achievements), it's a bit random. All those behaviors test 100% ok via adhoc build and the crashes only occur when those behaviors are active (I've got a rule that turns them all off so I can test other things via preview without random crashing).
I have experienced a good amount of crashes as well with the past few builds when opening and closing projects too fast.
Fortuna Infortuna Forti Una
How long can you remain offline with this version before needing to login in online again?
I've experienced a few crashes as well. But less then in the past by a large amount. Always send those bugsplats everyone!
For me it's usually as i'm closing a project out, it still saves, but crashes on close, which is probably the best time to crash.
Also had one from image import again, I think.
Follow us: Twitter - Website
GS is accomplishing things much, much faster than ever before, thanks to it's new direction. People need to withhold their complaints for a bit, and just observe, as GS isn't the same as it use to be.
I'm getting one or two crashes a day. No obvious cause.......Way better than a month ago. Hourly crashes.
I can work with current build.
Yea it's all good now. Like I say it took a restart and all those folders did in fact display back to a single "file"...project. Whew !!
Complete Guide to iOS Publishing {} Complete Guide to Mac Publishing
@BlackCloakGS has anything been said about addressing the table memory leak issue? We are about to launch our first game and this is the only problem we face. Game runs fine at start, but memory keeps stacking up after each scene change or death... I had a tester today tell me he was playing the game for an hour, the first thirty minutes was great, but by the end the game became unplayable... really not good.
I know people make a lot of requests but I have seen others asking about this and can't imagine it not being a top priority.
Thanks!
-Eric
www.rossmanbrosgames.com
This has been addressed and the leaks are not due to tables. If there are leaks it's coming from somewhere else. See this thread.
http://forums.gamesalad.com/discussion/87868/mac-stable-release-0-13-31/p2
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Thanks @The_Gamesalad_Guru I do hope the figure it out soon. I just tested my project that was built with the latest version of Gamesalad. In Xcode Instruments Allocations, after each scene change you see a clear jump in memory, playing for a long period of time makes a steady incline.
www.rossmanbrosgames.com
Thanks for the super fast updates GS Team!
Big Smile Games Play Happy!
Check out our other GameSalad exclusives.
Hate to beat a dead horse with all the progress being made but I have to agree with @RossmanBrothersGames unfortunately without an updated roadmap it's difficult to tell what is a priority at any given time, and memory issues are putting my game on hold along with many others. Hopefully we'll see this be fixed very soon!
POLAR ROLLOUT (New Line-Drawing Physics Puzzler!) - FREE Download
Hello Game Salad, could you please make it so we can shut down that initial popup window when opening Game Salad?
I just want my project window open, and not that popup "Open Recent Projects" window. I just like to shut that straight away. Currently (and for some time now) it hangs around and can't be closed.
Just tested my game in 0.13.31 (on iPad 2), and it crashed after about 4 missions.
No progress made on that bug at all.
All hope is lost.
@Hymloe try the following: when your 4th mission starts then save attributes that needs saving and then trigger the "reset scene" behavior, it will flush the RAM that has been built up. Do the same after the next 3 levels and so forth. This principle is how I've worked around the memory build up issue to avoid app crashing on a hungry app.
Well then it is something else as @Hopscotch proved via instruments it isn't the issue. You can't argue with science. You have to prove things out. Assuming something is an issue doesn't help narrow it down. That issue i mentioned is fixed so we need to move on to see what exactly is causing the memory build up in peoples games. Some are reporting it happens during a scene change so maybe GS needs to flush memory on scene changes.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
I know how you feel @Hymloe. I needed to fill up my pool for my kids today. I filled my bucket, tossed it in the pool and all it did was wet the bottom. WTH! I know it is a 4 year old bucket but nearly 23% of all household buckets are that old.
As a side note, I tested your current version yet again. On an iPhone4s which is technically comparable with the iPad2 you used. I wasted another good 45 minutes of gameplay in the hope of finally crashing it. Nothing. Mission after mission running fine.
Now, your game footprint is about 130Mb as times, which IS high for a 512Mb RAM device, no matter what development environment you use. As a rule of thumb, you should not exceed half of the available RAM.
If you target old devices, then you must cater for their limitations and reduce the amount and size of art and sound assets. This is NOT a GS bug. It is called engineering responsibility on your behalf.
What does get me huffy is that you obviously only tested on the Viewer again if it crashed so soon for you.
To @BlackCloakGS, just for the record, there still are memory leaks somewhere in the system, as you are aware. There is a small increase over time, but as shown before, it is not as game breaking as stated by some and not related to the usual suspects. I will keep experimenting as time allows.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
This is exactly how bad info gets spread. This is a major issue on this forum. As soon as something goes wrong people jump on the forum as say it's a bug without doing proper and extensive testing. The irony is they always say, "it's not my code. i know what I'm doing." Which is crap because we all make coding mistakes. It's just that the power users assume they made a mistake first and go looking to narrow it down. I test eveything i do to be sure it works. i add stuff then test it out. i don't just sit and code for hours and not test. That leads to major bug hunting which wastes time. You can't rush through things. At some point you have to get some discipline and be more methodical about ones work. In the long run it saves time and effort.
After testing what I think might be a bug, the first thing i do is make a bug report. Then I'll come to the forum and post to see if anyone experenced the issue. I don't scream ITS A BUG. I will usually ask if anyone can see anything wrong with how I am doing something. I always assume first that I am missing something and 90 times out of 100, I did mess up something stupid.
Even 130 shouldn't cause a crash on an iPad 2. 150 is more crash range for that device.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
A user on stackoverflow did some tests building up memory on devices until it forced a crash here are the results.
I did some testing with the utility Split wrote (link is in his answer).
I don't have all devices available but this is what I could test so far:
iPad1: 127MB/256MB/49% (crash amount/total amount/percentage of total)
iPad2: 275MB/512MB/53%
iPad3: 645MB/1024MB/62%
iPad4: 585MB/1024MB/57% (iOS 8.1)
iPad Mini 1st Generation: 297MB/512MB/58%
iPad Mini retina: 696MB/1024MB/68% (iOS 7.1)
iPad Air: 697MB/1024MB/68%
iPad Air 2: 1195MB/2048MB/58%
iPod touch 4th gen: 130MB/256MB/51% (iOS 6.1.1)
iPod touch 5th gen: 286MB/512MB/56% (iOS 7.0)
iPhone4: 325MB/512MB/63%
iPhone4S: 286MB/512MB/56%
iPhone5: 645MB/1024MB/62%
iPhone5S: 646MB/1024MB/63%
iPhone6: 645MB/1024MB/62%
iPhone6+: 645MB/1024MB/62%
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Yes, as a developer these are fundamentals that one needs to understand or research. GS can make development easy but not help you break physical boundaries.
Here a quick mockup of why memory spikes and crashes your system if your assets (images, sound, music) are very big.
With the new rendering engine with its large fixed image sheets, even this worry will be taken out of our hands.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
@hopscoth I agree with your thoughts on the memory leak. It definitely shouldn't be causing someone's game to crash after a short play time. It is a build up over time, that hasn't caused me any crashes, just choppy performance after the game has been used for hours. The problem is the memory build up stays when the app is left open in the background. So if people play the game throughout the day, and the app never fully closes, they will start to get slightly worse game play.
I would disagree with you saying this isn't game breaking. I think @BlackCloakGS needs to know this is definitely affecting games very negatively. While it isn't game breaking in causing major crashes (I think if you are experiencing that the problem is in something else, like your code) it is game breaking in the sense that it creates a bad user experience that I as the game creator has no control over. My game is a tough platformer where you die a lot with many scene changes and requires precision controls. The game will play fine for like 30 minutes, however after memory build ups even the slightest lag that starts coming (not major choppiness, just noticeable choppyness when spawning an actor or jumping on an enemies head) makes the game very frustrating. Myself and others have been posting about this problem for years, I hope we can see an solution. If there was a way to flush game RAM usage at scene changes that would be amazing.
www.rossmanbrosgames.com
@GeorgeGS is looking into the issue. If you want to help speed up the fix he needs more simple (one two actors at most) project that demonstrate the issue clearly.
@Hopscotch There is no garbage collection in iOS your diagram seems to be trying to blame the memory issues on the OS !!
This is why I end nearly every post regarding this issue with the confirmation that there definitely IS some leaking going on.
I have made dozens of projects trying to isolate the issue in various ways, but unable to reproduce it.
I have scene and graphics heavy projects myself which have a 200Mb+ footprint. These show a very slight memory increase over time, which then suddenly dissipates and drops back to normal after a few minutes. Probably not behaving as expected, but not causing problems.
Nothing to the extent of crashing after a few minutes.
I do see projects which crash on old devices because resources are pushed to the limits, but that is another story. If your project does not fall into this category the there is obviously some special interplay of circumstances which orphan memory.
As @BlackCloakGS suggests, look at your particular implementation, build a mini version of it and try to reproduce it that way. Then we can point GS in the right direction.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Semantics, @tmann, the OS just does it for you now once there is no reference to an object.
The point is that it is not instantaneous, actually there can be a larger delay under ARC before memory is really freed up for reallocation than before.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
@Hopscotch Does the iOS engine actually use ARC ? Maybe the problem is the legacy manual memory management, GS would need to clarify.
We do not use ARC in the iOS engine. We have three memory management systems that all create and destroy memory in our engine. The lua GC, manual retain release objective-c , and new/malloc and delete/free from C/C++.