@Hopscotch said:
As GS evolves and features get added, the base memory useage will necessarily increase. This is due to features that the community requests/demands to be in GS.
Just Facebook integration alone will increase memory usage by another 1mb. This cannot be seen as a bug.
I think we may benefit from being able to select some GS features as being INCLUDED or NOT INCLUDED in our specific apps, depending on if we use those features or not.
Because I agree with @Figuromo that GS just keeps sucking up more memory with each release, meaning apps that did work before, stop working as time goes on.
Sure, there's a certain "law of nature" to that, as new fancier devices come out, and the Apple iOS gets updated... but it'd be closer to ideal if we could keep our apps leaner if we're not even using all the new potentially bloated GS features, for example.
@mshuraih said:
does anyone have the problem when you try to delete an image from the images library ,, you select the image and you end up deleting the neighboring image ,.. and occasionally deleting one next to it ! is this a known bug
Dude, that's been a problem for about 4 years.
I think GS are "right on top of it". [/sarcasm]
I'd suggest, if you're going to delete an asset from the game, whether an image or anything really, it can be wise to quit Game Salad, open your project fresh, do the delete, then save, quit Game Salad, reload, then keep working.
@MarcMySalad said:
I wouldn't recommand that since if you delete it outside of GS then you will have a reference in at least one of the xml-files, created by GS, to an image file that no longer exist.
Also, in the past I've tried multiple times to delete images directly within the Creator, but it seems to never delete the images I select.
Right now I'm not willing to update to the latest build due to these memory issues (my latest games were pushing older devices to the max already) - so publishing new games to Apple is no longer an option.
Also - Amazon are no longer accepting games published with GS due to the ongoing audio issue AND now the new requirement with the back/home button (which I have just had an Amazon app rejected for).
So right now (for me anyway) the only store I'm able/willing to publish new games to is Google... which ain't good!!
@DigiChain I'm in a similar situation except I did publish recently and now I'm getting bombarded with bad reviews due to frequent crashes. Which of course has cut my downloads in half.
They be too busy with Graphene to give a damn. Atleast, their lack of response on the manner seems to suggest so.
Shows a status of confirmed. We know they are aware of it at least. I believe similar bugs have also been confirmed and had some comments added to them, so were not totally in the dark, just no solid info of when we might see some fixes.
We will be looking at the memory issues for the engine next week. We had already started on some project before the bug was submitted and we can't switch any sooner.
It'd be great to see some more rigorous QA on Stable Builds especially, where QA take a set of pre-existing projects through a series of steps, recording the resulting memory usage, performance, and stability, which would hopefully result in Stable Releases being much more solid platforms for us all to work with out here in the real world.
Always having a current stable release to work on is probably the number 1 most important thing for all Game Salad users, so you should make that a #1 priority and ensure that always happens. That's why there's Nightly Builds, Release Candidates, and Stable Releases.
PhilipCCEncounter Bay, South AustraliaMemberPosts: 1,390
Always having a current stable release to work on is probably the number 1 most important thing for all Game Salad users, so you should make that a #1 priority and ensure that always happens.
Hear, here!
I don't want to spoil the new thread about RC 0.13.3 and GamePad support, or put a damper on all the accolades being bestowed on @BlackCloakGS for his solo accomplishment, but I have to say here that it stings a lot that the not-so-stable 0.12.20 has been languishing away, dead in the water, for far too long while this other stuff was undertaken.
Been very busy with work for the last six months at least and over that time the state of GameSalad has been so poor it's shocking.
I was happy to see the engine refined from the coding side, and have bugs fixed. But in comparison to two years ago, things are way more buggy.
Why have things gone so downhill these last couple of years to the point where things that worked fine no-longer do, and promised things never arrive.
In some ways I wish I could rewind my machines to Mountain Lion and GameSalad back to when it was not full of bugs that make it completely unusable and useless.
Very disappointed
Bugs I reported which make any game that's got GameCenter and is widescreen unplayable in the viewer still exist making the viewer useless. I don't want to have to turn rules off to make the software run.
@BlackCloakGS I cannot build our production game Word Wow with 0.12.20.0. I was trying to put out an update to find that the Adhoc build would not load... Viewer seems to work. Obviously it builds fine with previous versions as it's been in the store for the last 9 months. Really worried here, as I can't update our game anymore since we need the 64bit support. I'd gladly go back to a previous version if I could.
I submitted a support ticket for this. Can you please look at this? There's nothing for us to leverage as a workaround, we are completely stuck.
@clee2005 said:
BlackCloakGS I cannot build our production game Word Wow with 0.12.20.0. I was trying to put out an update to find that the Adhoc build would not load... Viewer seems to work. Obviously it builds fine with previous versions as it's been in the store for the last 9 months. Really worried here, as I can't update our game anymore since we need the 64bit support. I'd gladly go back to a previous version if I could.
I submitted a support ticket for this. Can you please look at this? There's nothing for us to leverage as a workaround, we are completely stuck.
You can submit app updates with 32-bit gamesalad creator until June or so. 64-bit binaries are only required for new apps submitted.
I know this isn't a fix to your problem, but if its a critical update then just wanted to let you know you can submit it with the older creator version.
Fortuna Infortuna Forti Una
PhilipCCEncounter Bay, South AustraliaMemberPosts: 1,390
edited February 2015
@clee2005 said:
BlackCloakGS I cannot build our production game Word Wow with 0.12.20.0. I was trying to put out an update to find that the Adhoc build would not load... Viewer seems to work. Obviously it builds fine with previous versions as it's been in the store for the last 9 months. Really worried here, as I can't update our game anymore since we need the 64bit support. I'd gladly go back to a previous version if I could.
I submitted a support ticket for this. Can you please look at this? There's nothing for us to leverage as a workaround, we are completely stuck.
Someone else posted yesterday that they are still successfully building 32 bit updates with 0.12.10. Sorry but I can't find the thread. It is in one of these epic threads! As mentioned elsewhere you have until 1 June before 64 bit updates are mandatory.
@Lovejoy said:
I know this isn't a fix to your problem, but if its a critical update then just wanted to let you know you can submit it with the older creator version.
Thanks @Lovejoy and @PhilipCC ! I didn't realize this. You're right it's definitely not a fix, and I'm still VERY concerned about the future of our most successful game. But thank you very much for the information, cause at least I can continue with our update.
@BlackCloakGS said:
We will be looking at the memory issues for the engine next week. We had already started on some project before the bug was submitted and we can't switch any sooner.
Despite the noise about images, they are not the culprit. Here an evaluation of a graphics and animation intensive project. No memory creep. The dips are changes to different scenes. Memory builds and recovers as expected.
There may well be some minor leaks related to images, the real evil though, is ...
TABLES
Here a results from a project, NO IMAGES, only table functions. Memory jumps on table actions and never releases between scenes.
0.12.20
Now in 0.13.2
Only table behaviours. Every single one bloats memory:
@Hopscotch Nicely illustrated. As most of us know using tables in GS is basically a must for any bigger project. Do you have a bigger one-scene project that makes heavy use of tables in combination with lots of high-res images? (or create one for simulation) If so supervise that the same way over some time in instruments, you are likely to find memory leakage in 0.12.20 that will crash your app.
Just as you indicate the memory leakage might not be directly (or at all) related to images alone, however if you have a project that makes use of retina images with lots of images and animations that in combination with table related bugs in 0.12.20 might be what tips the water in the cup over the edge.
Leaks in relation to tables should therefore, in my opinion, be very high on the priority list to be fixed - it's not something that should be pushed for the future "0.13" build.
Even though your illustration points to even bigger issues in "0.13.2" (issues can be expected since its a development build) what matters right now is fixing such bugs / memory leakage / major issues for the current "stable" version / 0.12.20.
Agreed @JSproject, these things need to be addressed right away.
My big worry is everyone pointing at images. So GS will waste days on a wild goose chase, finding a minor leak and confidently presenting the next stable build. Another week gone without real results.
Here is what a graphics heavy project WITH table functions looks like. Notice that the memory size overall increases, but not the range of dynamic allocation and deallocation of image memory. Again, big projects falling over is because table functions bloat the memory and never get released.
(v0.12.20 results)
Multi or single scene makes no difference. The increase in memory due to table functions never gets released.
I want to help point the GS team in the right direction so we can have some real results.
@JSproject, single scene or not, make no difference. The linked project started as a single scene, then added the more to see if memory gets released. No difference, memory just accumulates.
To note as well, using or avoiding timers, loops and constrains, also makes no difference as far as I can tell.
@neoman said:
Amazon is getting more strict now in the review process and are rejecting apps as during game play if you press the back button the app exists then starts from the beginning when you relaunch it ... Here is the official reply from the Amazon app review team.
FAILED TESTING
Observation:- Others :
Steps to reproduce:
1.Install & launch the app.
2.Tap on "Play" & start playing the game.
3.During playing tap on device back button.
4.App exits to device home screen, once again launch, app restarts.
I tried to program the back button so it goes back to the menu scene similar to what we did with Tizen but the engine does not pick up the code.
@QASalad or @BlackCloakGS Can someone from the GS team provide an answer to what we can do to solve this issue ? I would appreciate if someone could take 30 seconds to post an update for this issue. Thank you.
Fantastic work @Hopscotch for capturing memory issues!
I'm so glad @Hopscotch understands how to track memory usage and setup the appropriate tests to appropriately illustrate this problem.
Being a non-programmer myself, I've struggled to really get this issue illustrated. So this is a great step in the right direction.
I've posted links to this page of this thread, as well as directly to Hopscotch's video, and sample project file, on the page for Bug #729... to make sure that whoever the bug gets assigned to will hopefully see this very useful test info that Hopscotch has provided.
Comments
I think we may benefit from being able to select some GS features as being INCLUDED or NOT INCLUDED in our specific apps, depending on if we use those features or not.
Because I agree with @Figuromo that GS just keeps sucking up more memory with each release, meaning apps that did work before, stop working as time goes on.
Sure, there's a certain "law of nature" to that, as new fancier devices come out, and the Apple iOS gets updated... but it'd be closer to ideal if we could keep our apps leaner if we're not even using all the new potentially bloated GS features, for example.
Dude, that's been a problem for about 4 years.
I think GS are "right on top of it". [/sarcasm]
I'd suggest, if you're going to delete an asset from the game, whether an image or anything really, it can be wise to quit Game Salad, open your project fresh, do the delete, then save, quit Game Salad, reload, then keep working.
Seems to make it work more reliably.
Also, in the past I've tried multiple times to delete images directly within the Creator, but it seems to never delete the images I select.
POLAR ROLLOUT (New Line-Drawing Physics Puzzler!) - FREE Download
This is all another language -__- lol
I was wrong, my apologies. UPDATED apps can be 32 bit to 1st June... "only" NEW apps have to offer 64 bit since 1st February...
Hmm.. this is all rather worrying.
Right now I'm not willing to update to the latest build due to these memory issues (my latest games were pushing older devices to the max already) - so publishing new games to Apple is no longer an option.
Also - Amazon are no longer accepting games published with GS due to the ongoing audio issue AND now the new requirement with the back/home button (which I have just had an Amazon app rejected for).
So right now (for me anyway) the only store I'm able/willing to publish new games to is Google... which ain't good!!
@DigiChain I'm in a similar situation except I did publish recently and now I'm getting bombarded with bad reviews due to frequent crashes. Which of course has cut my downloads in half.
They be too busy with Graphene to give a damn. Atleast, their lack of response on the manner seems to suggest so.
http://bugs.gamesalad.com/show_bug.cgi?id=729
Shows a status of confirmed. We know they are aware of it at least. I believe similar bugs have also been confirmed and had some comments added to them, so were not totally in the dark, just no solid info of when we might see some fixes.
Follow us: Twitter - Website
@BlackCloakGS @QASalad @ForumNinja any updates or idea on when these issues will officially be addressed?
POLAR ROLLOUT (New Line-Drawing Physics Puzzler!) - FREE Download
We will be looking at the memory issues for the engine next week. We had already started on some project before the bug was submitted and we can't switch any sooner.
@BlackCloakGS Thanks for the update.
Follow us: Twitter - Website
It'd be great to see some more rigorous QA on Stable Builds especially, where QA take a set of pre-existing projects through a series of steps, recording the resulting memory usage, performance, and stability, which would hopefully result in Stable Releases being much more solid platforms for us all to work with out here in the real world.
Always having a current stable release to work on is probably the number 1 most important thing for all Game Salad users, so you should make that a #1 priority and ensure that always happens. That's why there's Nightly Builds, Release Candidates, and Stable Releases.
Hear, here!
I don't want to spoil the new thread about RC 0.13.3 and GamePad support, or put a damper on all the accolades being bestowed on @BlackCloakGS for his solo accomplishment, but I have to say here that it stings a lot that the not-so-stable 0.12.20 has been languishing away, dead in the water, for far too long while this other stuff was undertaken.
I'd like to update 2 of my existing games, but feel totally unsure / unconfident about which of many dodgy builds I should be using.
I should be able to confidently go to the latest Stable Build, at any time, and publish a game through it.
Full stop.
Been very busy with work for the last six months at least and over that time the state of GameSalad has been so poor it's shocking.
I was happy to see the engine refined from the coding side, and have bugs fixed. But in comparison to two years ago, things are way more buggy.
Why have things gone so downhill these last couple of years to the point where things that worked fine no-longer do, and promised things never arrive.
In some ways I wish I could rewind my machines to Mountain Lion and GameSalad back to when it was not full of bugs that make it completely unusable and useless.
Very disappointed
Bugs I reported which make any game that's got GameCenter and is widescreen unplayable in the viewer still exist making the viewer useless. I don't want to have to turn rules off to make the software run.
The viewer is still showing @1x images too.
Can't publish games to the view most of the time, GameSalad just hangs.
If I can't even do these basic fundamental things, what faith can I have the game that I publish is not going to be hindered by crashes?
It's all rather sad - I hope things will get better when I get full steam back in to my game dev.
@BlackCloakGS I cannot build our production game Word Wow with 0.12.20.0. I was trying to put out an update to find that the Adhoc build would not load... Viewer seems to work. Obviously it builds fine with previous versions as it's been in the store for the last 9 months. Really worried here, as I can't update our game anymore since we need the 64bit support. I'd gladly go back to a previous version if I could.
I submitted a support ticket for this. Can you please look at this? There's nothing for us to leverage as a workaround, we are completely stuck.
Our games http://Donkeysoft.ca
You can submit app updates with 32-bit gamesalad creator until June or so. 64-bit binaries are only required for new apps submitted.
I know this isn't a fix to your problem, but if its a critical update then just wanted to let you know you can submit it with the older creator version.
Fortuna Infortuna Forti Una
Someone else posted yesterday that they are still successfully building 32 bit updates with 0.12.10. Sorry but I can't find the thread. It is in one of these epic threads!
As mentioned elsewhere you have until 1 June before 64 bit updates are mandatory.
Thanks @Lovejoy and @PhilipCC ! I didn't realize this. You're right it's definitely not a fix, and I'm still VERY concerned about the future of our most successful game. But thank you very much for the information, cause at least I can continue with our update.
Cheers,
Chris
Our games http://Donkeysoft.ca
So I went back and can confirm that 0.12.10.0 builds the same code fine and produces a working Adhoc. Something significant changed in 0.12.20.0
Our games http://Donkeysoft.ca
(Don't miss the video at the bottom)
Great @BlackCloakGS !
Despite the noise about images, they are not the culprit. Here an evaluation of a graphics and animation intensive project. No memory creep. The dips are changes to different scenes. Memory builds and recovers as expected.
There may well be some minor leaks related to images, the real evil though, is ...
TABLES
Here a results from a project, NO IMAGES, only table functions. Memory jumps on table actions and never releases between scenes.
0.12.20
Now in 0.13.2
Only table behaviours. Every single one bloats memory:
Copy Table
Removing or adding rows
Changing cell values
Getting cell values
Leaving the scene never releases memory either!
And a video:
Project file attached.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
@Hopscotch Nicely illustrated. As most of us know using tables in GS is basically a must for any bigger project. Do you have a bigger one-scene project that makes heavy use of tables in combination with lots of high-res images? (or create one for simulation) If so supervise that the same way over some time in instruments, you are likely to find memory leakage in 0.12.20 that will crash your app.
Just as you indicate the memory leakage might not be directly (or at all) related to images alone, however if you have a project that makes use of retina images with lots of images and animations that in combination with table related bugs in 0.12.20 might be what tips the water in the cup over the edge.
Leaks in relation to tables should therefore, in my opinion, be very high on the priority list to be fixed - it's not something that should be pushed for the future "0.13" build.
Even though your illustration points to even bigger issues in "0.13.2" (issues can be expected since its a development build) what matters right now is fixing such bugs / memory leakage / major issues for the current "stable" version / 0.12.20.
Agreed @JSproject, these things need to be addressed right away.
My big worry is everyone pointing at images. So GS will waste days on a wild goose chase, finding a minor leak and confidently presenting the next stable build. Another week gone without real results.
Here is what a graphics heavy project WITH table functions looks like. Notice that the memory size overall increases, but not the range of dynamic allocation and deallocation of image memory. Again, big projects falling over is because table functions bloat the memory and never get released.
(v0.12.20 results)
Multi or single scene makes no difference. The increase in memory due to table functions never gets released.
I want to help point the GS team in the right direction so we can have some real results.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Amazing. Your test project looks to illustrate the issues with tables perfectly.
I hope this helps shed light on the issue for GS. Fixing this will let me get back to my long languishing game project!
Nice one @Hopscotch !
@Hopscotch In your tests you have scene changes, it's important for the GS devs to note that leakage can also be observed on one-scene projects.
There is a bug report (103) that relates to memory leakage in combination with tables and scene changes but there is more to it than that.
@JSproject, single scene or not, make no difference. The linked project started as a single scene, then added the more to see if memory gets released. No difference, memory just accumulates.
To note as well, using or avoiding timers, loops and constrains, also makes no difference as far as I can tell.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
I tried to program the back button so it goes back to the menu scene similar to what we did with Tizen but the engine does not pick up the code.
@QASalad or @BlackCloakGS Can someone from the GS team provide an answer to what we can do to solve this issue ? I would appreciate if someone could take 30 seconds to post an update for this issue. Thank you.
Fantastic work @Hopscotch for capturing memory issues!
Free Mini Games and Demo Templates
I'm so glad @Hopscotch understands how to track memory usage and setup the appropriate tests to appropriately illustrate this problem.
Being a non-programmer myself, I've struggled to really get this issue illustrated. So this is a great step in the right direction.
I've posted links to this page of this thread, as well as directly to Hopscotch's video, and sample project file, on the page for Bug #729... to make sure that whoever the bug gets assigned to will hopefully see this very useful test info that Hopscotch has provided.
http://bugs.gamesalad.com/show_bug.cgi?id=729
@Hopscotch Nice testing, seems likely to be the main culprit.
Follow us: Twitter - Website
Has this issue of the iADS appearing at the top of scene, although set to appear at the bottom been fixed yet ??
M