GS Mythbusters? White Square Image loading optimisation
StuartY
Member Posts: 134
One of the things that's irked me - and everyone else, apparently - about working with GS are the long loading times. I've heard of various techniques to try and keep it down. These vary from the proven, common sense (using smaller images, being aware of the 2* rule, loading similar levels sequentially) to stuff which is less proven and may or may not have something in it - the alternative medicine of the GS world, so to speak.
One of the most prevalent appears to be working using "white square" actors and adding a rule to change their image as soon as the level starts to the correct image. Apparently, this is meant to reduce the time GS spends pre-loading image files. The only complication; you have to work in a blizzard of white squares when you're actually positioning stuff in your game.
Well, I didn't fancy the thought of having to blunder around in the dark (or the light, in this case) trying to assemble every level in my game. So I decided to do a test and see if this technique actually works.
My conclusion: It doesn't.
I opened up a simple project I've just finished. I had assembled a level using the white squares technique. Then I placed the "real" images on to all the blank actors. I opened it in the iPhone viewer - once before, once after. I timed the loading of the scene in question with a stopwatch. The results:
With white squares: 10.6 seconds
Actors with images: 10.3 seconds
This doesn't prove the inverse - that not using white squares is actually faster - human error could account for the 0.3s. But it does seem to suggest that the white square technique has little, if any bearing on load times.
My project has far more audio than images, so I stripped the audio out and repeated the test to be sure:
WS: 2.0s
Images: 1.8s
Again, marginally quicker without the WS.
Maybe this used to work and it doesn't in 0.93. I don't know. But considering as I was unable to discover any advantage at all to using this technique, I'll be forgetting about it and working with GS normally from now on.
What are your opinions on the matter? I'd be particularly interested to here what the devs or sous-chefs think. Has anyone else who uses it tried similar tests?
One of the most prevalent appears to be working using "white square" actors and adding a rule to change their image as soon as the level starts to the correct image. Apparently, this is meant to reduce the time GS spends pre-loading image files. The only complication; you have to work in a blizzard of white squares when you're actually positioning stuff in your game.
Well, I didn't fancy the thought of having to blunder around in the dark (or the light, in this case) trying to assemble every level in my game. So I decided to do a test and see if this technique actually works.
My conclusion: It doesn't.
I opened up a simple project I've just finished. I had assembled a level using the white squares technique. Then I placed the "real" images on to all the blank actors. I opened it in the iPhone viewer - once before, once after. I timed the loading of the scene in question with a stopwatch. The results:
With white squares: 10.6 seconds
Actors with images: 10.3 seconds
This doesn't prove the inverse - that not using white squares is actually faster - human error could account for the 0.3s. But it does seem to suggest that the white square technique has little, if any bearing on load times.
My project has far more audio than images, so I stripped the audio out and repeated the test to be sure:
WS: 2.0s
Images: 1.8s
Again, marginally quicker without the WS.
Maybe this used to work and it doesn't in 0.93. I don't know. But considering as I was unable to discover any advantage at all to using this technique, I'll be forgetting about it and working with GS normally from now on.
What are your opinions on the matter? I'd be particularly interested to here what the devs or sous-chefs think. Has anyone else who uses it tried similar tests?
Comments
WS: 1.8s
Normal: 2s
Again, about the same, but I think the WS had a slight edge. It's also worth noting that Photics' method produced a few 1/10s of white squares in the level before the images had loaded.
I'm going to make a test project with an absurd quantity of images so I can test this over a much longer timescale, eliminating the possibility of human error.
I also did white squares test (With no timer) and it didn't work.
Cheers.
do you notice the squares before your images load? ...
are you testing through the GS viewer or Adhoc builds...?
Photics, I'd also be interested to know how you "stripped" the default images from your project - how does one set about "going back to white"?
What if you build the game with an image in the actor and then before publishing throw them out. The actors will turn white again but no problem there because the .self trick is in it. My suggestion is to use a different name than the one in the .self trick ore you will get blanks there when the images are thrown out.
For example make a copy of each image and call them image.png and XXXimageXXX.png
The XXXimageXXX.png will be the one you throw out.
I just did a test and this works fine
Lump Apps and My Assets
Second-half of the test is commencing... the "fast" number is 3.3 seconds.
Seriously, though, I'm looking forward to seeing how this all plays out in the end.
Traditional - 4.3 Seconds
White Box / 0.01 timer - 3.3 Seconds
What do you guys think about my trick mentioned above. I can post my test if you guys like but it is perhaps clear the way its told (dunno if my Dunglish is well enough
Lump Apps and My Assets
Normal (images already selected): 5.8s
No Timer, Change Attribute technique: 6.0s
Timers set at 0.001s: <1s loading time, but white squares until 5.5s
So - the timer method has it overall, and wins in initial loading times as well. But, it might result in blank images for a noticeable period of time if your project is image heavy. Loading FROM a white screen might help to conceal this. The one thing you definitely shouldn't bother with is changing the images without a timer.
Next, I'll try it with adhoc builds and see if that makes any difference.
Lump Apps and My Assets
Normal: 7s
Change Attribute: 6.7s
Change Attribute with timer: <1s - but takes 6.2s to fill in white squares.
I also tested level switching in the viewer, going between two identical levels. For this, I used the timer method and the normal method. Both resulted in sub 1s load times when the second level was loaded. With the timer method, however, it appeared to have "forgotten" the images and still took 5.5seconds to change from white squares.
So - at the moment it would seem like a pretty good trick for things like the menu screen TSB was talking about, but seems to generate some disadvantages when it comes to changing between similar levels.
Ludwig - next on my list is to use interp. as a timer, see if that changes the situation. Also, your trick with deleting duplicate images seems to be a pretty clever way of side-stepping the biggest drawback.
But yeah... blank images are a problem. I don't notice this in BOT because the game fades to black during scene transitions.
So - at the end of all this fun and games, I've come to the conclusion that I'll probably use the timer technique for my menu screen and not bother with it the rest of the time, as most of my objects remain the same from one level to the next. It would be interesting to know whether any of you who do use it have experienced noticeable "white squaring" at the start of levels in a "real" game situation - obviously, my test had a pretty huge amount (48mb) of images.
In summary:
Timers work, but images take some extra time to load - myth confirmed
Using the method but not using timers doesn't give any appreciable advantage - myth busted
Thanks.
edit: oops sorry i think i found my answer. Thanks to TSB GSHelper vids. Damn i love that site. If i manage to have a big sale on my upcoming game i'll definitely support his product.
What if a Rule was used instead of a timer?
If self.image ≠ self.name
Then change self.image to self.name
This way, I can quickly copy that instanced actor and only need to rename the actor "picture.png" to use the right image... and the rule would solve the problem of disappearing backgrounds.
The problem is that the extra rules would eat performance.
you can still use it in a behavior such as change attribute
I need White Square, and make them Change image within a timer, lets say, 1 second (I Will change a lot of hidden images, not the images that are shown)
But Change image preloads it?
SO How Can I change the image?
Cheers.