Smooth Camera Offset

Hymloe

Has anyone come up with a SMOOTH camera offset solution?

My game runs relatively smoothly, but if I try to create a Dummy object that is always 150 pixels in front of the actor, and offset it from my player character using Constrain self.PositionX = playerCharacterPosX + 150...

...it's very jerky.

Can anyone suggest a way to offset the camera nice and smoothly?

This seems to be a problem that no one has solved, that I can find (except by making the game really simple, I suppose).

Surely this solution should (ideally) be just as smooth as using a Control Camera behaviour directly on the player character actor.


=======================
I would suggest to Game Salad:

I would suggest that the Game Salad makers should add an out-of-the-box "Offset Camera" field within the Control Camera behaviour, so that the player can simply type in their desired offset values.

It seems that their Control Camera behaviour works well. It's smooth, and always updated nicely. But once you try to modify the camera's position via another intermediate actor, jerkiness is introduced into that pipeline, if your game has some complexity to it.

So I am of the opinion that, to get a smooth camera offset, Game Salad may need to allow for that WITHIN the Control Camera behaviour itself, to ensure that the camera interpolation has it's own special priority within the game engine.

=======================

That's my 2 cents (as a Pro member). :P


Because using the Constrain offset approach just isn't smooth enough.

Any suggestions or advice?


- Murray

JohnPapiomitis

instead of using the control camera behavior and dummy actors try this. Unlock your player in the scene so you can access the scene attributes. Then constrain the camera.origin.x to self.position.x+150

SlickZero

It's been like that for months. It just popped up in one of the updates a while back, and there was talk of it being identified, and resolving it, but I don't think anything ever was. I had to toss the idea of a offset camera in one of my platformer/constant runner games because of the jerkiness, and had to settle for the actor to be in the middle of the screen.

Supposedly having the rules and anything associated with the constrain in the very top of the rule list so it's the first thing that's executed helps, but it did nothing for me when I tried it. The only thing that worked was tossing the idea away, and settling for the actor in the middle of the screen.

Wish I could help. I don't know of another way to have the offset camera.

SlickZero

Well whadda ya know. I tried your method John, and it didn't work. Then I went in and turned off "control camera" on the actor, and then it did.

I feel stupid…Learn something new every day I guess.

JohnPapiomitis

haha yeah its the control camera actor that gets jumpy. As long as you dont use control camera and do what i said in my post your good.

Glad i could help

Hymloe

Thanks John,

That is a good idea, and good to know how that works.

It largely works.

EXCEPT that now, my player character, who is very rule heavy, MUST be an instance in the scene to make that technique useful.

That's not very practical, as soon as you want to update your actor, you have to REVERT every instance of your player character BACK to the prototype, then make it a unique instance again, and RE-AD the camera rules back in.

If you have 50 levels, for example, this is really no good.

THE SOLUTION WORKS, but does not seem practical to me.

Is there a suggested work around for this problem I've outlined above?

I can imagine, maybe you could keep all your player character rules OUTSIDE of the actual player character actor. But then, you wouldn't have access to any player character LOCAL attributes, only GLOBAL ones. Which would still make some things tricky, and take you back to the above problem of having to occasionally (or regularly) go in and revert all instances back to the prototype, then re-apply the camera.origin rules again.

Thanks!

- Murray

Hymloe

This solution you've suggested, though John, is pretty much exactly how the whole offset camera thing should work!

I'm really not sure why an actor can't have rules inside that DO relate to the scene camera.

Surely these could be allowed, and then when the actor is created for a given scene at runtime, the rules work as applied to that scene.

- Murray

Hymloe

OK, I've tried optimising the implementation of this technique into something more workable for me…

======================

I've made an actor that just sits off the corner of each scene. It is a unique instance (unlocked), so that it can access the camera attributes.

I've then just added two Constrain Attribute behaviours…

Constrain scene.Camera.Origin.X to game.PlayerPosX-100
Constrain scene.Camera.Origin.Y to game.PlayerPosY-200

This sets the camera origin (bottom left corner of the camera view area) to be 100 left of the actor, and 200 below the actor.

Note that now, there are NO actors with a Control Camera behaviour on them!
This one set of rules now does everything, which is quite nifty.

Also, note that your offset could be a global attribute, or an equation, to make it easier to adjust the actual offset from a prototype actor, or an equation to do with how to lead the camera based on the player's movement vector, or such things.

======================


This is working fairly well for me.
And any jerkiness in there now is probably just down to my game's speed being a tad slow.

The Control Camera behaviour still seems smoother to me, as I guess Game Salad have implemented some sort of priority for it, or additional smoothing processes in there, or something.

But this is the smoothest camera offset system I've managed so far.

Thanks for the advice about using scene.Camera.Origin.X and Y, John!

- Murray

Hymloe

You may now have a problem, like me, that the camera can see off the edge of your scene, because of the offset. When my character gets right over to the right hand side of my long scene, the camera can now see of the edge.

My next problem is dealing with things like that! But I think I can come up with solution there.

- Murray

The_Gamesalad_Guru

John showed me this trick a while ago for my runner. I also had the same issue with the end showing so what I did was when my actor reaches the last camera area (on iPhone landscape the last 480 px) I interpolate the camera back to normal with an ease in/out makes a smooth pan and after my actor wraps the scene after 100px I interpolate back to the offset.

Hymloe

Cheers Frying Bacon,

I made a rule where the camera only moves if my player character is less than X distance from the right hand side of my scene. My camera just stops hard, and my player character keeps moving until off screen, then it snaps back to the left hand side. Works well for me!

Cheers.

- Murray

lebiscuit

i created a variable "thelook"

i interpolate my camera to "self.Position.X" to "scene.Hero.Hero.Position.X + game.thelook"

and now you can interpolate where you'r looking at, left or right

cheers

Hymloe

That sounds promising! I'll have to try something like that, and see if it smooths things out even more...

Thanks LeBiscuit.

ImpactBlueStudios

For those who are doing things like camera offset without constraining scene.camera.origin via an instance main character, make sure you order your actors in your scene correctly.

The character actor needs to be below the camera actor who does the camera constraining. This ensure that in each frame the new position is calculated b4 it is constrained to camera origin, effectively preventing jittering and a laggy camera.

Constraining an offset actor with the control camera on it is good too, but for those who are having the same issue as me, where I'm using an iphone 5 wide screen build and testing on the iphone 4 aspect ratios you'll realise the camera does not reach the edge of the scenes because of overscan cropping. This is why I had to drop control camera and manually constrain the camera origin via the above method, and just use a clamp via min(max()) to make sure you dont see past the edges of the scene.

Hope this helps.

sooknah@gmail.com

Hello everybody, this is my very first post after trying to learn GameSalad the hard way. Its a GREAT SALAD as long as you keep the salt and the vinegar in good proportion dude.. LOL..

Thanks to Hymloe's camera constraint solution I came up with a solution that does not kill your ACTOR/CAMERA processor priorities.

I would suggest

(1) Forget about CAMERA CONTROL
(2) Learn Interpolation (Its the best thing and most important ingredient for GAMESALAD
(3) CONSTRAINT ATTRIBUTE is very good.. but there's an even processor less expensive one --> CHANGE ATTRIBUTE.. use it to set the desired origin of your camera, relative to your actor
(4) Use the same INTERPOLATION that you use for your actor ONTO YOUR CAMERA.

Result: No more jerky actors or useless jitter in camera

djdee

hello,
am making and endless game. Theres a power meter that i would like to add to my screen. I had constrained the meter to the players.X & Y+ 400. But it jerks a lot.
My main actor is spawned from another actor so i cannot unlock the main actor and delete the camera control.
It would be really helpful if some give me the exact steps to follow as am not able to catch up with the above solution.
Thank You

jamie_c

Add the power meter on it's own layer, and make that layer non-scrollable.

djdee

thank you @jamie_c

jamie_c

You're welcome!

ETGgames

dont use interpolation its glitchy. Instead have a camera actor that follows your player and has control camera on it. Constrain player's x and y position to real attributes, and then have the linear x velocity constrained to 5(game.playerX - self.postitionX) and linear y velocity constrained to 5(game.playerY - self.positionY)

ETGgames

for the offset, just add the values to the constrain

Socks

@ETGgames said:
for the offset, just add the values to the constrain

These people are all dead now (OP is from March 2012)

PhilipCC

@Socks said:
These people are all dead now (OP is from March 2012)

I'm sorry to hear that. What did they die from... frustration?

Can you believe that I read the whole thread thinking that I was learning something useful before I got to your comment and saw 2012!

jamie_c

@Socks