Back to For Beginners

SDL sidescroller help

For Beginners

Started by chosenkill6 November 07, 2011 01:42 AM

2 comments, last by rip-off 12 years, 5 months ago

chosenkill6

163

Author

November 07, 2011 01:42 AM

Hi
I've just started my next project in SDL
I'm pretty new to game programming. Made a pimped out game of Pong, and now I wanna move onto something a bit more complex. I'm hoping that this game will help me learn about a 2D camera system, basic gravity, and tile based map etc.

I also plan on making a map editor that can create a text file with numbers in a matrix and each number is a type of tile. This will be a map in my game

Just need some help starting out. Here are a few things that I need advice in:

Basic game logic about the camera, how would I do this? I've never used a 2D camera before.
How to load a map? Do I blit tiles as they come to the edge of the screen? Very confused about this part.
Also anything else you think tht I should know before starting this project?

I plan on this being my summative for my grade 10 computer science class

Thanks!

rip-off

11,000

November 07, 2011 10:03 AM

For a camera, think about your game world being drawn on a giant fixed whiteboard. You then have a smaller empty picture frame you can slide around the whiteboard, the area of the whiteboard that is inside the picture frame is your screen. Sliding this around is like moving the camera. So the player moves left, the frame moves left.

However, imagine now that instead you detach the whiteboard from the wall, and mount it to sliders. The small picture frame gets fixed in place. If the player wants to move right, instead of moving the frame you can slide the whiteboard left. Can you see this gives the same affect as moving the frame, from the point of view of a person who is looking directly at the frame?

So, if you have a map that is much larger than the screen, you can store a "camera_x, camera_y" pair. These values might be fixed to the player in some games. In other games the camera might be more fluid, acting like it is attached to the player using a spring. Even in the former kind of game, you might temporarily clamp the camera position when the player approaches the edge of the screen, so it isn't entirely fixed on the player.

When you draw the map, you can do some basic culling to avoid drawing objects that aren't on screen. This involves some basic rectangle intersection mathematics. You'll probably have such routines anyway for

Then, you transform these objects from world space (their position relative to the origin on the virtual "whiteboard") into screen space (the position relative to the origin on the rectangle) by subtracting the camera_x, camera_y values from the objects world co-ordinates.

You can use the same technique for tiles. The simplest thing is to redraw the tiles every frame. This avoids lots of the complexity of trying to selectively redraw tiles as sprites move across them. You should be able to algorithmically enumerate the exact set of tiles that are on screen without resorting to rectangle intersection tests.

Loading a map depends on the map format. A simple map format is a text file, where each letter in the file represents a tile type. There are, I suspect, many guides to implementing such a loader.

blog | twitter

chosenkill6

163

Author

November 07, 2011 11:42 AM

For a camera, think about your game world being drawn on a giant fixed whiteboard. You then have a smaller empty picture frame you can slide around the whiteboard, the area of the whiteboard that is inside the picture frame is your screen. Sliding this around is like moving the camera. So the player moves left, the frame moves left.

However, imagine now that instead you detach the whiteboard from the wall, and mount it to sliders. The small picture frame gets fixed in place. If the player wants to move right, instead of moving the frame you can slide the whiteboard left. Can you see this gives the same affect as moving the frame, from the point of view of a person who is looking directly at the frame?

So, if you have a map that is much larger than the screen, you can store a "camera_x, camera_y" pair. These values might be fixed to the player in some games. In other games the camera might be more fluid, acting like it is attached to the player using a spring. Even in the former kind of game, you might temporarily clamp the camera position when the player approaches the edge of the screen, so it isn't entirely fixed on the player.

When you draw the map, you can do some basic culling to avoid drawing objects that aren't on screen. This involves some basic rectangle intersection mathematics. You'll probably have such routines anyway for

Then, you transform these objects from world space (their position relative to the origin on the virtual "whiteboard") into screen space (the position relative to the origin on the rectangle) by subtracting the camera_x, camera_y values from the objects world co-ordinates.

You can use the same technique for tiles. The simplest thing is to redraw the tiles every frame. This avoids lots of the complexity of trying to selectively redraw tiles as sprites move across them. You should be able to algorithmically enumerate the exact set of tiles that are on screen without resorting to rectangle intersection tests.

Loading a map depends on the map format. A simple map format is a text file, where each letter in the file represents a tile type. There are, I suspect, many guides to implementing such a loader.

Thanks for the detailed reply
Your camera example was great, I think I have a basic idea of what I'm gonna do to implement this

The map loading part seems really complex, do you suggest reading the map as required, or should I read the whole thing and load it into an array?
Also, when loading the map, why would I need the rectangle intersection? Can I not just have a define with the width of my pixels and then apply a tile, then move over that amount? One more thing, might seem really noobish...what is culling?

rip-off

11,000

November 07, 2011 12:52 PM

The map loading part seems really complex, do you suggest reading the map as required, or should I read the whole thing and load it into an array?
[/quote]
Read the whole thing into an array.

Also, when loading the map, why would I need the rectangle intersection?
[/quote]
You don't need it for loading the map. What I was trying to say is that you should be able to determine the exact set of visible tiles, you don't need to cull the non-visible tiles like you might want to do for sprites. See below.

One more thing, might seem really noobish...what is culling?
[/quote]
Getting rid of things you don't want. In the context of computer graphics, culling means deciding which objects are likely to end up on the screen. Culling will always be performed at some level, because pixels will never be rendered off screen. However, "high level" culling can be far more efficient than low level culling. Imagine a complex game where each actor is composed of multiple images. Culling the entire character in one bounding rectangle test would be more efficient than getting SDL to cull each image as you try to blit it.

It isn't necessary to implement culling, but it is something to consider. It is said that premature optimisation is the root of all evil. Try the simplest thing first (render every image for every actor). If the game runs too slow, then you can profile the code and make informed decisions about how to get the game to perform better.

blog | twitter

SDL sidescroller help

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

SDL sidescroller help

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines