Which of these is more efficient/less processor intensive?

AfterBurnett

Hi again guys,

Just wondering, for my side-scroller... should I have the scene set as 480x320 and spawn objects for parallax scrolling (I have it set up that way at the mo), or should I set the scene as something much wider but same height and move the camera through the scene? I'm thinking this way it'd be much easier to place enemies rather than using a bunch of timers and guesswork.

Also, if I do make the scene wide and have the actors placed there, are they ALWAYS there or do they only spawn when they get close to the camera? Would be pointless placing a bunch of actors that move in certain directions only to find they'd finished their attack waves and left the screen before my ship got there

At the end of the day, I'd like to know which is the best approach. I'm leaning towards the big scene idea as it would give me room to do a little more with the game... just not too sure if it's the recommended approach.

Chunkypixels

i agree, would be useful to know about the spawning off camera issue you mentioned.

I'd suggest using the wider scene, so you can have a bit of variety in background scenery, then place invisible spawner actors instead of fully fledged actors.

So when your main actor, or camera comes into contact with the spawners it then spawns the relevant actors just offscreen. This way you can have less actors active in your scene, as spawners could be used to activate patterns or groups.

if that makes sense....

rebump

If you use a wide (multi-screen width) scene, all actors do their thing even if they are not on screen. You would need to have the camera or the player character's X/Y position in game attributes that the off-screen actors could check (using magnitude()) to determine they are close enough to being on-screen to start their routine. Problem with this is each character would be using a constrain for best results or a timer wrapped check for less time accurate results. Good thing is you can set it up so the constrain is no longer active when they are on-screen or behind the player (i.e. passed the player actor already).

Some off-screen actors can just do their thing even while off-screen so the issue with constrain is not present. However, they are still in memory and using resources to do their thing. A benefit for this method is there is no player perceived overhead for spawning them since they were placed and are present from scene start (i.e. spawned right before scene start).

Using the single screen width scene method saves memory use for not having all the scene's actors in memory all at once but they introduce additional (and sometimes complex) logic in the "scene controller" to coordinate the re-spawing of things that appear on one side and disappear on the other. You, of course, also introduce the spawing of those items over and over too.

The actor count and complexity is something to consider with either method. More actors in the "wide" scene means more memory and processor use. More actors in the single screen width scene means more and more spawning.

The wide scene is easier to deal with in terms of setup but could use too much memory to allow your app to run safely on all iDevices. The single screen width scene may be spawning too much at once and impede performance on older iDevices.

In short: test both methods to determine best results. :-|

There is mention that if an actor is a certain distance or greater from the camera, it is automatically destroyed. I would hope it is based on distance from the edge of the scene as opposed to camera and I am guessing it is since I have setup large multi-screen scenes where the actors are present doing their thing and haven't gone away. (Or it could be they were still close enough...)

AfterBurnett

Thanks for the help... looks like I'll have to do some testing!

AfterBurnett

Damn, I wish enemies were inactive when offscreen... I just had a play... SLOWDOWN!!!! And that's on my Mac! Way too much happening at once...

scitunes

In my last game (xtreme mountain busing) I wanted to have the bus travel on moving boulders for the entire level which was quite long. It was very fun on the mac but of course when I tried it on an iDevice it crashed immediately. So I had a rule in the boulders that says

when self position.X is < (cameraOrigin.X - 300)
-change attribute selfposition.X to cameraOrigin.X+300

I did this in about 4 or 5 round boulder actors and it feels like there are hundreds of boulders throughout the level when really the same 4 are being "recycled".

You could take this same approach with the bad guys. Instead of destroying them just change their position. It will "feel" like a new bad guy when really it is the same actor that has been moved.

rebump

@sci: Thanks for adding that to clarify. I got so wrapped up in my write-up that I left out one of the major points I was trying to make about the "single screen width scene" (which was what you state above). I was going to mention it at the end of this paragraph:

"Using the single screen width scene method saves memory use for not having all the scene's actors in memory all at once but they introduce additional (and sometimes complex) logic in the "scene controller" to coordinate the re-spawing of things that appear on one side and disappear on the other. You, of course, also introduce the spawing of those items over and over too."

@All: Basically, that method adds credence to the superiority of the "single screen width scene's" method but the spawn (or in Sci's example: re-use) logic can get complex (i.e. think of spawning various types of platforms in various positions/layouts in a platformer game).

Also, folks use the re-use method for "endless" scenes too.