Camera for 2d game

Paha picture Paha · May 12, 2012 · Viewed 12.3k times · Source

I'm currently making an awesome (in my mind) zombie game and I need to know a good way to make a camera. I am using the Slick2d library along with MarteEngine for java.

I'm kinda new to java and jumped straight into a library before really getting deep into swing and such so this is probably a lack of graphics knowledge. I read on a tutorial that you can't actually move the window of the game on the map so instead you need to move the map and objects to make it seem like the camera is moving.

If I was to do it this way it seems like it would be very resource intensive. I would have to loop through every zombie, survivor, object, hitbox, etc to move their coordinates. I've already tried this method once and things weren't really moving the same speed. That may have been due to me handling it with different update speeds.

I've seen a few things on using graphics.translate but I don't really understand it. So.. any suggestions to making a camera move would be awesome! Thanks in advance.

Answer

jefflunt picture jefflunt · May 12, 2012

You can definitely move the camera. See my answer to this question explaining how to move the camera, render the world relative to said camera, and some other useful tips on how to do this and how to decide what to draw on the screen as the camera moves.

While it's totally possible to use translate(x, y), that alone doesn't solve clipping issues (how to know what to draw on the screen), and it's not a catch all. Also, when you think about it, there's really not much of a difference between translating the surface and moving the camera. It's all relative, and so long as the pixels are moving in the right direction, it doesn't really matter if you're "moving the camera relative to the world" or "moving the world relative to the camera" - they're essentially the same operation.

As far as Swing is concerned, be glad you didn't start there. Swing is designed for desktop applications with windows, menus, buttons, complex event systems, and the like. For a number of reasons Swing is terrible for games, not the least of which is the way the rendering pipeline works in Swing; it's fine for desktop apps, but becomes a pit of despair for games and most types of rendering that need to be real-time, and graphics intensive. This is all okay because Swing wasn't built to solve the problems of game developers anyway.