@tmann said:
Hopscotch Does the iOS engine actually use ARC ? Maybe the problem is the legacy manual memory management, GS would need to clarify.
No idea. The engine is written in C++ as far as I am aware. So probably no automatic conversion to ARC.
The issue remains the same. Under some exotic circumstances memory is not released. The more specific we can be in pointing it out with proofs, the sooner they can solve it for us.
@BlackCloakGS said:
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++.
@BlackCloakGS Thanks very much for the clarification.
@Hopscotch said:
The issue remains the same. Under some exotic circumstances memory is not released. The more specific we can be in pointing it out with proofs, the sooner they can solve it for us.
Couldn't agree more I'll go and see if I can break something (sorry if I came across as an Arse )
I am having difficulty recreating the memory increase on a smaller scale project. All I have learned is that the pause function seems to make a much larger memory spike than change scene. My game does pause before changing scenes between levels. A pause screen pops up with a retry or continue button.
I think the default loading screen of the free version is a terrible ambassador for a professional game engine!
Blurry, Stretched, weird red backdrop.
The wording "Free Trial" and "Not for Commercial Use" actually has no purpose here.
The developer knows this already, so it only makes the developer look like ...
1) a cheapskate, for not buying pro
2) a criminal, for using it for commercial purposes as most will have ads in anyway
... to the user.
Personally I feel this reflects a bad image, which ultimately rubs off on the pro developers. We need to make every effort to lift the image of GS. I want to poke Mr Hodap from TA in the eye, every time I hear him equate some random bad game with GS - "it is like some crappy GS game".
Yep... saw it for the first time today after downloading something from the app store !! There is little you can say really apart from ...............wtf.. but what you said was perfect @Hopscotch.
I have a real pet hate for bolloxed aspect ratios and see so many of them around GSs lower ranks but this takes the biscuit.
Its Sad that its come to this, but after a week, there is no sign of any improvements, if only it shows the unprofessional approach being taken. Even the splash screen isn't done right.
No State of GameSalad for over a month.
Thanks for the learning experience, It had been fun until you try to take it seriously. If GameSalad isn't free anymore, then the users who pay for need to be making money to continue using it. And at this stage, GS does not seem to care about this. It is shame.
Creator crashes all the time, crashes when trying to use viewer, or try to publish.
Who knows I might use the new engine you guys create, oh thats right you already built two . Maybe a new marketplace - sure close down yours for half a year, show us the new website, then go with a third party site that provides horrible customer support.
I wish I could leave on a more positive note, but you didn't even provide multiplayer. Or push notifications. But thank goodness you put all your effort into adding more tables for us.
@BlackCloakGS@GeorgeGS How difficult would it be to add an option to have things not get destroyed when they're more than 500 pixels from the scene? Is that something imposed to have the default be that things are auto-destroyed, or is there some technical reason this happens? A checkbox in each actor would be very useful.
@Armelline said:
BlackCloakGS GeorgeGS How difficult would it be to add an option to have things not get destroyed when they're more than 500 pixels from the scene? Is that something imposed to have the default be that things are auto-destroyed, or is there some technical reason this happens? A checkbox in each actor would be very useful.
I've always liked the fact that this kind of clean up operation is in place, someone new to GameSalad might easily go about firing off hundreds of shots from his hero's gun not thinking about what happens to the bullets once off screen - which, if GS had to track every bullet for the entirety of the game (even the 150 bullets you fired off 20 minutes ago at the start of the game), even when they are tens of millions of pixels off screen, then I suspect we'd see a lot of complaints about laggy performance - so the logic of this function is sound, and I think should definitely be on by default, but like you say it would be good to be able to switch it off too . . . .
. . . but you sort of can, there are numerous ways to defeat the 500 pixel graveyard, you can simply enlarge your scene, or even just place a boarder just before the -500 mark (on all sides) and have that boarder stop the actors in their tracks, or move them somewhere else, or respawn somewhere else (etc etc).
But like you suggest, if it's a '15 minute job' ( ) it would be a useful thing to be able to control.
@The_Gamesalad_Guru said:
I agree with socks and my point as well GS has bigger fish to fry right now. Let's try to stay focused on the issues in front of us.
Yeah, basically that, like autosave, this is something we can easily do right now, we can prevent actors from being destroyed at the -500 pixel edge of the world with the tools we currently have, so although I agree that all these kinds of small refinements are useful in all sorts of situations I would prefer to see GS concentrate on the more important stuff.
There are cases where the 500 pixel auto-destroy is a bit of a pain. For instance, if you have a very large actor that the player is able to move. I definitely wouldn't want to delay something like custom fonts for it, but if it's fairly easy to get done I'd love to see @Hopscotch's suggestion of it defaulting to 500 but being able to change it.
@Armelline said:
There are cases where the 500 pixel auto-destroy is a bit of a pain. For instance, if you have a very large actor that the player is able to move. I definitely wouldn't want to delay something like custom fonts for it, but if it's fairly easy to get done I'd love to see Hopscotch's suggestion of it defaulting to 500 but being able to change it.
You can just expand the scene and move the camera origin over to get more space on left side.
@Armelline said:
This is not always a desirable thing to do. It's what you currently have to do, but it's far from idea.
Yeah, it might cause issues, especially if you have to implement it after you've started your game (easier to set up from the start), so I'd probably go with having 4 actors, at the 500 px boarders, to detect and stop (or move or change direction - etc) any actors looking to escape.
EDIT: just thought, this doesn't really address your big-actor-being-moved scenario.
Comments
No idea. The engine is written in C++ as far as I am aware. So probably no automatic conversion to ARC.
The issue remains the same. Under some exotic circumstances memory is not released. The more specific we can be in pointing it out with proofs, the sooner they can solve it for us.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
There you go, even more complex than anticipated.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
@BlackCloakGS Thanks very much for the clarification.
Couldn't agree more I'll go and see if I can break something
(sorry if I came across as an Arse 
)
I am having difficulty recreating the memory increase on a smaller scale project. All I have learned is that the pause function seems to make a much larger memory spike than change scene. My game does pause before changing scenes between levels. A pause screen pops up with a retry or continue button.
www.rossmanbrosgames.com
On the android engine replace the manual retain release objective-c with the Java GC. Lua and C/C++ still apply
Not at all!
Constructive peer review.
Ever seen forums of the theoretical physics community? You will cry!
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
We all have our arse moments around here..lol
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
... and sometimes an unfair bit of arse kicking too!
I think the default loading screen of the free version is a terrible ambassador for a professional game engine!
Blurry, Stretched, weird red backdrop.
The wording "Free Trial" and "Not for Commercial Use" actually has no purpose here.
The developer knows this already, so it only makes the developer look like ...
1) a cheapskate, for not buying pro
2) a criminal, for using it for commercial purposes as most will have ads in anyway
... to the user.
Personally I feel this reflects a bad image, which ultimately rubs off on the pro developers. We need to make every effort to lift the image of GS. I want to poke Mr Hodap from TA in the eye, every time I hear him equate some random bad game with GS - "it is like some crappy GS game".
(my wrong spelling is intentional)
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Yep... saw it for the first time today after downloading something from the app store !! There is little you can say really apart from ...............wtf.. but what you said was perfect @Hopscotch.
I have a real pet hate for bolloxed aspect ratios and see so many of them around GSs lower ranks but this takes the biscuit.
Fortuna Infortuna Forti Una
These things are ugly and puzzling. How they would allow this screen to be published is beyond me. I thought you couldn't publish without pro???
How does apple not reject these apps?
@BlackCloakGS when a interstitial ad pops up should the game pause seems like it did before?
Agreed, nothing says 'cheap crap' like screwed up aspect ratios.
@BlackCloakGS Is there any news on Bug 1081 - Arcade: HTML5: change image behaviour not working
I am currently working on RevMob and Window installer stuff. Once i am done with that i will be circling back to fix html5 bugs.
Sounds great! I've not been able to get a project to work on Arcade for ages
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Its Sad that its come to this, but after a week, there is no sign of any improvements, if only it shows the unprofessional approach being taken. Even the splash screen isn't done right.
No State of GameSalad for over a month.
Thanks for the learning experience, It had been fun until you try to take it seriously. If GameSalad isn't free anymore, then the users who pay for need to be making money to continue using it. And at this stage, GS does not seem to care about this. It is shame.
Creator crashes all the time, crashes when trying to use viewer, or try to publish.
Who knows I might use the new engine you guys create, oh thats right you already built two
. Maybe a new marketplace - sure close down yours for half a year, show us the new website, then go with a third party site that provides horrible customer support. 
I wish I could leave on a more positive note, but you didn't even provide multiplayer. Or push notifications. But thank goodness you put all your effort into adding more tables for us.
Bye
@Tiny_Ideas, too bad that you feel that way.
My perception is quite the opposite. GS has never been more responsive in dealing with issues, or rational in their strategy.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
@BlackCloakGS @GeorgeGS How difficult would it be to add an option to have things not get destroyed when they're more than 500 pixels from the scene? Is that something imposed to have the default be that things are auto-destroyed, or is there some technical reason this happens? A checkbox in each actor would be very useful.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Even a value, defaulted to 500 but changeable, would be great.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Even better.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I've always liked the fact that this kind of clean up operation is in place, someone new to GameSalad might easily go about firing off hundreds of shots from his hero's gun not thinking about what happens to the bullets once off screen - which, if GS had to track every bullet for the entirety of the game (even the 150 bullets you fired off 20 minutes ago at the start of the game), even when they are tens of millions of pixels off screen, then I suspect we'd see a lot of complaints about laggy performance - so the logic of this function is sound, and I think should definitely be on by default, but like you say it would be good to be able to switch it off too . . . .
. . . but you sort of can, there are numerous ways to defeat the 500 pixel graveyard, you can simply enlarge your scene, or even just place a boarder just before the -500 mark (on all sides) and have that boarder stop the actors in their tracks, or move them somewhere else, or respawn somewhere else (etc etc).
But like you suggest, if it's a '15 minute job' (
) it would be a useful thing to be able to control.
I agree with @socks and my point as well GS has bigger fish to fry right now. Let's try to stay focused on the issues in front of us.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Yeah, basically that, like autosave, this is something we can easily do right now, we can prevent actors from being destroyed at the -500 pixel edge of the world with the tools we currently have, so although I agree that all these kinds of small refinements are useful in all sorts of situations I would prefer to see GS concentrate on the more important stuff.
There are cases where the 500 pixel auto-destroy is a bit of a pain. For instance, if you have a very large actor that the player is able to move. I definitely wouldn't want to delay something like custom fonts for it, but if it's fairly easy to get done I'd love to see @Hopscotch's suggestion of it defaulting to 500 but being able to change it.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Yep, exactly this reason.
@Socks, your suggestion of expanding the scene size is the obvious solution.
However, editing actors on the scene then becomes unbearably tedious, scrolling back to the actual scene content after editing an actor.
Having a simple destroy limit hidden in the "Motion" settings, would make life sooo much simpler!
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
You can just expand the scene and move the camera origin over to get more space on left side.
This is not always a desirable thing to do. It's what you currently have to do, but it's far from idea.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Yeah, it might cause issues, especially if you have to implement it after you've started your game (easier to set up from the start), so I'd probably go with having 4 actors, at the 500 px boarders, to detect and stop (or move or change direction - etc) any actors looking to escape.
EDIT: just thought, this doesn't really address your big-actor-being-moved scenario.