Sorry your browser is not supported!

A 2D Camera for AppGameKit T1 (Only tested on 1088).

Download from Here

Includes a Camera Trap
A configurable zone around player sprite that allows movement of the sprite without scrolling the screen.

Damping
Smoothly scrolls the tracked sprite into view (Configurable, use 5 as a starting point) Setting this value too low will allow the sprite to move off the screen as the camera will lag behind. Setting the value too high will cause the Camera to sharply snap to the tracked sprite.

Camera Limits
Allows setting of limits for camera movement in addition the tracked sprite can also be locked to the same limits.

Simple to Use.

Initialise the Camera :

Camera2DInit(offset x, offset y, damping , lock Sprite )
Offset x and y determine the top left location of the camera trap
Damping (as above)
Lock Sprite: 0 = false 1=true. If set to true the tracked sprite will not be allowed to move outside the camera limits.

Set the Camera Limits, Trap and debug Mode.

(Once the camera has been initialised the global variable Camera1 can be used to set the camera properties)
Camera1.trapSize.X = 1024 / 3 // Width of the camera trap
Camera1.trapSize.Y = 768 / 3 // Hight of the Camera trap
Camera1.debug = 1 // 0 = false, 1 = true , When turned on a transparent box will show //the trap area
Camera1.lookAhead.X = 0.0 // lookahead x ,y allow addition space in the moving direction, //normally used on small mobile screens
Camera1.lookAhead.Y = 0.0

Set The Camera:

Camera2DSet(spriteId,top x,top y,bottom x,bottom y)

spriteId The spriteId you want the camera to start at
top x Camera limit top X position
top y Camera limit top Y position
bottom x Camera limit bottom X position
bottom y Camera limit bottom Y position

Tell the Camera to follow a sprite:

In your main game loop after you have updated the player movement

Camera2DFollow(spriteId)

spriteId The Id of the sprite you want the camera to follow.

Additions:
Includes a simple Camera Demo that shows how to track a sprite with the camera. The demo also includes the Screen Shaker as its easier to see the effect within a mock game. To trigger the shaker move the player straight up to the top platform (you should see falling rocks and lots of shaking).
The TileMap lib is far from complete but it does include a couple of nice functions that will look a the tile data and create a smaller number of collision areas, rather than each tile having its own collision area.

Wow, great stuff.

Thanks for the code, very useful stuff.

Do you mind if we look at the code and play with it?

Thanks

You are welocme to do what you want with the code. I still have ths zoom code to add to the camera which will probably be in the next few days.

If you have any ideas for the camera etc it would be great if you can pass them back so I can include them in the lib.

Yes i tried it and your code can be very useful !!! Well Done !

I tried it in my little golf game and it seems to slow the game down, so not quite sure what is happening there. The demo works fine, but trying in my game reduced it to a crawl. I have only hedged it in quickly, and it is probably something I have not implemented correctly or some of my old code still conflicting, more than likely. It also seems to push the ball to the left of the screen at 0 rather than at the tee position for some reason.

I'll have to look into it further when I have more time, suggestions could be useful in the meantime though

Okay, I have had another look since posting, and have it almost implemented by the looks. It is now locking the game out when loading a new level, I assume something needs to be reset at this point. I am hopeful I can get this working as it is looks pretty nice so far, and hopefully will eliminate a bug I was getting with the screen scrolling too far occasionally.

I'll keep you updated.

Fixed it. It was the overlay sprite (for debug) being recreated again and covering the buttons every so often. Seems cool though nice job!

Seems as if you fixed the issue already.

Anyway I have attached a simple project which shows the Camera working with a physics ball (Sprites are only used so you have some kind of visual reference).

One suggestion;

You could change the working of the "lock Sprite" parameter of Camera2DInit() to accept the ID of the sprite to follow, ie.

0 = false - don't follow
1 = true - keeps compatibility with existing code
> 1 = ref - store in a global variable

Then if Camera2DFollow(spriteId) stores spriteId in the same global variable, you could have a quick call to get it to track the sprite already known about - which doesn't need the parameter passing each time;

eg.

Camera2DFollowSame()

Kind of fire and forget mode.