How to render a 2d side-scroller game

Question

I do not really understand the way I'm suppose to render a side-scroller? How do I know what to render when my character move? What kind of positionning should I use for the characters? I hope my question is clear

Answer 1

The easiest way i've found to do it is have a characterX and characterY variable [integer or float, whatever you want] Then have a cameraX and cameraY variable. Every object in the scene is drawn at theObjectX-cameraX, theObjectY-cameraY...

CameraX/CameraY are tweened by a similar-to-midpoint formula so eventually they'll reach playerx/playery[Cx = (Cx*99+Px)/100] ... yeah

By doing this, every object moves in the stage's space, and is transformed only on render [saving you from headaches]

Answer 2

• Use a matrix to define a camera reference frame.
• Use space partitioning to split up your level into screens/windows.

Think of your player sprite as any other entity, like enemies and interactive objects. Now what you want is the abstraction of a camera. You can define a camera as a 3x3 matrix with this layout:

[rotX_X, rotY_X, 0]
[rotX_Y, rotY_Y, 0]
[transX, transY, 1]

The 2x2 sub-matrix in the top-left corner is a rotation matrix. transX and transY defines the translation part, i.e the origin. You also get scaling for free. Just simply scale the rotation part with a scalar, and you have yourself a zoom.

For this to work properly with rotation, your sprites need to be polygons/primitives, say like triangles or quads; you can't just apply the matrix to the positions of the sprites when drawing. If you don't need rotation, just transforming the center point will work fine. If you want the camera to follow the player, use the player's position as the camera origin. That is the translation vector [transX, transY] So how do you apply the matrix to entity positions and model vertices? You do a vector-matrix multiplication. v' = vM^-1, where v' is the new vector, v is the old vector, and M^-1 is the matrix inverse. A camera needs to be an inverse transform because it defines a local coordinate system. An analogy could be: If you are in front of me and I turn left from my reference frame, I am turning your right. This applies to all affine and linear transformations, like scaling, rotation and translation.

Split up your level into sub-parts so you can cull objects and scenery which does not need to be rendered. Your viewport is of a certain size/resolution. Only render scenery and entities which intersect with your viewport. Instead of checking each and every entity against the viewport bounds, assign each entity to a certain sub-screen and test the bounds of the sub-screen against the viewport and camera bounds. If your divide your levels into parts which are the same size as your viewport, then the maximum number of screens visible at any particular time is:

• 2 if your camera only scrolls left and right.
• 4 if your camera scrolls left, right, up and down.
• 4 if your camera scrolls in any direction, and additionally can be rotated.

A screen-change is an event you can use to activate entities belonging to that screen. That could be enemies, background animations, doors or whatever you like.

Answer 3

If this is your first foray into writing a side-scroller, I'd suggest considering using an already existing game engine (like Construct or Gamemaker or XNA or whatever fits your experience level) so you don't have to worry about what order to render things and how to make it all work. Mess with that a bit--probably exploring a few of them--to get a feel for how they do things then venture out to your own once you've gotten used to it. Not that there's anything wrong with baptism by fire but it can get pretty overwhelming in my opinion.