thanks for explanation... by "loops", you mean "nested subroutines"* that are never returned, or something? (*used to dabble in basic / pascal programming, before I found GS which needs "NO PROGRAMMING!" of course ;-) The rules and constraints are very clever! but I do sometimes wish for line by line code for some activities
here's a question - Do particle systems also "leak memory"?
my published app spawns very few new actors, but it makes constant use of particles for effects. (star background, echo waves, etc.)
I have noticed it slows down (frame rate drops) after a while of use, 10 - 20 minutes? on my iPad will do a more detailed test soon.
@Franz Loops..yes something like that, basically when the slowdown occurs the cpu is maxed out doing something weird, if you keep going beachballing starts and these get longer and longer etc...
not sure about particles, it is very hard to tell, but certainly memory leaks on iDevices are massively less.
If you're working with images that are already very small to begin with, you aren't saving time on the initial load by using the image switch trick. It appears however that it is fairly effective when the images are of a larger file size. There is some major cpu usage if you change all of the images at once, but staggering them with a timer (or self.time) works smoothly.
There is almost no difference in load times whether you use the 2x2 image created or a naked actor. There also appears to be no difference of load times if each of the instances have an alpha of 0 to start the scene off.
BOTTOM LINE:
This procedure helps with load time if you have a small number of instances of actors and if the images that you're switching to are larger than 10 - 20 kb each. Unfortunately it isn't a huge difference, but little bits here and there add up, so it's something to give serious consideration.
A combination of staggering spawning and using the image switch trick would definitely make a dent in the load time, but only if you are able to spawn actors that are already the dimensions that you'll need each image to be. If you have a small number of actors that are off camera to begin with, this could be a highly effective process.
Again, if you have a large number of actors or instances of actors, you're still a bit out of luck.
*edit
Differences in load times were all within a second from variation to variation of testing each process. I was using 100 instances of a single actor and loading them off camera to start. Staggering the image switching and staggering the spawning reduces the chances of visual stuttering each time the spawning/image change occurs.
simo103 said: @entersimon .. great thread thanks for the insight and efforts. I wish there was a permanent home for some of this info, perhaps I'll pull a bunch of relevant forum posts and create a page for http://gsgame.epiggames.com/
but in the meantime .. don't know if you found this old thread but a did a few performance tests relating to overlapping images:
the other concerning issue is of course that Gamesalad updates reportedly are addressing numerous know issues with memory leak and that each update should have some (but not all) fixed. Thus some of these issues may be improved over time so for example a work around of recycling actors could become unneeded if teh spawn/destroy issue gets resolved.
I will create a template to show the issue I covered in my post and upload it. Perhaps we can combine numerous test projects into one file that everyone can download and do self tests with and that way each GS update can be compared to the old?!?! Thoughts?
I think that's a great idea. Basically it would be a benchmark test project. It probably wouldn't even be necessary for everyone to download it so long as someone posts the results of each test after each update.
Also, I think it would be priceless having a place to go to that shared optimization info found by developers. For right now, the workarounds are all we have for some issues, and as GS updates more and more and does their refining, we'll have to keep up with it and help to figure out newer and better ways to optimize. It would be good too because the coders would be able to see what we're doing for added speed, and they can hone in their focus to fix specific issues that everyone seems to be running into. I love the idea of this. The devs of GS are obviously working very hard, so any input we can give them would undoubtably help them out. Great ideas simo103
btw, even though I've done a lot of research on image optimization, I somehow missed the gem that is imageoptim. Thanks for that bit of info. Its made a very big difference. Shaved a half second off of my load time. That gives me good room to work with
Comments
by "loops", you mean "nested subroutines"* that are never returned, or something?
(*used to dabble in basic / pascal programming,
before I found GS which needs "NO PROGRAMMING!" of course ;-)
The rules and constraints are very clever!
but I do sometimes wish for line by line code for some activities
here's a question - Do particle systems also "leak memory"?
my published app spawns very few new actors,
but it makes constant use of particles for effects. (star background, echo waves, etc.)
I have noticed it slows down (frame rate drops) after a while of use, 10 - 20 minutes? on my iPad
will do a more detailed test soon.
not sure about particles, it is very hard to tell, but certainly memory leaks on iDevices are massively less.
If you're working with images that are already very small to begin with, you aren't saving time on the initial load by using the image switch trick. It appears however that it is fairly effective when the images are of a larger file size. There is some major cpu usage if you change all of the images at once, but staggering them with a timer (or self.time) works smoothly.
There is almost no difference in load times whether you use the 2x2 image created or a naked actor. There also appears to be no difference of load times if each of the instances have an alpha of 0 to start the scene off.
BOTTOM LINE:
This procedure helps with load time if you have a small number of instances of actors and if the images that you're switching to are larger than 10 - 20 kb each. Unfortunately it isn't a huge difference, but little bits here and there add up, so it's something to give serious consideration.
A combination of staggering spawning and using the image switch trick would definitely make a dent in the load time, but only if you are able to spawn actors that are already the dimensions that you'll need each image to be. If you have a small number of actors that are off camera to begin with, this could be a highly effective process.
Again, if you have a large number of actors or instances of actors, you're still a bit out of luck.
*edit
Differences in load times were all within a second from variation to variation of testing each process. I was using 100 instances of a single actor and loading them off camera to start. Staggering the image switching and staggering the spawning reduces the chances of visual stuttering each time the spawning/image change occurs.
Also, I think it would be priceless having a place to go to that shared optimization info found by developers. For right now, the workarounds are all we have for some issues, and as GS updates more and more and does their refining, we'll have to keep up with it and help to figure out newer and better ways to optimize. It would be good too because the coders would be able to see what we're doing for added speed, and they can hone in their focus to fix specific issues that everyone seems to be running into. I love the idea of this. The devs of GS are obviously working very hard, so any input we can give them would undoubtably help them out. Great ideas simo103
btw, even though I've done a lot of research on image optimization, I somehow missed the gem that is imageoptim. Thanks for that bit of info. Its made a very big difference. Shaved a half second off of my load time. That gives me good room to work with