Performance / Optimization

madmassey

So I've been reworking the core prototype stuff in my project file for efficiency before I go out and start doing all the gameplay, and I had a few questions about optimization. I went through the project file to remove spawning / destroying and it almost seems like performance is worse on my 3GS. So I was wondering if any of these things could cause performance issues -

- I increased the height of my main test scene to fit all the entities that I was previously spawning... so instead of 960x320, it's 960x576. Could this cause significant problems? Especially if the width of the scene got up to 2400 or so?

- To help conserve space and make my project clean, I shrunk all my actors down really small, and am changing their size attributes before displaying them on the main screen. So, for a full screen image, the image file is 960x640 (resolution independence), the size I expand it to once it's in use is 480x320, and the size I store it in in my project is 75x50.

- On that note, could using resolution independence in general have a negative impact on the performance of lower end hardware?

- Whenever I expand an image, I leave it there with an alpha value of 0 on the main scene in front of the camera... so I'm not constantly moving it off and on the screen, just hiding it. But with several actors with alpha channels overlapping each other, I'm concerned that alpha overdraw may be an issue.

And any other general performance tips (sans the spawning/destroying thing) would be nice. Any help would be greatly appreciated!

MotherHoose

madmassey said:
So I've been reworking the core prototype stuff in my project file for efficiency before I go out and start doing all the gameplay, and I had a few questions about optimization. I went through the project file to remove spawning / destroying and it almost seems like performance is worse on my 3GS. So I was wondering if any of these things could cause performance issues -

- I increased the height of my main test scene to fit all the entities that I was previously spawning... so instead of 960x320, it's 960x576. Could this cause significant problems? Especially if the width of the scene got up to 2400 or so?

you do NOT have to increase the screen size to have all the entities available when needed.
actors can be dragged to scene and then moved to the surrounding grey area and still always be accessible for play.
just changeAttributes for X and Y.

- To help conserve space and make my project clean, I shrunk all my actors down really small, and am changing their size attributes before displaying them on the main screen. So, for a full screen image, the image file is 960x640 (resolution independence), the size I expand it to once it's in use is 480x320, and the size I store it in in my project is 75x50.

this is totally unnecessary work ...the images are loaded at runtime in the size initially imported... the only in important size is the display size... making them smaller and then larger only increases the work the device has to do... and the programming you do!

- On that note, could using resolution independence in general have a negative impact on the performance of lower end hardware?

yes... but devices not upgraded to iOS4.0 ... may have performance issue with any intense game.

- Whenever I expand an image, I leave it there with an alpha value of 0 on the main scene in front of the camera... so I'm not constantly moving it off and on the screen, just hiding it. But with several actors with alpha channels overlapping each other, I'm concerned that alpha overdraw may be an issue.

whether you change the Y to -200 or the alpha to 0 ... the gameEngine still has to do something ... as the X and Y are always in memory... think it is better to change one of them. and avoid display clutter and conflicts with layers, etc.

And any other general performance tips (sans the spawning/destroying thing) would be nice. Any help would be greatly appreciated!

ah @madmassey... you are putting a terrific amount of effort into your project... I commend you!

use ImageOptim to cleanup gfx...its Free

MH

madmassey

Heh... It's never unnecessary work if it gives a clean and organized workspace without a performance hit. It just improves efficiency later on down the line. Running all my images through a compressor is a good idea, I'm gonna give that a try later on.

If anybody is curious about any of this stuff... It seems like changing image size and XY coordinates are both very cheap performance wise. Scene size, who knows. I'll just make it bigger as I go on until it starts to hitch I guess.

As I suspected though, a HUGE framerate killer is overdraw. When I had all the UI elements initialize invisible in the middle of the screen, performance was totally shot. I then set it up to move elements to the same coords offscreen, and it got a little better but still had issues. So I tried moving the stuff offscreen and making sure that nothing at all was overlapping once off screen and got a rock solid 60 fps. That sort of thing is a big problem in 3D games too, when you have a bunch of trees or shrubs made with alpha planes packed into an area. Of course, maybe touching 10 overlapping actors is bad in general as well.

simo103

madmassey .. thanks for the tips ... this particular topic is very perplexing to me as there seems to be many ways to achieve a desired result but only a few of those are right performance wise.

One of the things I'm wondering about is a jagged border I have for my scenes. It is 480x320 with most of it transparent (ie: the middle where gameplay takes place). Any idea if this would be better achieved performance wise with four images of smaller size .. one each for each side (ie: top, bottom, left and right)?

HoneyTribeStudios

I started replacing my constrains and timers with the following:

create an integer attribute (call it zero) and give it a value of 0

When zero = ceil( selftime x 2) %2

... change attribute

The % means modulo. The x2 means the attribute change will occur every second. So put in higher values for the change to take place more often.

Still need to test the performance figures. But from what I've read using the game or self timers is better than adding additional ones.

simo103

thanks shaz .. will try that also and will report back

simo103

okay I made a copy of my project and decided to try a few things (tested using a 2nd gen iPod Touch in the GS viewer:

1. Opening scene is four panels with camera move to show game logo then two level choosing panels and a options/settings panel.

Was: getting FSP of 14.5 with Images 25.8megs. Took out one border that was a full scene image size 12kb .png

Now: FSP 47.5 images 20.8megs (so removing one overlapping 12 kb image resulted in that performance size change

2. GAME scene is a three panel with camera move

WAS: FPS 42 Images 19.3megs

Now: removed borders FPS 58 , images 11.3

deduction: major performance hit from overlapping images. I am going to compile some more before and after tests and see if I can come up with a selection that could really help people make the right choices. Would appreciate if others would like to join in. I think to be effective and accurate we would need to just change one element so you are comparing the original to one type of change to see the effect.

madmassey

Yeah... I think the key is that it was a large, full screen image with transparency, so the alpha on it was overlapping every element in the scene... Plus every time you click it had to check the actor for rules? That one's a guess. But I think the issue is how the engine handles layers. A simple solution to your problem is to either make the border a part of the background image or, if it scrolls, make the playable space smaller and put the border as 4 pieces not overlapping anything on the outside.

Also, after some more testing on my own stuff, I think spawning and destroying actors can be a positive thing for actors that have a ton of rules, assuming you're only spawning and destroying them once. Because even if it doesn't free up resources image wise, it doesn't have to deal with all the rules simultaneously.