Camera Control Tutorials

#1 @Aaron, off the top of my head, if you wanted to 'push' the camera, I would maybe put a static 't2dSceneObject' (there invisible, heh) at the edge of the level screen, and enable collisions on it, when the 'onCollision' callback is made, move the camera and re-position the block ...

You could do this 'push' in both directions, to implement something similiar to say the Super Mario 2/3 screen scrolling, where the player could dance around in the middle without the screen scrolling, but as they neared either edge, the screen was 'pushed' in that direction.

#2 Thanks David, I'll give that a shot.

Any other ideas out there?

#3 @David, I'm working on what you suggested, I've created the sceneobject and put it where I want it, and enabled collisions. I'm going to write some functionality to move the camera, however, when you said "re-position the block" you meant the sceneobject which I created, which isn't mounted to the camera, I assume. Could I mount it to the camera so that it's constantly smaller than the visable area?

#4 Something like this:

function cameraPushBox::onLevelLoaded(%this, %scenegraph)
{
  %force = 0;
  sceneWindow2D.mount(%this, "0 0", %force, true);  
}

#5 I was hoping that I could do this with one sceneobject, and keep the play inside that, but I'll need the use each scene object as a boundary, so one for each direction that I want to control the camera.

#6 @Aaron, yes, unfortunately, TGB does not have 'inverted' collisions. So two objects would be necessary to create a 'boundary', a third and fourth object would be required to move the camera up and down as well -- once the collision is triggered, you could move all the 'boundary' objects in the direction necessary (possibly store the direction in a dynamic field for the object, so the code is reusable)

function cameraPushBox::onCollision(%this, ....)
{
  switch$(%this.direction)
  {
     case "left":
     case "right":
     case "up":
     case "down":
  }
}

you could also have the 'step' increment stored in a dynamic field as well ... allowing the character to move 'faster' left and right, slower 'up' and 'really fast' down ;)

Let me know how this turns out for you ...

#7 So using the same class for the 4 edges, I can create a "dynamic feild" called direction, and assign a direction to each box. Then script specifics, correct?

#8 One more question, In a switch statement, is this the correct syntax for when the player is colliding with the left and up edges?

case "left && up":

Thanks!

#9 I know I am a little late throwing my hat into the ring here. but as I thought this through there are a couple of ways I think you could approach this without creating additional objects, fields and collision checks.

The first thing that came to mind is using the players world limit and doing your updates to the camera in the onworldlimit callback. You would need to do your camera updates and update the world limit boundries for the player. I did a quick test and was able to get acceptable results, I didn't have time to get into it any further. I would post the code but I am not by my system right now.


The other way I thought it could be handled is do a calculation on the distance of the player from the camera in an onUpdate Scene callback. This would be more transparent but does add a little overhead as the checks are done on every frame. With the right code it should not be an adverse effect on the frame rate.

#10 @ Guy, I actually scrapped what I was working on before. I took some ideas from the camera control system for the RTS tutorial. Basically you specifiy a buffer and compare the position of the player to the width of the window +/- the buffer, and then move the camera. I think this is a more robust system since it eliminates moving a world limit or a sceneObject. However, last time I worked on it, it was still buggy and not working how I was expecting. I'll re-visit the problem and hopefully kill a couple bugs. Also, when my player walks up to the edge, I wanted to camera to smoothly pan at the exact speed as the player, so that the distance between the player and edge does not change. Right now this results in a very choppy camera movement. I'll revisit my code in the next couple days and post it here.