Performance question. Accessing, destroying actors.
ohtukrw
Sir dogeMember Posts: 106
in Help Wanted
I have a static background, scene size W 13310 x H 600. My hero moves relative to the scene and comes back to start point after the scene is completed, appearing as if it is endless.
Should I be worried about it affecting the game play performance, because of its size? Is there a way only to show and access the pre- downloaded image only when the hero reaches a certain point (aka do it in chunks) and make the rest of the background images inactive?
I would imagine that this will have to be done with my spawning actors as it would crash the game otherwise. If the visible game screen width is 667, destroy actor if it is 333.5px away relative to the actor.
However what about the static background?
Comments
Yes 13310 image width is going to have some kind of serious issues. When the image file itself is bigger than some limit (like 2500 or 4000 or something), it doesn't show up on the phones when you test them (ad-hoc). It's just black. So you might have to scale your image down or cut it up and say something like:
When background is between location x=400 and 500, change image to ...image2
Or whatever. There's a lot out there to search and help you
**EDIT: My bad @Socks I was more specific there
Having a large scene size of 13,310 * 600 pixels will have no detrimental effect on performance.
Guys I added a lot of static coins 32x42 size 50px gap in between them and it dropped the fps to 47 and ram increased to 80mb! Without the spawners even operating... Scene that size with multiple actors does have a performance issue. Anyone else had lag fixing experience???
so gutted
https://postimg.org/image/a5lejexup/
Is it related to not using tables and separate actors instead?
Scene size has no effect on performance.
80mb of RAM isn't bad at all. As an example a device with 512mb ram won't crash until around 256mb usage on a single app for iOS. Newer devices have 1-2gb of RAM and can use 512/1gb. So not a RAM issue.
It sounds like a logic issue if fps is dropping. Hard to say exactly what but it's common to drop frames when using tons of spawns or logic that iterates often (loop, constrain, every timer).
Follow us: Twitter - Website
What would you personally do to avoid lag?
Sorry to break the news
but facts are facts, scene size has no effect on performance.
I flagged it, not because I thought you were wrong, it was because you were repeating yourself with no actual contribution to the topic. You could offer your own more experienced perspective, share ideas, insights to less able users, use arguments. Your comments are mostly sparked by self interest of disproving other people.
The main goal in getting back FPS is to not overload the CPU/GPU cycles. This could mean many things depending on the game.
For example you wouldn't want to spawn non-stop, have particles going at a spawn rate of 500, loop twice per frame, and have collide with high accuracy on with hundreds of actors.
It's best to think of things in frames. 60 FPS means 60 frames per second. What that really means is that on the back-end every 1/60th of a second it scans your code for changes (it's actually faster for certain behaviors/portions of the engine and slower for others, but 60 is how fast the graphics portion renders at a maximum.)
So every 1/60th of a second Gamesalad scans code from the bottom layer up, and then each actors code is scanned from the top down looking for changes. It doesn't always keep this order 100% depending on how the logic is written and how overloaded the CPU is, but it's pretty good at sticking close to it.
The problem is that when you have too much going on in one of those scans the CPU(or GPU) gets behind a bit and starts to drop frames. So it's waiting/struggling to process instructions, and then gets more instructions, and at some point it has to go "this is too much, i'm just gonna skip a few things here" and that's traditionally what is called lag.
As the game plays out you need to find ways to sort of split the load up on the CPU up over time. Things like setting up rules so you only have active behaviors for whats in camera view vs always running a behavior whether it's in view or not. Or setting up variables that detect an event so rules start firing only after that, rather then; let's say having an actor with alpha turned off but it's firing the rules anyway that don't necessarily need to be.
What I call "floating" behaviors can be a real killer, or basically, logic/behaviors that's always going with no rules. Such as constrains in an actor with no rules. So try and really think about the chain of events that happens as your game gets going. Is there a point where a ton happens at once? Does it need to be that way?
Of course you can get more granular and start evaluating every behavior for it's individual performance, and as I said before there are some that are notorious for killing performance. Loop, constrain, every timer, particles, display text, and some types of collisions are all ones to be careful with. But none of them are inherently bad.
Then of course because this all rides on the CPU/GPU your test devices itself can matter greatly. A Mac desktop CPU/GPU will have no problems with almost anything you throw at it. An android CPU/GPU could range from terrible dual core to a extremely powerful octo-core. One will obviously drop those frames more often then another.
The best thing to do is continually iterate on your code and test to see if performance is improving or not. It can take time to get good at writing well structured code that lessens the strain put on device.
You can always post your code on the forums and usually experienced devs will help you out with writing it better.
This only touches the surface of what optimization can be (and i feel like I wrote a book
), but it should give you an idea I hope of what might be causing your issue.
Follow us: Twitter - Website
//
hahaha r u serious!? You cannot ask for help and then get mad at the person helping you
lol @Socks is #winning
It's easy to misinterpret things on the internet. No tone to accompany the text. I think @ohtukrw was hoping for more of an explanation to accompany the facts coming from a place of frustration because of a lack of detailed information on the subject in general.
Do a google search for "Gamesalad Optimization" or "Gamesalad performance" and you get old articles with titles like "31 tips for optimizing GS" or "10 tips for someone just starting out" which are 60+% false or negligible gains.
Optimization can be daunting, especially when you don't have good documentation on it anywhere around GS's website. Just smatterings of misinformation from forum posts and a few golden nuggets here and there.
Follow us: Twitter - Website
I found out that my coins are causing the performance issue. They are small 32x42, but I have made loads of them. I even use self.time and real attributes, instead of ''after'' timer to save that cpu. They are not moving. Few simple rules to change alpha.
They are all seperate actors. I am not sure, but is it related to me not using those tables? Or does it have anything to do with layers? Or is there a way to access them only when on visible screen? I have no idea how GS handles the actors.
My hero is the only one moving...
I also found this advice.
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:
Landscape gameplay: If attribute game.MainCharacterPositionX > self.Position.X + (game.Screen.Size.Width/2)+(self.Size.Width/2), then destroy or move.
Should I use it?
if you have a billion of them on screen yeah it will mess with the performance. If you have "constrain, loop" or other constantly running rules in all those actors the performance would be horrible.
Yes you should use something like that you said. Which is if it is on the screen you can see it, else it is off/not running
Self.time and real attributes can be just as intensive(or more) as an after timer. And yes, rules like that may help to alleviate the cpu load as GS will continually trigger logic on an actor that hasn't been destroyed and is on the usable scene space.
You could also try using the replicate behavior if the actors all use the same type of logic, or spawning only what's needed in the camera space at a time.
Another option is to "recycle" the same actors so that instead of using tons of actors on spawn and destroy you use a pre-set number that as they move off screen,they then move back into place and then start over.
Follow us: Twitter - Website