@colander said:
MarcMySalad Hymloe when I say it is not fixable I mean with GS's current resources it is not possible. The amount of time it would take to do the task would be longer than starting from scratch and would be similar in practice as a rewrite but take much longer to achieve. I believe they had a review on this over a year ago and decided just that. This is why we are getting Graphine it is easier and quicker to start over.
MarcMySalad saying the GS team is lazy is just not cool. From what I see they are very hard working. They work on projects outside of working hours for the benefit of the community and at times late into their evenings fixing Creator and publishing issues. They are not lazy it just that fixing the code base is an enormous and very difficult task.
My code writing experience is limited to VBA and I know first hand fixing some else's inefficient poorly written and commented code is a waste of time. It is just a patch which causes other problems. A rewrite it is always the quicker and best option.
They are dealing with thousands and thousands of lines of code so interconnected and poorly constructed that changes in one area create unintended problems elsewhere. This is self evident we can all see the results. Nearly every time an improvement is made to Creator a bunch of hard to fix bugs crop up and some have persisted for years.
I know this is difficult to understand if you code writing experience is limited to GS. But you must of come across other faulty things created by other people where it was easier and quicker to tear it down or through it away and start again. I believe this is one of those situations it certainly appears to what they are doing. Unfortunately for them they can't just through Creator in the bin, lots of people are using it. It would be akin to throwing their business in the bin. At some point in the future when they have migrated people over to Graphine, Creator will be quietly retired. Nothing else would make any sense.
Every game I've worked on at professional game dev studios had memory issues. You just get someone to clean them up at the end. Game Salad needs to do just that.
Why are you saying what you're saying? Why would you just write a post regurgitating the same unacceptable excuses Game Salad have given for the memory issues?
@ForumNinja said:
Hey everyone. It's my understanding that release 12.20 was just supposed to have iOS 64 support, account validation on Creator start, and some memory fixes for people using Mac Yosemite 10.10.
While there still appears to be some memory leak issues (check out bug 709 and bug 103).
BenSawyer sheds some insight on what is causing the memory leak as well as a workaround you guys can use in the meantime while we work on fixing it (see comment 44 for bug 103).
I have my suspicions that you don't actually understand the contents of that comment, @ForumNinja.
It doesn't even really make sense to me, the way it's written. What does it mean?
Could you explain it for us in more detail @ForumNinja?
I would suggest that it is not a workaround that would benefit those of us having the problem, seeing our projects may already be intrinsically built around parts of Game Salad that should work, but may have these memory related issues.
@BenSawyer, perhaps you can explain in more detail here, in more detail, because I find it hard to follow what you're saying on the comment on bug 103.
@ForumNinja said:
Hey everyone. It's my understanding that release 12.20 was just supposed to have iOS 64 support, account validation on Creator start, and some memory fixes for people using Mac Yosemite 10.10.
While there still appears to be some memory leak issues (check out bug 709 and bug 103).
BenSawyer sheds some insight on what is causing the memory leak as well as a workaround you guys can use in the meantime while we work on fixing it (see comment 44 for bug 103).
I appreciate the input, and the workaround. But that's not really feasable for us to transfer every piece of table data to a self attribute first, nor is that the only issue at hand. That's basically asking us to rewrite our code because a core aspect of the engine is leaking memory.
@Hymloe said:
Every game I've worked on at professional game dev studios had memory issues. You just get someone to clean them up at the end. Game Salad needs to do just that.
They obviously had a good code base structure where this is a relatively easy process. From everything I have seen over the time I have been here I can deduce this is not the case with Creator otherwise it would have been fixed long ago.
Why are you saying what you're saying? Why would you just write a post regurgitating the same unacceptable excuses Game Salad have given for the memory issues?
I am in no way apologising for GS I am simply saying what I believe to be the case. Doesn't even mean I am correct it is just the conclusion I came to from what I have seen and experienced here.
They need to be fixed.
They are fixing it in the long term by creating Graphine. In the short term I have accepted this is where it's at and like everyone else am waiting for Creator to be fixed so I can move forward. I don't like it and wish the original GS team had done a much better job but unfortunately they didn't.
Here is 10 minutes playtime (as an adhoc) of a "heavy" game, scene 8732px wide, 130 actors, 102 of them with animations, rules, etc. Table functions and numerous scene changes. Most images and animations are 1024x1024px,
I get the same results in a wild shooter where dozens of projectiles and enemies get spawned and destroyed every second.
From what you describe I suspect one of the following culprits:
Accessing a 0 row in table functions. Doing randomly generated stuff can easily lead to some oversights/rare conditions where you may address a 0 row in a table
Some runaway loop, again caused by some rare condition in your logic
Creating blank tables every scene from a template table instead of reusing existing ones. (This does bloat memory)
Using the Viewer instead of an actual adhoc build. I only ever user adhoc build to test. That is the only real representation of how the code will run when published.
Or, your art assets really are too much for a mobile device and no GS or Unity can make it run. Mobile devices are limited, and you need to plan the scope of your game/art around it.
Maybe you would consider a dev of your choice here to help look at your project. Who knows, it may be a small issue and you are ready to publish tomorrow.
@Hopscotch said:
GS, close your ears and keep working!
MarcMySalad, Hymloe, unfortunately I do not share your experience.
Here is 10 minutes playtime (as an adhoc) of a "heavy" game, scene 8732px wide, 130 actors, 102 of them with animations, rules, etc. Table functions and numerous scene changes. Most images and animations are 1024x1024px,
I get the same results in a wild shooter where dozens of projectiles and enemies get spawned and destroyed every second.
From what you describe I suspect one of the following culprits:
Accessing a 0 row in table functions. Doing randomly generated stuff can easily lead to some oversights/rare conditions where you may address a 0 row in a table
Some runaway loop, again caused by some rare condition in your logic
Creating blank tables every scene from a template table instead of reusing existing ones. (This does bloat memory)
Using the Viewer instead of an actual adhoc build. I only ever user adhoc build to test. That is the only real representation of how the code will run when published.
Or, your art assets really are too much for a mobile device and no GS or Unity can make it run. Mobile devices are limited, and you need to plan the scope of your game/art around it.
Maybe you would consider a dev of your choice here to help look at your project. Who knows, it may be a small issue and you are ready to publish tomorrow.
You sure left out important information here. What device is this running on? How does this compare to usage in previous versions of the creator? What's the actual memory usage? What about 2048x2048 textures? Just a vague timeline screenshot showing a normal range without spikes or warnings.
You aren't the only one using instruments who knows a thing or two. I gave a breakdown earlier in the thread of devices and there usage and referenced previous stables performance metrics for comparison.
Gs pretty much acknowleges there are memory leaks in this thread and in the bugs section, yet here you are telling people it's because they don't know how to code and to hire a dev? HAH. It's an issue, not as big as everyone is making it out to be, but don't try and say it's not.
@AlchimiaStudios, the above tests I did where iPad4 and iPhone5. The point being discussed was alleged memory increase by images, not if the device could handle it.
I never use 2048x2048 images. I tile or break scene backgrounds into patchwork elements. GS is good at throwing lots of images around, old devices however are bad and slow at loading big images. To accommodate old devices I keep the images smaller and build up the scene at run time. GS is great at swapping images in and out of memory as long as you give it room to breathe. Same with any other dev environment. This way they even run fine on old Android devices through the funny Amazon wrapper.
GS may acknowledge memory leaks and there probably are, and these should be fixed. However, not to the extent of crippling your game.
If I said that they can't code, then it applies to me too. The examples I gave, trip me up all the time.
Oh, and I did not offer any services for hire. If I were to help them it would be purely out of selfish reasons to get a pat on the back in the unlikely event of being of help. No amount of money can compensate taking me out of my development time.
@Hopscotch said:
AlchimiaStudios, the above tests I did where iPad4 and iPhone5. The point being discussed was alleged memory increase by images, not if the device could handle it.
I never use 2048x2048 images. I tile or break scene backgrounds into patchwork elements. GS is good at throwing lots of images around, old devices however are bad and slow at loading big images. To accommodate old devices I keep the images smaller and build up the scene at run time. GS is great at swapping images in and out of memory as long as you give it room to breathe. Same with any other dev environment.
GS may acknowledge memory leaks and there probably are, and these should be fixed. However, not to the extent of crippling your game.
If I said that they can't code, then it applies to me too. The examples I gave, trip me up all the time.
Oh, and I did not offer any services for hire. If I were to help them it would be purely out of selfish reasons to get a pat on the back in the unlikely event of being of help. No amount of money can compensate taking me out of my development time.
Weather the device can handle it is directly related to memory usage. The reason I say it's not as big an issue as it's made out to be is because the performance is causing crashes on device with 512mb of ram. Older devices only. So worst case scenario, you drop support for them.
But let's talk about how this could be possibly be "crippling to your game".
On those devices with 512mb; 256mb is the threshold for a crash, as you can imagine going from 210-220mb used to 256mb used can be an easy threshold to cross. A small leak or increased usage from the engines versions could cause this crash.
Going from 350 to 512mb (limit for 1gb devices) used is a much larger threshold and would allow for small increases from the engine without much notice.
So you can see how it could cripple a game. This is why "large projects" are being discussed because they could be performing close to the limits and be fine in one build and then a few releases later small things change and you can no longer get an acceptable run time performance on the same app that was working before.
I personally wasn't saying you were advertising yourself as a work for hire, rather that the comment in general was a bit demeaning and unnecessary.
Just tick the Votes box, and click "Change my votes".
Here is a good idea everyone:
I just voted for this and I also unchecked all my other votes. If we all do that this will go to the top of the list quickly and something may be done sooner than later.
When the memory issue is fixed and apps stop crashing you can put your other votes back.
As I've said before, Admob and collision areas don't matter a ^ if we can't get our apps approved!
Been reading all the posts in here, and this is my opinion:
1) I think Game Salad should focus on fixing the memory issues until 0.13.0 version, this is the final version for Game Salad Creator and stop updating for Mac and Windows.
2) This will give time for the Programmers to focus on the new engine Graphene SDK, to roll out Beta ( Test ) and finally have a Stable Version out to the community.
This is just my humble opinion...I would rather have Gamesalad Staff focus on Graphene SDK and just retire Game Salad Creator after 0.13.0 comes out. If not, I fear that we may have to wait 6 months - 1 Year for the release of Graphene SDK ( Hope I'm wrong ...)
As for myself, I have a game that I will be releasing with the current Game Salad Creator, and afterwards, I will wait for Graphene SDK, I can't get another Pro Subscription which expires on 2 / 2015. I would rather wait for Graphene SDK to see the Pro's and Con's. Meanwhile, I'm already using another Game Engine and teaching myself Objective C, which for a newbie, it's not that bad, thought it was going to be harder......God Bless...
@luke2125 I know you are stating your opinion, but please realize the flaws in it.
1) GS can not simply be a final version, the app stores are constantly changing and require necessary changes (ex. 64-bit support). This is out of gamesalad's hands.
Stop updating it and we all will be unable to do anything with it, hence no need to pay for pro and essentially hurt Gamesalad as a whole.
2) The flaws stated on point 1 explain why this is not an option.
There a lot more to it, and hopefully you realize it.
@trashdinner@hotmail.com said:
I upgraded to Yosemite and Gamesalad was so sluggish it was impossible to scroll through code and everything was slow ... that never happened with Mavericks so I'm sadly reverting. Everything else runs flawlessly in Yosemite.
Yep, I found GS un-usable on Yosemite, and had a LOT of trouble even TRYING these new versions of GS, because I had to move from 10.8.5 to 10.9.4 just so I could get the right version of XCode so I could compile the Viewer over to my iPad.
It was actually a bit of a nightmare, all caused by Game Salad not support Yosemite.
@Hopscotch said:
GS, close your ears and keep working!
MarcMySalad, Hymloe, unfortunately I do not share your experience.
Here is 10 minutes playtime (as an adhoc) of a "heavy" game, scene 8732px wide, 130 actors, 102 of them with animations, rules, etc. Table functions and numerous scene changes. Most images and animations are 1024x1024px,
I get the same results in a wild shooter where dozens of projectiles and enemies get spawned and destroyed every second.
From what you describe I suspect one of the following culprits:
Accessing a 0 row in table functions. Doing randomly generated stuff can easily lead to some oversights/rare conditions where you may address a 0 row in a table
Some runaway loop, again caused by some rare condition in your logic
Creating blank tables every scene from a template table instead of reusing existing ones. (This does bloat memory)
Using the Viewer instead of an actual adhoc build. I only ever user adhoc build to test. That is the only real representation of how the code will run when published.
Or, your art assets really are too much for a mobile device and no GS or Unity can make it run. Mobile devices are limited, and you need to plan the scope of your game/art around it.
Maybe you would consider a dev of your choice here to help look at your project. Who knows, it may be a small issue and you are ready to publish tomorrow.
What does the graph show there, @Hopscotch ? Is the red line the point where the device will crap out? Or just showing the max memory it hit? What amount of memory is that, that your game gets to?
If you could go into more detail on some of those suggestions you've made, that would be much appreciated.
Especially the one about tables and addressing 0 rows, and how one might catch such occurrences???
Also your mention of "runaway loops", what do you mean by that? Perhaps an example might be handy there?
Also, what do you mean by "Creating blank tables every scene"?
My game missions work fine, in and of themselves. But each time I return to the Main Menu (a simple little scene), the memory does not go back down, it's always higher than it was the previous time that I was at the Main Menu.
Would these above cases you mention result in that?
I'm wondering whether there is any way that people know of to effectively flush out the memory usage when doing a scene change?
When I go back to the Main Menu scene, I want to get back as much memory as possible.
Is there any way to do this currently?
I basically want my game to perform a scene change, where it as-close-to-possible just dumps everything , and reloads the entire game.
I don't know where all the "Game Engine" and "Other" memory is being allocated to, and I have no idea how to clear it out from my end.
Is there any way for me to more closely inspect where that memory is going, what it's being allocated to, which actors are using it, which code or data it is being used by?
FYI: My game currently looks something like this on the memory usage:
Start: Aarrive at Main Menu scene:
Images 11.7mb, Sounds 9.5mb, Game Engine 15.3mb, Other 46.6mb, Total: 82.9mb.
After sitting on that scene for a while:
Images 11.7mb, Sounds 9.5mb, Game Engine 15.3mb, Other 46.4mb, Total: 83.0mb.
Start mission 1: Go to scene Game Mission (randomly generated mission values using table behaviours and stuff):
Images 6.7mb, Sounds 21.2mb, Game Engine 107.4mb, Other 62.0mb, Total: 170.0mb.
Started mission 2: Go to scene Game Mission
Images 6.7mb, Sounds 21.2mb, Game Engine 121.6mb, Other 66.0mb, Total: 219.0mb.
After playing that mission for a while:
Images 6.7mb, Sounds 21.2mb, Game Engine 107-130mb (builds up then flushes back down), Other 80mb, Total: 225.0mb.
After running around and doing more spawning of monsters in that level:
Images 7.6mb, Sounds 21.2mb, Game Engine 111.0mb (moves around), Other 87mb, Total: 235mb.
Memory caps in this one mission at these values, doesn't keep growing if I keep playing that one mission:
Images 7.7mb, Sounds 21.2mb, Game Engine 112mb, Other 93mb, Total: 237.3mb.
But after finishing a mission and returning to the main menu, a lot of memory never gets flushed. Just seems to fill up with junk, which builds and builds until it hangs.
Return to Main Menu and it's sitting at 229mb.
Images 10.7mb, Sounds 9.5mb, Game Engine 112mb, Other 96.1mb, Total: 229.2mb.
Load into another fresh randomised level: Go to scene Game Mission
Images 6.9mb, Sounds 21.2mb, Game Engine 153.6mb, Other 67.8mb, Total: 256.0mb.
Load into another randomised map: Go to scene Game Mission
Images 7.3mb, Sounds 21.2mb, Game Engine 213.7mb, Other 68.0mb, Total: 317.0mb.
CRASH! "Terminated due to memory pressure".
The pattern seems to be that each time I load into the Game Mission scene, it requires a bunch of memory to load everything in, but that is never fully recovered when returning to the Main Menu. If it were, I don't think my game would have any problems.
Is there any way to get the memory usage back down each time I go to the Main Menu?
Game Salad have acknowledged that there are memory leaks, and they are trying to fix them.
But @Hopscotch are you suggesting that I am perhaps/probably creating further memory leaks myself, which cannot be recovered by Game Salad, due to the way I'm using tables and other behaviours? Such as reading from "0 rows" in tables, etc?
I spent a lot of time about 6 months ago, going over all of those suggested issues, and ironed out any bugs relating to the "0 row" issues when that arose in one of the updates, and my game is not exhibiting the bugs that would have stemmed from reading from "0 rows", so I feel like I'm on top things in that regard.
I do use tables extensively in my project though, and I have a ton of global and local attributes in my project.
It's just that, the project was working fine in 10.4, and I could play 40+ randomly generated missions, and it was still going strong.
As the updates rolled in, the same project crashed out, and it's been basically shelved ever since, except for occasionally pulling it up and trying to fix the issues.
Like, perhaps I could have a behaviour in my Game Mission scene, where, once the payer has WON or LOST the level, I have the scene fade out, and have all actors destroy themselves, and wait a few seconds for Game Salad to do a memory cleanup, before changing scene? Am I cutting off Game Salad from being able to clean up memory by just ending my level and changing scene too rapidly?
Not that this is going to help anything, but I just want to take a moment to interject amidst all the crapping on the developers.
This is a BETA product, the first number of the build is 0, and the second number starts with a one. The site says beta everywhere, and it's never been claimed that it was a finished product - The team behind this product is offering pre-release accessibility for what is most likely a reduced price ($299/year) so that two things can happen:
They can source financing to work on this project
They have a solid user base with which to collect bugs and issues during development.
Believe it or not, building a game in an engine like this does not make one a developer, so it's understandable that people might not fully understand what goes into producing software like GameSalad - a framework that sits on top of an already established product (in this case, xCode and 'droid (Tizen.... windows.... mac... there's a LOT of compatibility to deal with)) to assist greater numbers of users to produce software using the underlying code.
It's not easy, and it's even less easy with the requirements, specifications, and restrictions that Apple puts on their software requirements - let alone the other vendors that they are targeting.
Here's the thing - when you purchase a license for software that is still in a beta state you accept the fact that:
The software may never actually be finished
The software may not always act as advertised
You forfeit the right to complain about the software's bugs because you have a dedicated pathway with which to file bugs.
It's ok to commiserate with others about brokenness. That's a natural side effect of the software's fragile state. It's not ok to call the developers childish names and accuse them of laziness and stupidity.
Signed:
A former software and web developer who's very, very tired of the development process and is quite grateful for frameworks such as this, quirks, difficulty, and weirdness included.
Edit: Still no pro logo on my posts. Guess the forum is in beta too
@Deviros said:
Not that this is going to help anything, but I just want to take a moment to interject amidst all the crapping on the developers.
This is a BETA product, the first number of the build is 0, and the second number starts with a one. The site says beta everywhere, and it's never been claimed that it was a finished product - The team behind this product is offering pre-release accessibility for what is most likely a reduced price ($299/year) so that two things can happen:
They can source financing to work on this project
They have a solid user base with which to collect bugs and issues during development.
Believe it or not, building a game in an engine like this does not make one a developer, so it's understandable that people might not fully understand what goes into producing software like GameSalad - a framework that sits on top of an already established product (in this case, xCode and 'droid (Tizen.... windows.... mac... there's a LOT of compatibility to deal with)) to assist greater numbers of users to produce software using the underlying code.
It's not easy, and it's even less easy with the requirements, specifications, and restrictions that Apple puts on their software requirements - let alone the other vendors that they are targeting.
Here's the thing - when you purchase a license for software that is still in a beta state you accept the fact that:
The software may never actually be finished
The software may not always act as advertised
You forfeit the right to complain about the software's bugs because you have a dedicated pathway with which to file bugs.
It's ok to commiserate with others about brokenness. That's a natural side effect of the software's fragile state. It's not ok to call the developers childish names and accuse them of laziness and stupidity.
Signed:
A former software and web developer who's very, very tired of the development process and is quite grateful for frameworks such as this, quirks, difficulty, and weirdness included.
Edit: Still no pro logo on my posts. Guess the forum is in beta too
Congratulations on just going Pro on a product that's basically being put aside for a different product line @Deviros
Game Salad is at the end of it's progressive development days. It'll continue to be supported, but development efforts - by the sounds of it - will be focussed on the new tool Graphene.
Game Salad has been Beta for about 5 years, and it's basically just a badge they hide behind. Game Salad will never be anything but a Beta product, despite what a normal human would expect from an application.
I don't think I've ever used it while it was anything but a Beta product. And I've been using it since late 2011.
So please, your post is a very old and worn line of thinking.
Welcome to Game Salad. I look forward to your future posts, which may well transmogrify to look more like ours over the coming weeks, as you swallow the red pill and realise what reality we are in here.
Please excuse the vitriol on my behalf. Much pain has flowed under this bridge over the years.
I wish you all the best, and there are definitely things you can do with Game Salad which are enjoyable and satisfying. Just keep your game as simple as possible, and don't push things. It only leads to pain.
@Hymloe, I am curious and keen to look into the issue with you. 3:30am here, so it will be in a little while.
I will ask you for some specifics in a PM if you don't mind. We can then present our findings here if something came out of it.
But first, make an ADHOC build and see how your game behaves. The Viewer is NOT a representation of how your app will behave memory wise on the device. As I have mentioned before, I never use it.
p.s. The red baseline on my image is just a marker to make it easy to see how memory increases and drops back to the previous level. Total memory fluctuating between 217mb (menu) and 224mb (level).
@Hopscotch said:
Hymloe, I am curious and keen to look into the issue with you. 3:30am here, so it will be in a little while.
I will ask you for some specifics in a PM if you don't mind. We can then present our findings here if something came out of it.
But first, make an ADHOC build and see how your game behaves. The Viewer is NOT a representation of how your app will behave memory wise on the device. As I have mentioned before, I never use it.
p.s. The red baseline on my image is just a marker to make it easy to see how memory increases and drops back to the previous level. Total memory fluctuating between 217mb (menu) and 224mb (level).
Sounds great, I'd love to see what you can make of the issue, and any discussion we can have about it, in private, or here, would be great.
I'm actually just pulling things out of my project, bit by bit, and writing down more results, to further investigate the project again in my lunch break.
@Hymloe Not sure why you keep avoiding the advice about doing an adhoc build. It has been advised more than once, at least acknowledge it. The viewer has major flaws, and if you look at the info you provided, its Game Engine which is causing the crash which is the viewer.
I think you'll find that "Game Engine" is not equal to "the viewer". It's the game engine.
I've tried Ad Hoc builds over the past year, and the result has always been the same as the viewer, so I'm not too fussed about using the Ad Hoc build to verify my tests.
The Ad Hoc build has never improved the crashing situation at all for me.
Man, there is SO MUCH mis-informed mysterious mumbo-jumbo and tom-foolery and hoodwinking that goes on around the Game Salad community.
I like to think I have a fairly firm grip on reality, despite obviously not entirely understanding everything that goes on behind the Game Salad curtains.
Sometimes I wish that Game Salad would publish actual in-depth detailed descriptions of how various behaviours and systems work, so we all know how to use them better.
Something that would be mega helpful would be to add some more info and debugging tools to the Viewer output, such as some way to log memory usage in more detail, or spit out assertions when behaviours are performing illegal or incomplete operations.
The reality is that an adhoc build is a more accurate representation than the GS viewer. So why not use all the tools at your disposal and try it at the current moment, you may just find that it works fine and can continue your game.
I am up there on the list of people who criticize GS, so this is in no way trying to defend them. Just trying to point out an alternate method of testing that may work out and save you from writing pages about the same issue.
@Lovejoy said:
The reality is that an adhoc build is a more accurate representation than the GS viewer. So why not use all the tools at your disposal and try it at the current moment, you may just find that it works fine and can continue your game.
I am up there on the list of people who criticize GS, so this is in no way trying to defend them. Just trying to point out an alternate method of testing that may work out and save you from writing pages about the same issue.
You are right of course. Thanks for the reminder. I've tried the AdHoc build on many times over the past year on many versions of GS, waiting for my game to come back to life, hoping it was just a Viewer problem. I have no reason to think that in this case, there's just some problem with the Viewer that won't appear in the Ad Hoc builds. This is not a new problem. It's just always getting worse, instead of better.
I just spent about 3 hours trying to figure out what the problem is again, by deleting and deactivating whole sets of actors and behaviours, but I'm really none the wiser after all that work.
I'm really hoping that GS team can figure it out in the coming week, once and for all, and put my long long journey to a joyous end.
@Hymloe I would def try an adhoc and use the Xcode instruments to evaluate performance. Much better then the GS tools (better breakdowns and options, more accurate). My guess tho is if you are seeing up to 300mb+ used it will still have some issues via adhoc, but who knows?
@JSproject said:
QASalad and BlackCloakGS I can confirm that there is a major bug in 0.12.20 "stable" which will crash apps on "iPad mini" (1st gen) and "iPad 2" and soon after loading which in practice renders builds made by 0.12.20 unusable on older devices.
GS developers can expect bad reviews coming from reviewers cause of crashes on such devices. This is not any small little thing that may go unnoticed.
What Figuromo and Hymloe and supafly129 wrote above made me bring out some older devices and run some quick tests with the following results:
Note: The tests below were done using the exact same project version with no changes done in the project between testing adhocs in the two versions below.
Devices tested with adhoc builds;
iPad 2 running IOS 7.1.1
iPad Mini running IOS 6.1.2
iPad Mini (2) retina running IOS 8.1.2
iPad 3 running IOS 8.1.2
iPad Air (1) running IOS 8.1.2
Publishing build settings:
Universal Build
Overscan
Legacy resolution independence (so 1x and 2x images were produced)
Published adhoc build using: GS 0.11.0.13
Result: All devices loads the app and it's possible to play the game for quite some time without any issue
Published adhoc build using: GS 0.12.20 "stable"
Result: All devices loads the app but within 2 minutes after playing the game it will crash on iPad 2 and iPad Mini. The Mini 2 and Air seem to perform as the 0.11.0.13 build.
Since the iPad Mini and iPad 2 both have 512 MB of RAM I suspect the issue is related to that for 0.12.20 builds.
Recordings using xcode instruments may be helpful for the GS team here, I did not do that in these initial tests.
(Tested ok: The Air and Mini 2 retina which both have 1 GB RAM and are 64-bit devices, the iPad 3 has 1GB RAM and is 32-bit).
To the community and the GS-team:
The easiest way to reproduce this on iPad 2 and iPad Mini (1) is probably to load up an 0.12.20 adhoc of any graphic intense game and just play it for a couple of minutes and then enjoy the crash
In my opinion it is way to early to kill off support for iPad 2 and iPad Mini at this point.
I would feel so much better if someone from GS would reply to this post and confirm that this is a bug and not the new memory base usage, and that we will get a hot fix in the near future.
Comments
Every game I've worked on at professional game dev studios had memory issues. You just get someone to clean them up at the end. Game Salad needs to do just that.
Why are you saying what you're saying? Why would you just write a post regurgitating the same unacceptable excuses Game Salad have given for the memory issues?
They need to be fixed.
I have my suspicions that you don't actually understand the contents of that comment, @ForumNinja.
It doesn't even really make sense to me, the way it's written. What does it mean?
Could you explain it for us in more detail @ForumNinja?
I would suggest that it is not a workaround that would benefit those of us having the problem, seeing our projects may already be intrinsically built around parts of Game Salad that should work, but may have these memory related issues.
@BenSawyer, perhaps you can explain in more detail here, in more detail, because I find it hard to follow what you're saying on the comment on bug 103.
I appreciate the input, and the workaround. But that's not really feasable for us to transfer every piece of table data to a self attribute first, nor is that the only issue at hand. That's basically asking us to rewrite our code because a core aspect of the engine is leaking memory.
Follow us: Twitter - Website
They obviously had a good code base structure where this is a relatively easy process. From everything I have seen over the time I have been here I can deduce this is not the case with Creator otherwise it would have been fixed long ago.
I am in no way apologising for GS I am simply saying what I believe to be the case. Doesn't even mean I am correct it is just the conclusion I came to from what I have seen and experienced here.
They are fixing it in the long term by creating Graphine. In the short term I have accepted this is where it's at and like everyone else am waiting for Creator to be fixed so I can move forward. I don't like it and wish the original GS team had done a much better job but unfortunately they didn't.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
GS, close your ears and keep working!
@MarcMySalad, @Hymloe, unfortunately I do not share your experience.
Here is 10 minutes playtime (as an adhoc) of a "heavy" game, scene 8732px wide, 130 actors, 102 of them with animations, rules, etc. Table functions and numerous scene changes. Most images and animations are 1024x1024px,
Checked Allocations, Leaks, VMMemory, PageFaults, everything runs fine.
I get the same results in a wild shooter where dozens of projectiles and enemies get spawned and destroyed every second.
From what you describe I suspect one of the following culprits:
Maybe you would consider a dev of your choice here to help look at your project. Who knows, it may be a small issue and you are ready to publish tomorrow.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
You sure left out important information here. What device is this running on? How does this compare to usage in previous versions of the creator? What's the actual memory usage? What about 2048x2048 textures? Just a vague timeline screenshot showing a normal range without spikes or warnings.
You aren't the only one using instruments who knows a thing or two. I gave a breakdown earlier in the thread of devices and there usage and referenced previous stables performance metrics for comparison.
Gs pretty much acknowleges there are memory leaks in this thread and in the bugs section, yet here you are telling people it's because they don't know how to code and to hire a dev? HAH. It's an issue, not as big as everyone is making it out to be, but don't try and say it's not.
Follow us: Twitter - Website
@AlchimiaStudios, the above tests I did where iPad4 and iPhone5. The point being discussed was alleged memory increase by images, not if the device could handle it.
I never use 2048x2048 images. I tile or break scene backgrounds into patchwork elements. GS is good at throwing lots of images around, old devices however are bad and slow at loading big images. To accommodate old devices I keep the images smaller and build up the scene at run time. GS is great at swapping images in and out of memory as long as you give it room to breathe. Same with any other dev environment. This way they even run fine on old Android devices through the funny Amazon wrapper.
GS may acknowledge memory leaks and there probably are, and these should be fixed. However, not to the extent of crippling your game.
If I said that they can't code, then it applies to me too. The examples I gave, trip me up all the time.
Oh, and I did not offer any services for hire. If I were to help them it would be purely out of selfish reasons to get a pat on the back in the unlikely event of being of help. No amount of money can compensate taking me out of my development time.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Weather the device can handle it is directly related to memory usage. The reason I say it's not as big an issue as it's made out to be is because the performance is causing crashes on device with 512mb of ram. Older devices only. So worst case scenario, you drop support for them.
But let's talk about how this could be possibly be "crippling to your game".
On those devices with 512mb; 256mb is the threshold for a crash, as you can imagine going from 210-220mb used to 256mb used can be an easy threshold to cross. A small leak or increased usage from the engines versions could cause this crash.
Going from 350 to 512mb (limit for 1gb devices) used is a much larger threshold and would allow for small increases from the engine without much notice.
So you can see how it could cripple a game. This is why "large projects" are being discussed because they could be performing close to the limits and be fine in one build and then a few releases later small things change and you can no longer get an acceptable run time performance on the same app that was working before.
I personally wasn't saying you were advertising yourself as a work for hire, rather that the comment in general was a bit demeaning and unnecessary.
Follow us: Twitter - Website
Here is a good idea everyone:
I just voted for this and I also unchecked all my other votes. If we all do that this will go to the top of the list quickly and something may be done sooner than later.
When the memory issue is fixed and apps stop crashing you can put your other votes back.
As I've said before, Admob and collision areas don't matter a ^ if we can't get our apps approved!
Hi,
Been reading all the posts in here, and this is my opinion:
1) I think Game Salad should focus on fixing the memory issues until 0.13.0 version, this is the final version for Game Salad Creator and stop updating for Mac and Windows.
2) This will give time for the Programmers to focus on the new engine Graphene SDK, to roll out Beta ( Test ) and finally have a Stable Version out to the community.
This is just my humble opinion...I would rather have Gamesalad Staff focus on Graphene SDK and just retire Game Salad Creator after 0.13.0 comes out. If not, I fear that we may have to wait 6 months - 1 Year for the release of Graphene SDK ( Hope I'm wrong ...)
As for myself, I have a game that I will be releasing with the current Game Salad Creator, and afterwards, I will wait for Graphene SDK, I can't get another Pro Subscription which expires on 2 / 2015. I would rather wait for Graphene SDK to see the Pro's and Con's. Meanwhile, I'm already using another Game Engine and teaching myself Objective C, which for a newbie, it's not that bad, thought it was going to be harder......God Bless...
Sincerely,
Sunday
@luke2125 I know you are stating your opinion, but please realize the flaws in it.
1) GS can not simply be a final version, the app stores are constantly changing and require necessary changes (ex. 64-bit support). This is out of gamesalad's hands.
Stop updating it and we all will be unable to do anything with it, hence no need to pay for pro and essentially hurt Gamesalad as a whole.
2) The flaws stated on point 1 explain why this is not an option.
There a lot more to it, and hopefully you realize it.
Fortuna Infortuna Forti Una
Yep, I found GS un-usable on Yosemite, and had a LOT of trouble even TRYING these new versions of GS, because I had to move from 10.8.5 to 10.9.4 just so I could get the right version of XCode so I could compile the Viewer over to my iPad.
It was actually a bit of a nightmare, all caused by Game Salad not support Yosemite.
Unsure when it will work on Yosemite....???
What does the graph show there, @Hopscotch ? Is the red line the point where the device will crap out? Or just showing the max memory it hit? What amount of memory is that, that your game gets to?
If you could go into more detail on some of those suggestions you've made, that would be much appreciated.
Especially the one about tables and addressing 0 rows, and how one might catch such occurrences???
Also your mention of "runaway loops", what do you mean by that? Perhaps an example might be handy there?
Also, what do you mean by "Creating blank tables every scene"?
My game missions work fine, in and of themselves. But each time I return to the Main Menu (a simple little scene), the memory does not go back down, it's always higher than it was the previous time that I was at the Main Menu.
Would these above cases you mention result in that?
I'm wondering whether there is any way that people know of to effectively flush out the memory usage when doing a scene change?
When I go back to the Main Menu scene, I want to get back as much memory as possible.
Is there any way to do this currently?
I basically want my game to perform a scene change, where it as-close-to-possible just dumps everything , and reloads the entire game.
I don't know where all the "Game Engine" and "Other" memory is being allocated to, and I have no idea how to clear it out from my end.
Is there any way for me to more closely inspect where that memory is going, what it's being allocated to, which actors are using it, which code or data it is being used by?
FYI: My game currently looks something like this on the memory usage:
Start: Aarrive at Main Menu scene:
Images 11.7mb, Sounds 9.5mb, Game Engine 15.3mb, Other 46.6mb, Total: 82.9mb.
After sitting on that scene for a while:
Images 11.7mb, Sounds 9.5mb, Game Engine 15.3mb, Other 46.4mb, Total: 83.0mb.
Start mission 1: Go to scene Game Mission (randomly generated mission values using table behaviours and stuff):
Images 6.7mb, Sounds 21.2mb, Game Engine 107.4mb, Other 62.0mb, Total: 170.0mb.
Started mission 2: Go to scene Game Mission
Images 6.7mb, Sounds 21.2mb, Game Engine 121.6mb, Other 66.0mb, Total: 219.0mb.
After playing that mission for a while:
Images 6.7mb, Sounds 21.2mb, Game Engine 107-130mb (builds up then flushes back down), Other 80mb, Total: 225.0mb.
After running around and doing more spawning of monsters in that level:
Images 7.6mb, Sounds 21.2mb, Game Engine 111.0mb (moves around), Other 87mb, Total: 235mb.
Memory caps in this one mission at these values, doesn't keep growing if I keep playing that one mission:
Images 7.7mb, Sounds 21.2mb, Game Engine 112mb, Other 93mb, Total: 237.3mb.
But after finishing a mission and returning to the main menu, a lot of memory never gets flushed. Just seems to fill up with junk, which builds and builds until it hangs.
Return to Main Menu and it's sitting at 229mb.
Images 10.7mb, Sounds 9.5mb, Game Engine 112mb, Other 96.1mb, Total: 229.2mb.
Load into another fresh randomised level: Go to scene Game Mission
Images 6.9mb, Sounds 21.2mb, Game Engine 153.6mb, Other 67.8mb, Total: 256.0mb.
Load into another randomised map: Go to scene Game Mission
Images 7.3mb, Sounds 21.2mb, Game Engine 213.7mb, Other 68.0mb, Total: 317.0mb.
CRASH! "Terminated due to memory pressure".
The pattern seems to be that each time I load into the Game Mission scene, it requires a bunch of memory to load everything in, but that is never fully recovered when returning to the Main Menu. If it were, I don't think my game would have any problems.
Is there any way to get the memory usage back down each time I go to the Main Menu?
Game Salad have acknowledged that there are memory leaks, and they are trying to fix them.
But @Hopscotch are you suggesting that I am perhaps/probably creating further memory leaks myself, which cannot be recovered by Game Salad, due to the way I'm using tables and other behaviours? Such as reading from "0 rows" in tables, etc?
I spent a lot of time about 6 months ago, going over all of those suggested issues, and ironed out any bugs relating to the "0 row" issues when that arose in one of the updates, and my game is not exhibiting the bugs that would have stemmed from reading from "0 rows", so I feel like I'm on top things in that regard.
I do use tables extensively in my project though, and I have a ton of global and local attributes in my project.
It's just that, the project was working fine in 10.4, and I could play 40+ randomly generated missions, and it was still going strong.
As the updates rolled in, the same project crashed out, and it's been basically shelved ever since, except for occasionally pulling it up and trying to fix the issues.
Like, perhaps I could have a behaviour in my Game Mission scene, where, once the payer has WON or LOST the level, I have the scene fade out, and have all actors destroy themselves, and wait a few seconds for Game Salad to do a memory cleanup, before changing scene? Am I cutting off Game Salad from being able to clean up memory by just ending my level and changing scene too rapidly?
@Hymloe Try doing an Adhoc build, the viewer is not the best for testing.
Fortuna Infortuna Forti Una
Not that this is going to help anything, but I just want to take a moment to interject amidst all the crapping on the developers.
This is a BETA product, the first number of the build is 0, and the second number starts with a one. The site says beta everywhere, and it's never been claimed that it was a finished product - The team behind this product is offering pre-release accessibility for what is most likely a reduced price ($299/year) so that two things can happen:
Believe it or not, building a game in an engine like this does not make one a developer, so it's understandable that people might not fully understand what goes into producing software like GameSalad - a framework that sits on top of an already established product (in this case, xCode and 'droid (Tizen.... windows.... mac... there's a LOT of compatibility to deal with)) to assist greater numbers of users to produce software using the underlying code.
It's not easy, and it's even less easy with the requirements, specifications, and restrictions that Apple puts on their software requirements - let alone the other vendors that they are targeting.
Here's the thing - when you purchase a license for software that is still in a beta state you accept the fact that:
It's ok to commiserate with others about brokenness. That's a natural side effect of the software's fragile state. It's not ok to call the developers childish names and accuse them of laziness and stupidity.
Signed:
A former software and web developer who's very, very tired of the development process and is quite grateful for frameworks such as this, quirks, difficulty, and weirdness included.
Edit: Still no pro logo on my posts. Guess the forum is in beta too
Congratulations on just going Pro on a product that's basically being put aside for a different product line @Deviros
Game Salad is at the end of it's progressive development days. It'll continue to be supported, but development efforts - by the sounds of it - will be focussed on the new tool Graphene.
Game Salad has been Beta for about 5 years, and it's basically just a badge they hide behind. Game Salad will never be anything but a Beta product, despite what a normal human would expect from an application.
I don't think I've ever used it while it was anything but a Beta product. And I've been using it since late 2011.
So please, your post is a very old and worn line of thinking.
Welcome to Game Salad. I look forward to your future posts, which may well transmogrify to look more like ours over the coming weeks, as you swallow the red pill and realise what reality we are in here.
Please excuse the vitriol on my behalf. Much pain has flowed under this bridge over the years.
I wish you all the best, and there are definitely things you can do with Game Salad which are enjoyable and satisfying. Just keep your game as simple as possible, and don't push things. It only leads to pain.
@Hymloe, I am curious and keen to look into the issue with you. 3:30am here, so it will be in a little while.
I will ask you for some specifics in a PM if you don't mind. We can then present our findings here if something came out of it.
But first, make an ADHOC build and see how your game behaves. The Viewer is NOT a representation of how your app will behave memory wise on the device. As I have mentioned before, I never use it.
p.s. The red baseline on my image is just a marker to make it easy to see how memory increases and drops back to the previous level. Total memory fluctuating between 217mb (menu) and 224mb (level).
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
http://bugs.gamesalad.com/page.cgi?id=voting/user.html&bug_id=729#vote_729
We're at 7 votes for memory cleanup. Come on guys we can do better then that.
Sounds great, I'd love to see what you can make of the issue, and any discussion we can have about it, in private, or here, would be great.
I'm actually just pulling things out of my project, bit by bit, and writing down more results, to further investigate the project again in my lunch break.
Look forward to talking to you via PM. Cheers!
@Hymloe Not sure why you keep avoiding the advice about doing an adhoc build. It has been advised more than once, at least acknowledge it. The viewer has major flaws, and if you look at the info you provided, its Game Engine which is causing the crash which is the viewer.
Fortuna Infortuna Forti Una
I think you'll find that "Game Engine" is not equal to "the viewer". It's the game engine.
I've tried Ad Hoc builds over the past year, and the result has always been the same as the viewer, so I'm not too fussed about using the Ad Hoc build to verify my tests.
The Ad Hoc build has never improved the crashing situation at all for me.
Man, there is SO MUCH mis-informed mysterious mumbo-jumbo and tom-foolery and hoodwinking that goes on around the Game Salad community.
I like to think I have a fairly firm grip on reality, despite obviously not entirely understanding everything that goes on behind the Game Salad curtains.
Sometimes I wish that Game Salad would publish actual in-depth detailed descriptions of how various behaviours and systems work, so we all know how to use them better.
Something that would be mega helpful would be to add some more info and debugging tools to the Viewer output, such as some way to log memory usage in more detail, or spit out assertions when behaviours are performing illegal or incomplete operations.
The reality is that an adhoc build is a more accurate representation than the GS viewer. So why not use all the tools at your disposal and try it at the current moment, you may just find that it works fine and can continue your game.
I am up there on the list of people who criticize GS, so this is in no way trying to defend them. Just trying to point out an alternate method of testing that may work out and save you from writing pages about the same issue.
Fortuna Infortuna Forti Una
Thanks @Lovejoy,
You are right of course. Thanks for the reminder. I've tried the AdHoc build on many times over the past year on many versions of GS, waiting for my game to come back to life, hoping it was just a Viewer problem. I have no reason to think that in this case, there's just some problem with the Viewer that won't appear in the Ad Hoc builds. This is not a new problem. It's just always getting worse, instead of better.
I just spent about 3 hours trying to figure out what the problem is again, by deleting and deactivating whole sets of actors and behaviours, but I'm really none the wiser after all that work.
I'm really hoping that GS team can figure it out in the coming week, once and for all, and put my long long journey to a joyous end.
@Hymloe I would def try an adhoc and use the Xcode instruments to evaluate performance. Much better then the GS tools (better breakdowns and options, more accurate). My guess tho is if you are seeing up to 300mb+ used it will still have some issues via adhoc, but who knows?
Follow us: Twitter - Website
We all want that my friend, we are part of the same team here.
Fortuna Infortuna Forti Una
I would feel so much better if someone from GS would reply to this post and confirm that this is a bug and not the new memory base usage, and that we will get a hot fix in the near future.