Try constrain image instead of change image. Change image doesn't seem to work reliably for swapping an image.
I'm changing loads of images, and very quickly, with lots of different actors and 'change image' has been rock solid for me.
I just wanted to know if anyone had any support for the claim that "Change Attribute" is more reliable / less of a strain on the processor (or some other advantage) . . . than "Change Image" ?
Also, you don't need the image extension in the name, so if the graphic is called "image.png" just put "image" (minus quotes).
Yep, I always label my images with just a number and no extension.
I tried the Change Image suggestion however it does not work. The image is now just a blank square. I didnt want to use constrain because you said constrains are bad. Why isnt the Change Image workaround rule working?
My problem is when I click my start gameplay button, my app crashes after 10 seconds. The log said it ran out of memory. So what would cause it to crash at the beginning like that? There is barely anything on the screen at the start of the game.
Do these optimization tips apply to when your working on gamesalad? I recently added in loads of art for the environment and everything, and gamesalad is noticeable slower and crashing more often.
tatiangMember, Sous Chef, PRO, Senior Sous-ChefPosts: 11,949
Do these optimization tips apply to when your working on gamesalad? I recently added in loads of art for the environment and everything, and gamesalad is noticeable slower and crashing more often.
Most of the suggestions relate to run-time performance, not editor performance.
Great tips!!! If someone hasn't already explained nr 9 I will.. The ram can only understand binary numbers, which is 1 or 0. You can get other numbers by taking 2^n, where n is any integer value such as 1, 2, 3, 4... So when you make a picture which is 28*28px, the ram will see it as 32*32px (2*4).
By choosing picture size of 32, 64, 128, 256, 512 etc. you will minimize ram usage. Another example is if you make a picture which is 513px it would be seen by the ram as 1024px..
This also explains why you only can buy ram memory of 2, 4, 8, 16 gb. The same goes for SSD's and HDD's.
Hope it's a little bit more clear Not a native English speaker so sorry for some misspellings..
I don't do any of these things and my games run awesome. It's all about how efficient your logic is. Learn how to execute efficient planned integrated logic and your game will purr. If you saw how much code is in the main scene of Puck It @RP and I's new game you wouldn't believe it. But it runs over 60FPS and purs like a kitten because the logic is very linear and integrated. This is the key to smooth running code. As I say, just because it works doesn't mean it's right.
@FryingBaconStudios can you explain what you mean about having efficient logic in our games? and "learn how to execute efficient planned integrated logic"? I have heard that a fair bit and i honestly do not understand what it means. If you dont mind explaining that a little more i would appreciate it. Thanks
Logic is a straight series of events not willy nilly. This means things happen in order even when they happen seemingly simultaneously. I learned logic through 30 years of working with hard wire logic. What it means is to plan out your code beforehand and not just pilling it up. I'm currently contracting a game right now where you put balls into four different baskets. How I built the logic is that everything related to the balls and baskets which can be any of 10 different types which leads to tons of possible combinations, all the code revolves around four main attributes and all the code gets it's cues from those four. Those four are integrated into all the ball and basket actors, including associated masks, counting and detecting actors. This means all these actors only have to monitor four game level attributes to get their cues for destroy, counting misses and hits, image display, spawning associated balls et... This means things will scan and respond faster. Designing this type of code means planing it beforehand and refining it before you code it. I use a shorthand and outline and write out my code beforehand but since I have so much experience in logic I can track and write and rewrite most of it in my head. As I always say just because it works doesn't mean it's the best code. Many times I will trash or rewrite over 10 versions of my code, all those version work, but I work it until I find the most refined and efficient way to code it. Writing highly efficient code takes time and lots of thought and planing and testing. When I have complex ideas to work out, I make prototype projects and test out my concepts until I have it working how I want then I code it in my project. This is a lot of pure work and most people don't have the patience for this. I may spend days just thinking about how to code particular concepts until I'm sure it is refined. Many times I find ways to do it with less code each time. Maybe @RP will post here to validate my claims as we work together and he's seen my code.
Yuppers, your code is a foundation that will need to be damn near perfect or like a building, you level it and start over. Like Fry says, just because it's working does not means it's right. When you add more rules and/or behaviors it can break, or perhaps via a future update. I can't count how many times I reworked my "working" code only to find out it still was not perfect. I've seen Fry have to dump mountains of work just to hit the drawing board again over one little hiccup.
thanks for that detailed explanation @FryingBaconStudios. I have never hand written my code before i have implemented it into GS games, i guess now that i know i should probably start to do that. Is that what Pseudocode is? My games so far have been fairly simple games and yet they dont really function as well as i know they should. I can only put that down to poorly written code. But i have no idea what code is best changed and what is best to leave as it is. I suppose i will just need to keep working hard to organise my logic in the correct order. Thanks again mate very helpful.
It's all about sliming the code. Finding ways to build out your code around central attributes and/or events instead of just adding layer after layer. The only way to accomplish this is to layout the outline of your events and see how you can use and reuse the attributes you create. Like in this game I started with the four main attributes and built the code for the spawning, images changes, scoring and such around those four attributes. This is what I mean by integrated code. Like @rp said I will scrap a particular stack of code and rewrite it when it doesn't function perfectly or integrate well into my other blocks of code.
@phamtastic said:
. . . if I have to pick top 3 things from this list to make my game really run smooth . . .
1. Uncheck "Preload Art" on as many actors as you can.
This might be applicable in some situations, but all you are really doing is moving the loading of images from the start of the game to later on (when the assets are called on)- if anything I suspect this would make a game with lots of images a little more glitchy at run time as every time you come across a new asset usage it will have to be loaded. So I'd say there was no overall gain, my personal preference is to have the user wait for a second or two more at the start rather than risk little glitches when the game is running. This is not hypothetical I've had situations where unchecking preload art caused little glitches.
2. Uncheck "Movable" for every actor that doesn't have the "Accelerate", "Change Velocity", "Collide", "Move", "Move to", or any of the rotate behaviors.
Seems reasonable enough, you are effectively switching off the physic engine, but I've never tested it myself.
3. Use the "Interpolate" behavior instead of the "Move", "Move to", and "Change Size" behaviors whenever possible.
Not tested it myself, I can't see why it would help.
4. Use the "Rotate" behavior instead of animations.
My own tests have shown the very opposite to be true, animations are handled very well by GS, and they tend to outperform a behaviour doing the same thing, but you need to test for the situation - for example when this would be true would be a situation like having a 1024 x 1024 pixel image rotating - this would be much more efficient than an large (it would have to be larger than 1024 x 1024 if square) animation.
5. Turn every attribute under the physics tab in the actor editor to 0 on actors who do not need it.
Sounds like superstitious behaviour to me
6. If the actor is not going to be seen, change their "Visible" attribute to false.
Not tested it.
7. Instead of using the "Change Image" behavior, use "Change Attribute" and change the self.Image to the desired image's name.
I can't see why that would be advantageous, but not tested it myself.
8. Images should be the same size as the actor using them and double the size if you are using Resolution Independence.
A good general recommendation, but it's not a big issue if you image is a little bigger or smaller than the actor.
9. Change any image that is about 10 pixels more than 8, 16, 32, 64, 128, 256, 512, or 1024 to which ever of these numbers are closest.
A good general recommendation.
10. If an image file is large or is a background, have the actor that uses the image use the suggestion in number 7 instead of having the actor start initially with the image.
I see no reason why this should help.
11. All images should be 72dpi.
The 'ppi' (rather than 'dpi') is largely irrelevant, it's just metadata, whether your image is 22ppi or 40,000ppi will make no difference to image fidelity or memory use.
12. Save all images as PNG-24 or PNG-8
GameSalad no longer supports 8bit PNGs, but even if it still did they would make no difference to how smoothly your game runs as everything gets written into 24 colour-space on the target device.
13. Save all images as PNG-8 unless they have any transparent or translucent object in them.
See above (side note: you actually can have transparency with 8 bit images)
14. Don't use the color changer within GameSalad unless necessary.
Literally nonsense !
15. All images should be divisible by 4.
Recommend for Retina devices, but not a big deal if your images are not divisible by four, it will have no effect on how smoothly your game runs, it only effects how your game looks . . . got static (not moving) actors with images applied, and the images are very graphicy/contrasty then go for it, but if you have moving images or less graphic images like photos or illustrations then you are unlikely to see a difference.
16. Make sure your image creator is set to 8-bits/channel.
Strangely this would negate point 13, but yes, 24bit images (8bit per channel) are what you want.
17. Don't use the "Display Text" behavior wherever possible.
Agreed, the display text behaviour puts a notciable drain on your device, it's fine if you have a few elements (score, time . . etc), but beyond that I'd recommend replacing text with images where you can.
18. Try not to use so many global attributes and use tables wherever possible.
Not only are timers a bit of a system drain, but they can also be a little unpredictable in certain situations. It's fine to use them where needed, but you probably don't want 150 timers all firing away in your game !
20. Limit constrains and if you do need to use it, make sure that they are on the top of your code.
Agreed, constrains can be taxing, but like timers they are fine if you don't go crazy with them - but replace them with Change Attribute behaviours where you can.
22. If an actor is not being used again in the same scene, destroy it.
Seems reasonable enough.
23. If you have a game that goes on forever like Jetpack Joyride, Temple Run, or Jay & Silent Bob in Too Fat to Fly, make sure you either move or destroy actors that pass you by using these rules:
Seems reasonable enough - although it's worth noting that GS destroys your actors for you if they go beyond 500 pixels from the edge of your scene.
25. Use music at your own risk because it will decrease performance.
I've never had an issue with using music.
26. Delete all unused rules, groups, behaviors, actors, attributes, images, and sounds.
Seems reasonable enough, but will have no effect on performance.
27. Don't save more than 3 attributes at once.
Not tested this.
28. Don't update all Game Center Achievements/Leaderboards at once unless their is no movement in the scene at that time
Not tested this.
29. Make an initial scene that looks like your splash screen to load attributes and log in to Game Center
@Socks said:
This might be applicable in some situations, but all you are really doing is moving the loading of images from the start of the game to later on (when the assets are called on)- if anything I suspect this would make a game with lots of images a little more glitchy at run time as every time you come across a new asset usage it will have to be loaded. So I'd say there was no overall gain, my personal preference is to have the user wait for a second or two more at the start rather than risk little glitches when the game is running. This is not hypothetical I've had situations where unchecking preload art caused little glitches.
My understanding was that with the new megatexture system, this option has no ultimate effect.
@phamtastic said:
Socks - Thanks for the sharing your expertise... much appreciated. btw... is there an easy way to verify the FPS that your game is running?
Comments
I just wanted to know if anyone had any support for the claim that "Change Attribute" is more reliable / less of a strain on the processor (or some other advantage) . . . than "Change Image" ? Yep, I always label my images with just a number and no extension.
I tried the Change Image suggestion however it does not work. The image is now just a blank square. I didnt want to use constrain because you said constrains are bad. Why isnt the Change Image workaround rule working?
My problem is when I click my start gameplay button, my app crashes after 10 seconds. The log said it ran out of memory. So what would cause it to crash at the beginning like that? There is barely anything on the screen at the start of the game.
- Thomas
@SnapFireStudios... what can we do about what? Are you having a specific problem or just concerned by what you read?
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
If someone hasn't already explained nr 9 I will..
The ram can only understand binary numbers, which is 1 or 0. You can get other numbers by taking 2^n, where n is any integer value such as 1, 2, 3, 4...
So when you make a picture which is 28*28px, the ram will see it as 32*32px (2*4).
By choosing picture size of 32, 64, 128, 256, 512 etc. you will minimize ram usage.
Another example is if you make a picture which is 513px it would be seen by the ram as 1024px..
This also explains why you only can buy ram memory of 2, 4, 8, 16 gb. The same goes for SSD's and HDD's.
Hope it's a little bit more clear
I'm not following on nr 4, but I'm a bit slow
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Thanks
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
To all GS Experts, if I have to pick top 3 things from this list to make my game really run smooth and reduce loading... What would that be????
twitter.com/RoShamBoFighter
facebook.com/RoshamboFighter
1. Uncheck "Preload Art" on as many actors as you can.
This might be applicable in some situations, but all you are really doing is moving the loading of images from the start of the game to later on (when the assets are called on)- if anything I suspect this would make a game with lots of images a little more glitchy at run time as every time you come across a new asset usage it will have to be loaded. So I'd say there was no overall gain, my personal preference is to have the user wait for a second or two more at the start rather than risk little glitches when the game is running. This is not hypothetical I've had situations where unchecking preload art caused little glitches.
2. Uncheck "Movable" for every actor that doesn't have the "Accelerate", "Change Velocity", "Collide", "Move", "Move to", or any of the rotate behaviors.
Seems reasonable enough, you are effectively switching off the physic engine, but I've never tested it myself.
3. Use the "Interpolate" behavior instead of the "Move", "Move to", and "Change Size" behaviors whenever possible.
Not tested it myself, I can't see why it would help.
4. Use the "Rotate" behavior instead of animations.
My own tests have shown the very opposite to be true, animations are handled very well by GS, and they tend to outperform a behaviour doing the same thing, but you need to test for the situation - for example when this would be true would be a situation like having a 1024 x 1024 pixel image rotating - this would be much more efficient than an large (it would have to be larger than 1024 x 1024 if square) animation.
5. Turn every attribute under the physics tab in the actor editor to 0 on actors who do not need it.
Sounds like superstitious behaviour to me
6. If the actor is not going to be seen, change their "Visible" attribute to false.
Not tested it.
7. Instead of using the "Change Image" behavior, use "Change Attribute" and change the self.Image to the desired image's name.
I can't see why that would be advantageous, but not tested it myself.
8. Images should be the same size as the actor using them and double the size if you are using Resolution Independence.
A good general recommendation, but it's not a big issue if you image is a little bigger or smaller than the actor.
9. Change any image that is about 10 pixels more than 8, 16, 32, 64, 128, 256, 512, or 1024 to which ever of these numbers are closest.
A good general recommendation.
10. If an image file is large or is a background, have the actor that uses the image use the suggestion in number 7 instead of having the actor start initially with the image.
I see no reason why this should help.
11. All images should be 72dpi.
The 'ppi' (rather than 'dpi') is largely irrelevant, it's just metadata, whether your image is 22ppi or 40,000ppi will make no difference to image fidelity or memory use.
12. Save all images as PNG-24 or PNG-8
GameSalad no longer supports 8bit PNGs, but even if it still did they would make no difference to how smoothly your game runs as everything gets written into 24 colour-space on the target device.
13. Save all images as PNG-8 unless they have any transparent or translucent object in them.
See above (side note: you actually can have transparency with 8 bit images)
14. Don't use the color changer within GameSalad unless necessary.
Literally nonsense !
15. All images should be divisible by 4.
Recommend for Retina devices, but not a big deal if your images are not divisible by four, it will have no effect on how smoothly your game runs, it only effects how your game looks . . . got static (not moving) actors with images applied, and the images are very graphicy/contrasty then go for it, but if you have moving images or less graphic images like photos or illustrations then you are unlikely to see a difference.
16. Make sure your image creator is set to 8-bits/channel.
Strangely this would negate point 13, but yes, 24bit images (8bit per channel) are what you want.
17. Don't use the "Display Text" behavior wherever possible.
Agreed, the display text behaviour puts a notciable drain on your device, it's fine if you have a few elements (score, time . . etc), but beyond that I'd recommend replacing text with images where you can.
18. Try not to use so many global attributes and use tables wherever possible.
Not tested this myself.
19. Try not to use timers. See http://forums.gamesalad.com/discussion/44707/timers-are-for-chumps-gs-optimization-tips
Not only are timers a bit of a system drain, but they can also be a little unpredictable in certain situations. It's fine to use them where needed, but you probably don't want 150 timers all firing away in your game !
20. Limit constrains and if you do need to use it, make sure that they are on the top of your code.
Agreed, constrains can be taxing, but like timers they are fine if you don't go crazy with them - but replace them with Change Attribute behaviours where you can.
21. Make your own pause instead of using the behavior. See http://gshelper.com/stop-motion-on-custom-pause-gamesalad-tutorial/
Not tested.
22. If an actor is not being used again in the same scene, destroy it.
Seems reasonable enough.
23. If you have a game that goes on forever like Jetpack Joyride, Temple Run, or Jay & Silent Bob in Too Fat to Fly, make sure you either move or destroy actors that pass you by using these rules:
Seems reasonable enough - although it's worth noting that GS destroys your actors for you if they go beyond 500 pixels from the edge of your scene.
25. Use music at your own risk because it will decrease performance.
I've never had an issue with using music.
26. Delete all unused rules, groups, behaviors, actors, attributes, images, and sounds.
Seems reasonable enough, but will have no effect on performance.
27. Don't save more than 3 attributes at once.
Not tested this.
28. Don't update all Game Center Achievements/Leaderboards at once unless their is no movement in the scene at that time
Not tested this.
29. Make an initial scene that looks like your splash screen to load attributes and log in to Game Center
Not tested this.
30. If you can, unlock actors to constrain to the actor directly. See: http://gshelper.com/gamesalad-performance-tip-1-2/
Seems to make sense.
@Socks - Thanks for the sharing your expertise... much appreciated. btw... is there an easy way to verify the FPS that your game is running?
Thanks
twitter.com/RoShamBoFighter
facebook.com/RoshamboFighter
My understanding was that with the new megatexture system, this option has no ultimate effect.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Yes see my video on using Xcode instruments.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Do you know when they plan to implement this mega-texture system ? I seem to remember 0.13 being the version where it will be introduced ?