@Socks I can't remember where I read but it was recent within the last two weeks. When I first saw the new functions like you I thought why waste time on that when we have prec(). A member was complaining about these new functions and features being added while they still hadn't released a stable build. Someone else (I can't remember who as GS employee I think) wrote that the precision function works a text not a number function.
I have just spent half an hour trying to find the post but no luck. I will keep trying to find it but it would save a lot of effort if someone from GS can post here about it and clear it up one way or the other.
I have used prec() a lot in the app I am working on and it works fine but after reading that I intend to go back and change them all using round().
@Darrelf A very interesting post, considering I spent a few weeks struggling with memory issues. If you are still having memory problems, then you might be onto a different memory issue. Please keep us posted.
Here are my test results using 0.11.0.4 and XCode instruments:
I have a drag and drop puzzle game that with 2 memory issues.
Issue 1: the increasing memory issue when changing scenes is fixed, and the memory usage now stabalizes at about 50 mb and stays there. Thanks @BlackCloakGS and team!
Issue 2: a couple of weeks back I swapped all the "changeimage" behaviors for "changeattribute" behaviors, so that solved the other issue and I haven't tested any more for that.
@colander said:
Socks I can't remember where I read but it was recent within the last two weeks. When I first saw the new functions like you I thought why waste time on that when we have prec(). A member was complaining about these new functions and features being added while they still hadn't released a stable build.
Lol, that was my first thought too (guess I'm too cynical these days), why is anyone spending time on implementing another way to round numbers up/down (we already have ceil and floor and prec) when we have dozens of glitches, bugs and issues that remain year after year after year. If anyone is going to work on quantizing values it should be for when we place actors into our scene, I'm soooooooo tired of having to manually round up the X and Y values of every actor I place in my scene, on every project, for years now, thousands of actors, ahhhhhhahahahah !!
Someone else (I can't remember who as GS employee I think) wrote that the precision function works a text not a number function.
Works just fine with numbers.
I have just spent half an hour trying to find the post but no luck. I will keep trying to find it but it would save a lot of effort if someone from GS can post here about it and clear it up one way or the other.
Maybe it (prec) is one of those functions that will be discontinued (like using % for modulus) . . . . ?
@darrelf we will look into it. Can't promise it will be fix for 11.
For any one still having png issues please submit a support ticket with the following information. What program you use to save out the png and what setting you used and does it happen in 0.10.4.1. Also please attach the image or project with your bug.
Thank you
@huds07 this is the wrong thread to ask this question. Please stay on topic. Also posting that to every where including messaging me is not approbate behavior.
@BlackCloakGS said:
quantumsheep I an QA can not reproduce the table issue using the 0.11.0.4. We both can get past 100 columns
Yep, over 100 columns is fine - it's the rows I was talking about!
I've been able to go into another table in the same game and make over 100 rows just fine.
But this particular table (which is the most important one as it runs pretty much everything in the game) is just greyed out at 99 rows.
It's weird, but no worries as I worked around the issue as I mentioned previously by exporting, adding values in row 100, and re-importing into GS.
The 'Pause' problem is far more pressing for me. It worked fine, but for reasons unknown to me and without changing anything to do with the Pause behaviour, it's broken
I wonder how many other people might unknowingly be affected by this!
Oh, and as I was writing this post I just got your email adding the bug ( no. CS-278) to your list.
Thanks! Glad to see it's being taken seriously!
Another showstopping aspect is the stuff pointed out earlier in this thread about memory management by @darrelf (thanks btw for doing that research!).
This kind of stuff really needs to be fixed. There's no way any self-respecting dev would release a game knowing it's a ticking time-bomb heading for a crash!
Great work so far - good to see some progress! Looking forward to some cleaning up!
@BlackCloakGS : Can you please let us know what is the new ads timer? as we know that it was 60 sec for every ads request, so now in 0.11.0.4 what is the new timer value?
@Socks@colander We are adding round and roundTo as part of 0.11 because they will help to address several specific CS reports to do with physics issues between 0.10.4 and the recent 0.11 RCs.
prec(x,n) converts the value to a string. roundTo(x,n) keeps the value a number. If you are doing mathematical operations, there's a performance penalty to convert to strings and then back to numbers. For this reason, you'll almost always prefer roundTo (or round, floor, or ceil if appropriate) over prec. And it's more consistent with other programming languages. For example:
GOOD: 100+round(self.position.x)
BAD: 100+prec(self.position.x, 0)
The only time you'll want to use prec is if you want to pad the text with zeros to fit. This would probably be when you have a score or money quantity that you want to display with a fixed number of decimal points. For example:
@BlackCloakGS
I've just submitted a full bug report along with a side by side comparison screenshot on the png alpha issue - ticket #4454.
It's a huge problem for my hidden objects game - 3600 objects are affected across 240 scenes. It's basically unplayable as it stands as players would find it impossible to locate some of the objects.
@darrelf@BlackCloakGS
I submitted a bug report on the alpha issue too. I've attached the GS file that i've created for demonstration purposes if anyone wants to check it.
"Setting or interpolating the alpha value of an actor inside GameSalad to anything lower than 1 will turn the actor greyish instead of just making it transparent.
RC 0.10.4.1 was used to create the attached GS file.
Photoshop CS6 was used to create the .png that's being used in the GS file.
The .png was saved normally without any optimization tool. (In Photoshop: Save As - PNG - Compression: Smallest / Slow - Interlace: None)
Setting the compression to the other option doesn't change the outcome inside GameSalad. (Compression : None / Fast)
Particles work fine. The particles inside the GS file demonstrate how the image should normally look when it's transparent.
The actors on the other hand become greyish when their alpha gets below 1. This is even visible without starting the preview but its the same when starting the preview or testing on any device with the Viewer or an Ad hoc."
@BlackCloakGS Any idea why a 10MB GS project goes from 3.5 seconds to switch scenes in 10.4 to 17 seconds in 11.0.4? Only thing I can think off is that I have about 400 frames of animation (all PNG's with alpha saved as a PNG sequence in AfterEffects...) However, I have to use PNG's for my animation frames because every frame use alpha. What can it be do you think?
@viking unfortunately do to the new loading code our load times have increased quite a bit. This is something we are actively reworking in the release after 11 (you should see the changes soon in the nightly builds). 0.11.0 build really focused on fixing stability we closed over 200. The next release after 0.11.0 will focus on performance and memory usage. Sorry for any inconveniences this has caused.
@BlackCloakGS said:
viking unfortunately do to the new loading code our load times have increased quite a bit. This is something we are actively reworking in the release after 11 (you should see the changes soon in the nightly builds). 0.11.0 build really focused on fixing stability we closed over 200. The next release after 0.11.0 will focus on performance and memory usage. Sorry for any inconveniences this has caused.
Man, this is terrible news.
Essentially our games will now be double the file size (meaning many of us can no longer publish to Google Play). And worse still they'll load 2-3 times slower!
For me this makes 0.11.0 unusable.
@fishbowl1 said:
BlackCloakGS I'm still having issues with alpha. Any time I alter the alpha using Gamesalad, there is a layer of grey added to my images. This happens even when an image has no premultiplied alpha. My images are 32 bit PNGs created in Photoshop.
*Edit: For example, if I use a rule "when touch is pressed, set alpha to 0.5" it turns my image grey. The images are fine otherwise, only when the alpha is altered.
@BlackCloakGS@CodeWizard This. I am using Photoshop CC 64 bit's "save for web" to generate 24 bit pngs (+8 for transparency) and everything is fine except for this exact issue. So far no matter what way I export a PNG from Photoshop that uses transparency it has this issue when interpolating alpha. This is kind of a game breaker for my project.
@natzuur this is an issue with our rendering system and has been fix today. It will be in the next release. see CS-281 in our public bug database forum post.
@viking said:
Load times are unfortunately not getting any better, at lease that is my experience in my latest project. On 10.4 my game takes 9 seconds to finish the initial load. With 11.0.4 the initial load takes 16 seconds. From scene one it takes 3.5 seconds to load scene two using 10.4. The same scene transition on 11.0.4 takes 17 seconds!
Frame rate is rock solid 60 FPS in 11.0.4 and the online features are crucial to the game I am working on, but these load times makes 11.0.4 unusable for me at the moment.
I just spent the weekend optimizing and managed to almost cut the load time in half, and then I installed .11.0.4 and am nearly back to where I started! Please tell me that a performance fix is coming, cause I agree with @viking, it's unusable like this.
The only things that have really impacted my projects are the loading times and semi transparent images appearing darker. Good news on that @BlackCloakGS, and thanks for posting that bug list!
@natzuur@fishbowl1 I believe their fix for PNG's loading this time around was separate from the transparency issue. It had more to do with file type support I believe.
@BlackCloakGS
found a bug, resolution independence does not stay checked on new projects. If you check it and import an image, the image is imported and the RI checkbox is disabled. If you drag the image to create an actor it creates one at the full image res instead of 1/2
@BlackCloakGS found an issue, RevMob ads will not display on an iPhone4 running IOS6 using a universal build in the landscape orientation. The same game will work as expected on an iPad running IOS7.1. If the app is universal in the portrait orientation it will work as expected on both devices. It looks like the issue is with landscape universal builds. Cheers.
Edit: My bad ... I repackaged the app and it's working as expected in landscape mode on the iPhone. Please ignore. Next time I won't jump in quick to report stuff.
@BlackCloakGS said:
natzuur this is an issue with our rendering system and has been fix today. It will be in the next release. see CS-281 in our public bug database forum post.
Great. that seems to be the only bug I've encountered myself so far.
Comments
@Socks I can't remember where I read but it was recent within the last two weeks. When I first saw the new functions like you I thought why waste time on that when we have prec(). A member was complaining about these new functions and features being added while they still hadn't released a stable build. Someone else (I can't remember who as GS employee I think) wrote that the precision function works a text not a number function.
I have just spent half an hour trying to find the post but no luck. I will keep trying to find it but it would save a lot of effort if someone from GS can post here about it and clear it up one way or the other.
I have used prec() a lot in the app I am working on and it works fine but after reading that I intend to go back and change them all using round().
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
@Darrelf A very interesting post, considering I spent a few weeks struggling with memory issues. If you are still having memory problems, then you might be onto a different memory issue. Please keep us posted.
Here are my test results using 0.11.0.4 and XCode instruments:
I have a drag and drop puzzle game that with 2 memory issues.
Issue 1: the increasing memory issue when changing scenes is fixed, and the memory usage now stabalizes at about 50 mb and stays there. Thanks @BlackCloakGS and team!
Issue 2: a couple of weeks back I swapped all the "changeimage" behaviors for "changeattribute" behaviors, so that solved the other issue and I haven't tested any more for that.
Lol, that was my first thought too
(guess I'm too cynical these days), why is anyone spending time on implementing another way to round numbers up/down (we already have ceil and floor and prec) when we have dozens of glitches, bugs and issues that remain year after year after year. If anyone is going to work on quantizing values it should be for when we place actors into our scene, I'm soooooooo tired of having to manually round up the X and Y values of every actor I place in my scene, on every project, for years now, thousands of actors, ahhhhhhahahahah !! 
Works just fine with numbers.
Maybe it (prec) is one of those functions that will be discontinued (like using % for modulus) . . . . ?
please help me how to add a rating and score in gamesalad windows
@darrelf we will look into it. Can't promise it will be fix for 11.
For any one still having png issues please submit a support ticket with the following information. What program you use to save out the png and what setting you used and does it happen in 0.10.4.1. Also please attach the image or project with your bug.
Thank you
@huds07 this is the wrong thread to ask this question. Please stay on topic. Also posting that to every where including messaging me is not approbate behavior.
@quantumsheep I an QA can not reproduce the table issue using the 0.11.0.4. We both can get past 100 columns
Yep, over 100 columns is fine - it's the rows I was talking about!
I've been able to go into another table in the same game and make over 100 rows just fine.
But this particular table (which is the most important one as it runs pretty much everything in the game) is just greyed out at 99 rows.
It's weird, but no worries as I worked around the issue as I mentioned previously by exporting, adding values in row 100, and re-importing into GS.
The 'Pause' problem is far more pressing for me. It worked fine, but for reasons unknown to me and without changing anything to do with the Pause behaviour, it's broken
I wonder how many other people might unknowingly be affected by this!
Oh, and as I was writing this post I just got your email adding the bug ( no. CS-278) to your list.
Thanks! Glad to see it's being taken seriously!
Another showstopping aspect is the stuff pointed out earlier in this thread about memory management by @darrelf (thanks btw for doing that research!).
This kind of stuff really needs to be fixed. There's no way any self-respecting dev would release a game knowing it's a ticking time-bomb heading for a crash!
Great work so far - good to see some progress! Looking forward to some cleaning up!
Cheers!
QS =D
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
@BlackCloakGS : Can you please let us know what is the new ads timer? as we know that it was 60 sec for every ads request, so now in 0.11.0.4 what is the new timer value?
@Socks @colander We are adding round and roundTo as part of 0.11 because they will help to address several specific CS reports to do with physics issues between 0.10.4 and the recent 0.11 RCs.
prec(x,n) converts the value to a string. roundTo(x,n) keeps the value a number. If you are doing mathematical operations, there's a performance penalty to convert to strings and then back to numbers. For this reason, you'll almost always prefer roundTo (or round, floor, or ceil if appropriate) over prec. And it's more consistent with other programming languages. For example:
The only time you'll want to use prec is if you want to pad the text with zeros to fit. This would probably be when you have a score or money quantity that you want to display with a fixed number of decimal points. For example:
But:
@quantumsheep QA is looking into the memory issue
Lubbly!
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
@BlackCloakGS
I've just submitted a full bug report along with a side by side comparison screenshot on the png alpha issue - ticket #4454.
It's a huge problem for my hidden objects game - 3600 objects are affected across 240 scenes. It's basically unplayable as it stands as players would find it impossible to locate some of the objects.
@darrelf @BlackCloakGS
I submitted a bug report on the alpha issue too. I've attached the GS file that i've created for demonstration purposes if anyone wants to check it.
"Setting or interpolating the alpha value of an actor inside GameSalad to anything lower than 1 will turn the actor greyish instead of just making it transparent.
RC 0.10.4.1 was used to create the attached GS file.
Photoshop CS6 was used to create the .png that's being used in the GS file.
The .png was saved normally without any optimization tool. (In Photoshop: Save As - PNG - Compression: Smallest / Slow - Interlace: None)
Setting the compression to the other option doesn't change the outcome inside GameSalad. (Compression : None / Fast)
Particles work fine. The particles inside the GS file demonstrate how the image should normally look when it's transparent.
The actors on the other hand become greyish when their alpha gets below 1. This is even visible without starting the preview but its the same when starting the preview or testing on any device with the Viewer or an Ad hoc."
@BlackCloakGS Any idea why a 10MB GS project goes from 3.5 seconds to switch scenes in 10.4 to 17 seconds in 11.0.4? Only thing I can think off is that I have about 400 frames of animation (all PNG's with alpha saved as a PNG sequence in AfterEffects...) However, I have to use PNG's for my animation frames because every frame use alpha. What can it be do you think?
@viking unfortunately do to the new loading code our load times have increased quite a bit. This is something we are actively reworking in the release after 11 (you should see the changes soon in the nightly builds). 0.11.0 build really focused on fixing stability we closed over 200. The next release after 0.11.0 will focus on performance and memory usage. Sorry for any inconveniences this has caused.
Thanks for the clarification, makes sense.
Man, this is terrible news.
Essentially our games will now be double the file size (meaning many of us can no longer publish to Google Play). And worse still they'll load 2-3 times slower!
For me this makes 0.11.0 unusable.
@TaoOfSalad thanks for the explanation I am using prec() to display money values so I will stick with it.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
@BlackCloakGS @CodeWizard This. I am using Photoshop CC 64 bit's "save for web" to generate 24 bit pngs (+8 for transparency) and everything is fine except for this exact issue. So far no matter what way I export a PNG from Photoshop that uses transparency it has this issue when interpolating alpha. This is kind of a game breaker for my project.
@natzuur this is an issue with our rendering system and has been fix today. It will be in the next release. see CS-281 in our public bug database forum post.
I just spent the weekend optimizing and managed to almost cut the load time in half, and then I installed .11.0.4 and am nearly back to where I started! Please tell me that a performance fix is coming, cause I agree with @viking, it's unusable like this.
Our games http://Donkeysoft.ca
The only things that have really impacted my projects are the loading times and semi transparent images appearing darker. Good news on that @BlackCloakGS, and thanks for posting that bug list!
@natzuur @fishbowl1 I believe their fix for PNG's loading this time around was separate from the transparency issue. It had more to do with file type support I believe.
So I guess I should stop using ImageAlpha (http://pngmini.com) or ImageOptim (http://imageoptim.com) before importing my PNGs into GameSalad.
Will there be another Release Candidate or nightly before the stable?
For this GS team have to add Gamepad support. Don't know why, but they don't want to do that. Basically gamepads is like a kryptonite for GS team.
Shadows Peak is an atmospheric psychological horror that explores the dark side of a player.
Doomsday is here. Alpha images compressed with tinypng dosen't work anymore. Goodbye Google Play
Shadows Peak is an atmospheric psychological horror that explores the dark side of a player.
@BlackCloakGS
found a bug, resolution independence does not stay checked on new projects. If you check it and import an image, the image is imported and the RI checkbox is disabled. If you drag the image to create an actor it creates one at the full image res instead of 1/2
submitting it now
Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left
@BlackCloakGS found an issue, RevMob ads will not display on an iPhone4 running IOS6 using a universal build in the landscape orientation. The same game will work as expected on an iPad running IOS7.1. If the app is universal in the portrait orientation it will work as expected on both devices. It looks like the issue is with landscape universal builds. Cheers.
Edit: My bad ... I repackaged the app and it's working as expected in landscape mode on the iPhone. Please ignore. Next time I won't jump in quick to report stuff.
Free Mini Games and Demo Templates
Great. that seems to be the only bug I've encountered myself so far.