I've found that a very simple game which usually ran at about 20mb now stacks memory every time a level is changed. In three levels I got the ram up to 50mb. This is new as of this update (as it passed extensive testing prior).
here is the problem with my sound. so upon an actor colliding with another actor i have it play a sound and cut to a pause screen. well on the previous version of game salad the sound would run to completion even with the pause screen. now with the new version it goes to the pause screen and does not play that sound or that sound is not carried over to the pause screen.
why has this changed? it is very annoying!
i mean i guess my way around it now is to play the sound on my next screen since its a game over one instead of on the collision, but still curious why it changed.
tshirtbooth said: if you already use the change attribute trick then this will not help you other then animations. this new feature is basically the same as the change image trick. Just an easier way to do it.
That is correct - the Preload Art setting enables you to defer asset loading for behaviors like Animate and Change Image rather than using Change Attribute + Timer.
azimpact said: Releasing memory when it’s ready to run out is not the way to go because by that point the game will have become too unstable to play.
It still doesn’t release memory when resetting the scene or even the game for that matter.
We release memory at a level 1 memory warning, rather than at the point where the app is about to crash.
We don't release memory when resetting the scene because all the assets that the scene was using will still be used when the scene restarts.
QVT said: That is correct - the Preload Art setting enables you to defer asset loading for behaviors like Animate and Change Image rather than using Change Attribute + Timer.
We release memory at a level 1 memory warning, rather than at the point where the app is about to crash.
We don't release memory when resetting the scene because all the assets that the scene was using will still be used when the scene restarts.
Now that I've done about 6 adhoc builds and tests, I'm liking what I see. After unticking some preloads, the game starts quicker and goes quicker from scene to scene.
On a 2g, it's ok but on anything above that it seems to run pretty stable.
So if that's the case why after 4 levels of game play and 3 scene changes does the ram keep adding and adding starting at 40mb going all the way up to 100mb where I switched it off. Ipad2
QVT said: That is correct - the Preload Art setting enables you to defer asset loading for behaviors like Animate and Change Image rather than using Change Attribute + Timer.
We release memory at a level 1 memory warning, rather than at the point where the app is about to crash.
We don't release memory when resetting the scene because all the assets that the scene was using will still be used when the scene restarts.
If i was happy with my load times and felt that there were the right balance(of course they could be better), has this update changed anything?, do i need to turn this pre load off/on or anything
Did anyone else experience the weirdness that UtopianGames had with that attribute problem? I'm in 2 minds about installing this "upgrade" as I have a load of attributes in use, so tracking down if some of them weren't being read correct would be a pain in the rear for sure.
I already have blank images for my actors and then change image attribute so can't see preload helping me out so don't need to upgrade for that.
Anyone else have a problem with having to use a "null" image to get this to work properly? In best practices they tell us to use a blank transparent image, then set a change image to the original actors image when the image is loaded.
Problem with doing that is that its going to be impossible to make any future level design changes without a lot of pain.
Surely there was a better way to implement this, surely it could have been hardcoded that if pre-loaded was turned off it would change the base image to a transparent blank image which ran in the background.
I mean looking at my project now with over 100 actors, its going to take me 5 minutes to find any actor i need.
@micksolo I think its best to do this at the end of your development and if you need to go back to move thing, open the actor and drop the art back on the art icon to 're-show' the actor image - put the blank one back when your done.
Since the update, is anyone having any issues with "otherwise" not working correctly, and over-riding the main part of the rule?
Ive had it with a number of rules Ive set up, where its a pretty basic rule, but it always does the "otherwise" portion, regardless of what conditions are met.
All my other rules containing otherwise, that are in my project, that were added pre-update work seem to work correctly, but new ones are consistently doing the "otherwise" portion of the rule instead of the main part...
Ive had to strip out the otherwise, and add an extra rule into my actors to get around it.
Just as a reminder, if you are experiencing any bugs or issues related to 0.9.8 please submit them via the contact form. These issues are a priority and we will be investigating them. As always, we will continue to monitor this thread for general feedback.
Am I understanding this correctly the the "preload" function makes the "change image" and "animate" features work optimally? If so... That's a HUGE step forward.
I have a particle explosion that uses a blast sound when it explodes. If you load the game and start playing, it works fine. However, if you die and the scene resets, then ALL the sounds no longer work. The only sound that does work is the music. It works if you use the viewer, but when you build an adhoc and load it to a device the problem starts.
I have a attribute to play sound if true, but I've placed a blank actor showing that attribute and it is still showing true when the sound stops working.
This was all working fine prior to the upgrade.
This is great. I waited to release the game for the upgrade thinking it would improve performance. Instead, it's made the game un-releasable.
yeah i had posted about that one azimpact. it seems that sounds do not play completely anymore and they are tied to the scene, so if the scene ends, pauses or resets the sound stops or doesn't play.
"yeah i had posted about that one azimpact. it seems that sounds do not play completely anymore and they are tied to the scene, so if the scene ends, pauses or resets the sound stops or doesn't play."
That's a nasty bug. It's taken a game that was ready to launch and made it so now it can't be launched because it don't function correctly. There is no way to work around it at this point. I knew I should of published it on Tuesday. That's what I get for waiting.
i just had a game published yesterday but noticed i needed to update something and well thats when i noticed the sound bug. so my work around was to have the sound play on the game over scene.
Comments
http://gamesalad.com/forums/topic.php?id=32765&page=1
Someone should merge this.
Releasing memory when it’s ready to run out is not the way to go because by that point the game will have become too unstable to play.
It still doesn’t release memory when resetting the scene or even the game for that matter.
I don’t understand why Gamesalad has such a problem with releasing memory when actors are destroyed when other’s don’t have that problem.
why has this changed? it is very annoying!
i mean i guess my way around it now is to play the sound on my next screen since its a game over one instead of on the collision, but still curious why it changed.
We don't release memory when resetting the scene because all the assets that the scene was using will still be used when the scene restarts.
On a 2g, it's ok but on anything above that it seems to run pretty stable.
How much memory is released on the 1st warning?
And another question ...
In what instances is it best to TICK the Preload Art attribute?
Just go with me a minute...
If i was happy with my load times and felt that there were the right balance(of course they could be better), has this update changed anything?, do i need to turn this pre load off/on or anything
I already have blank images for my actors and then change image attribute so can't see preload helping me out so don't need to upgrade for that.
Darren.
Problem with doing that is that its going to be impossible to make any future level design changes without a lot of pain.
Surely there was a better way to implement this, surely it could have been hardcoded that if pre-loaded was turned off it would change the base image to a transparent blank image which ran in the background.
I mean looking at my project now with over 100 actors, its going to take me 5 minutes to find any actor i need.
However it would have been useful if you also added a PreloadSound attribute along with the art one.
padint
padreal
precision
Really nice job - The in app browser is also a master stroke!
Ive had it with a number of rules Ive set up, where its a pretty basic rule, but it always does the "otherwise" portion, regardless of what conditions are met.
All my other rules containing otherwise, that are in my project, that were added pre-update work seem to work correctly, but new ones are consistently doing the "otherwise" portion of the rule instead of the main part...
Ive had to strip out the otherwise, and add an extra rule into my actors to get around it.
Just as a reminder, if you are experiencing any bugs or issues related to 0.9.8 please submit them via the contact form. These issues are a priority and we will be investigating them. As always, we will continue to monitor this thread for general feedback.
Thank you!
I have a particle explosion that uses a blast sound when it explodes. If you load the game and start playing, it works fine. However, if you die and the scene resets, then ALL the sounds no longer work. The only sound that does work is the music. It works if you use the viewer, but when you build an adhoc and load it to a device the problem starts.
I have a attribute to play sound if true, but I've placed a blank actor showing that attribute and it is still showing true when the sound stops working.
This was all working fine prior to the upgrade.
This is great. I waited to release the game for the upgrade thinking it would improve performance. Instead, it's made the game un-releasable.
Shadows Peak is an atmospheric psychological horror that explores the dark side of a player.
That's a nasty bug. It's taken a game that was ready to launch and made it so now it can't be launched because it don't function correctly. There is no way to work around it at this point. I knew I should of published it on Tuesday. That's what I get for waiting.