Before we start, I’d like to say that this is an advanced SDL tutorial. You should have experience with creating SDL applications and some basic knowledge of getting a program with it’s libraries up and running.

First, we’ll start off with a very simple Game class to build the foundation of our demo project.

Game.h

Game.cpp

You should be able to compile and run at this point. Now we have a nice 800×600 window prepared for our bidding! The three double variables are used at keep track of elapsed time each tick. You can simply substitute in your favorite Timer class if you wish. I also turn off cursor visibility since we’ll be controlling an object with the mouse and we don’t want it to obscure our view.

Now we’ll need some sort of objects that we can collide together!

Entity.h

Simple enough, I hope. For each Entity we create, we’ll take in a filename for the for the image we’ll be loading. If you didn’t notice, SDL_image is included, as I’ll be working with PNG files with alpha transparency. Next, we take in the tiles across and tiles down in the spritesheet we’ll be using. Finally, a frame rate to determine how fast the sprite will animate.

Next, the member variables. I’ve created a simple Vector struct to hold position and origin information. Position is where the Entity will sit on the screen and origin is the center of the tile currently being drawn. This will make things simpler when we want to draw a sprite centered on it’s position. Of course, an SDL_Surface pointer to hold the image data we’ll be using. And last, variables to hold information about the spritesheet we’ll be using and handling animation.

Finally, two methods to update and render the given Entity. Now let’s implement these!

Entity.cpp

The constructor loads in our image using IMG_Load() and stores all our data about the sprite sheet. The destructor ensures we have no memory leaks by freeing our SDL_Surface. Update chips away at our frameTimeRemaining with a given deltaTime. Once we hit or are under zero, we increase the frame, wrap around to the beginning if need be, and reset our frameTimeRemaining with our given frameInterval. Render finds our location and clip rectangles and then blits the surface to the screen. But wait, we haven’t added GetBounds or GetFrameBounds() yet. I’m sure those will be useful to have! Let’s get to that!

Add these method definitions in:

Entity.h

And now we’ll implement them:

Entity.cpp

GetBounds() takes our position and shifts it over by our origin. This places the position at the center of the sprite, rather than the top left. GetFramesBound() checks what frame we’re on and finds the matching coordinates. Very important for animation!

Now lets slap a couple of these suckers into our demo!

Game.h

Make sure you include Entity.h so we can actually use the class and we’ll add two Entity pointers to our Game class.

Game.cpp

Image: Ship
Image: Asteroid
(Special thanks to 3DBuzz for these images.)

We’ll now dynamically allocate memory for our two new Entity objects. I have my images sitting in an “images” folder, but you may do whatever you want! I then position the asteroid at the center of the screen. And because we’re mindful programmers, we’ll delete the allocated memory once we’re all done.

Game.cpp

In OnThink, we’ll mouse movement to our ship by looking for an SDL_MOUSEMOTION event while polling for events. In OnUpdate, we’ll simply call each Entity’s Update method with the deltaTime we found. Lastly, in OnRender, we’ll just call the Render method by passing our screen.

Compile, run, and give it a whirl! Weeee! We now have two animated sprites, one centered in the screen and one controlled by our mouse. But where’s the collision? Oh yeah, we haven’t implemented it yet!

We’ll need a bit more functionally in our Entity class, so let’s work on that. This one’s a doozy, so hold on tight! But don’t worry, we’ll take it one step at a time…

Entity.h

Entity.cpp

Given the SDL_Rect of a collision rectangle, we want to find what pixels on the sprite sheet correlate to it. A little messy, but it gets the job done.

Entity.cpp

Given the two bounds of two entities, we want to find how much they intersect, if at all. If they do, we’re given their intersection rectangle, if not, we’re given an empty rectangle. For Max and Min, you can either include “cmath” or use a couple macros such as this:

Entity.cpp

This is where bulk of our per pixel collision check happens. First, we ensure there’s even a bounding box collision. No use going through all the trouble when we know nothing will happen. Then we normalize the bounds of each entity with the found collision rectangle. This will give us the region of pixels we’ll be comparing against each other. You’ll notice this GetAlphaXY() function. This is where we’ll get down into the pixels and determine if they’re solid enough for collision. You’ll see that it’s called twice in one if-statement. This is because we’re searching for a solid enough pixel in each surface at the same position. Once that is found, we’ll confirm a hit!

Entity.cpp

Oh my, some crazy looking stuff here! It’s not that bad. Let me explain a few things here.

We’re passing in a pointer to an Entity and an (x,y) coordinate. All we’re doing in this function is finding the pixel at that coordinate and determining what colors its composed of. The first two lines give us a pointer to the pixel in question. The funky looking switch-statement is finding the color composition depending on the image’s bytes-per-pixel format, either 8-bit, 16-bit, 24-bit, or 32-bit. In our case, it will always land on case(4), but this should give you an idea on how to expand to other formats.

Finally, we’re grabbing the RGBA components of the pixel using SDL_GetRGBA. All we care about is alpha, but you can experiment with collision where hits will only happen when a pixel is red or blue enough. Alpha will range between 0 and 255. I wanted collision to happen with not just pixels that were completely opaque, but not too transparent. I found 200 to be a nice number, but you’re free to tweak as you please.

Well that’s it! Our Entity class has the functionally to test for per pixel collision… so lets show it off!

Game.cpp

Adding this checks for collision between our ship and asteroid. When bounding box collision happens, a green box will be drawn behind them. When per pixel collision happens, the box will turn red!

Well, that’s about it. Run, compile, and enjoy! You now have per pixel collision checks between your two Entity objects! Feel free to tweak numbers, use different images, or control them in different ways! I’ve given you the foundation, now go out there and create some interesting implementations!

Here’s the final code in case you may have some errors and need to check against my own.

Game.h

Game.cpp

Entity.h

Entity.cpp

I hope you enjoyed my first tutorial for SDLTutorials.com and learned a lot! I plan to do more in the future!

SDL Per Pixel Collision – Tutorial Files:
Win32: RAR

In this tutorial, I will show you a simple c++ library to add network resources to your game.

Firstly, we have to add the SDL_net headers and libraries to your desktop environment. If you are using a linux distro like Ubuntu, it is enough to download the libsdl-netx.x-dev package from the repositories. If not, the process is analogous of including sdl mixer, image, etc, better explained by Tim’s Tutorials.
Don’t forget, as well, to set the linker options in your IDE, adding the SDL_net library.

So, let’s create our two files, CNet.h and CNet.cpp, that will build our framework that we’ll help us at making network games. It’s necessary to say that this library, for the time being, only works with TCP/IP protocol.

Here is our header file, and, after the includes and the charbuf declaration, our first class. Its aim is initialize and end the network environment, with two static functions. However, they are unnecessary, if we’re using SDL_Init(SDL_INIT_EVERYTHING).

The class above provides the needed interface for the application to deal with the packets sent through the network. It’s limited to a maximum of 256 bytes.

Regardless this class uses a buffer with a fixed length, the packets sent through the network can be much more smaller, according to the program’s needs. In our TIC TAC TOE game, only one byte is sent. To work with this customization, we put some message states, to help the framework user to build a derived class.

The LoadBytes and UnloadBytes member functions load and unload in a buffer the wanted chars. They were determined by the virtual functions NumToLoad and NumToUnload, each of which indicates how many bytes have to be loaded or unloaded. By default, this class is able to work with strings that have a maximum of 255 characters. If you want to work with other data structures, as we’ll do at the game making, you may override this member function.

Last, the finish() member function, which sets the class ready to be used. So, we can send through the socket, in the same packet, a message with two different data structures, avoiding unnecessary network pollution. Below, the implementation code of this and the latter classes:

Now, back to the header file. Let’s take a look at the CIpAddress class:

Basically, that is a C++ interface for the SDL NET structure IPaddress. It has informations about the host IP address, and the port which the program is associated to. Here is the definition of the class members, at CNet.cpp:

Again, back to header, let’s analyze CTcpSocket, a framework to the SDL NET TCP socket structure. In a few words, a socket is a connection, a “pipe” between two computers, that delivers messages to them, in and out. In a TCP socket, there are necessarily two fixed computers in each pipe’s end, and messages always are got in the right order that they have sent.

In the code above, the member function Ready() plays an important role: it checks whether there is or not activity in the socket, freeing the program’s flow to do what they have to do, without waiting messages from the other side of the pipe.
Below, the code in CNet.cpp:

From this class, we will derive CHostSocket, according to the piece of code of CNet.h:

A host socket is a socket whose utility is listen to a certain port, to check whether there is someone wanting to connect to the service provided by the program, in the machine it runs. If found, we have to use the member Accept to associate another socket to the client. Here is the implementation:

So, a tcp socket client is a socket whose aim is to communicate with a remote host, who, in turn, is using a tcp client to send and receive messages too. Below, the header file for this class:

The same way CHostSocket is, this class is derived from CTcpSocket, and uses the constructor or Connect() to make a connection to the host. If so, the object uses the Send() and Receive() member functions to throw and get messages through the network. Below, the implementation:

So that, we have finished the first part of our tutorial. Next, we’ll change the TIC TAC TOE source code to add playability over a network.

SDL Net Tutorial Files:
sdl-net-clientfiles.tar
sdl-net-commonfiles.tar
sdl-net-serverfiles.tar

So lets get started. Open up your project from the last tutorial. We’re first going to make a few prelimary changes. Make a new file called CEntityCol.cpp. Inside that file, put the following:

Now, get rid of that code from CEntity.cpp. I am basically moving the code to its own file so that everything is much neater. The second thing. Open up CEntity.h and change:

To this:

Also, change the void to bool in CEntity.cpp, CPlayer.h, and CPlayer.cpp. Why the change? Well, you’ll see in a minute.

We’re already storing the collision events in a queue, now we need to do something with them. Open up CApp_OnLoop.cpp. You’ll notice we already have a loop going for entities and we’re calling OnLoop. We’re basically going to do the same thing again, but after our first loop:

Not much going on here. We’re first iterating through every event in the queue. We then grab the two entities involved (EntityA, and EntityB), and we make sure they are valid pointers. If so, we first tell EntityA that it has collided with EntityB by calling OnCollision. Now, this is where that void to bool change comes in. EntityA can choose to prevent EntityB from knowing it has collided with him. If you remember, only Entities that are moving check for collision. This would mean EntityA is definitly a moving entity, and EntityB may or may not be moving.

Here’s an example to explain why you wouldn’t want to waste time calling EntityB’s OnCollision. Say you fire a bullet, and it hits a rock entity. Now, lets say the rock has a flag stating it’s indestructable. Our rock doesn’t care its been hit. So, when the OnCollision is called for the bullet, the bullet can see the entity it has hit is indestructable. And because of that, it can create a little “bullet being destroyed” animation, and then we can ignore telling the rock about it.

This is about the extent of entity collisions. So, now that we have this base, lets do something semi-useful with it.

Open up CEntity.h and add this new function, and variable:

Then, open up CEntity.cpp, and add the Jump function. Also make CanJump = false in the constructor:

Finally, go to the OnMove function. We’re going to figure out when our entity is allowed to jump. An entity is allowed to jump whenever it is touching the ground – or, in other words, whenever the entity is no longer moving on the positive Y-axis. So, at the top, we are first always going to reset CanJump to false:

Now, go down a bit, and modify the PosValid for the Y-axis to the following:

Now, to run through everything we did. First, we have a flag that states if an entity can jump. When set to true, we are allowed to call the Jump function. This CanJump variable is always false, unless our feet are on the ground. Whenever we actually do want to jump, we simply set our SpeedY in the negative Y-axis direction (up). Remember, gravity is always pushing us down, but at a slow speed. So, if we have a SpeedY of -5, and a AccelY of 0.75, we’ll move up for a time, gravity will kick in, and then we will eventually be pushed back down. Thus, giving the effect of a real jump. The trick here is to get the Speed and Acceleration variables just right.

Also, as a side note, the reason we made Jump return true/false is simply for informational purposes. Meaning, when a key is pressed by the player to jump, they won’t always be allowed to jump. And, if you wanted, you could do something based upon what Jump() returns.

So a few more tweaks before we try this out. In the constructor of CEntity, change the MaxSpeedX and MaxSpeedY to 10. Then, open up CApp_OnEvent.cpp and add the following to OnKeyDown:

And one last thing. Open up CPlayer.cpp, and change the OnCollision function to this:

That’s it! Compile, run, and have fun with Yoshi jumping all over the place. You’ll notice the simple collision event we added is that when Yoshi 1 collides with Yoshi 2, it causes Yoshi 1 to jump. Kind of lame, but you should get the idea.

SDL Collision Events – Tutorial Files:
Win32: Zip, Rar

The first order of business we’ll tackle is movement. A seemingly simple idea that can be a bit tricky. Now, I am going to introduce a method that has worked for me for quiet some time, though I am not sure if it can be readily optimized, changed, or whatever. So save the criticism. The reason I like it so much is that it’s pixel perfect now matter what system you are on, and it’s already fast for its purpose.

But before we get into that, we’re going to need a standard for movement. You see, when we play our games on old Pentium 2 as opposed to a quad core, there are apparent differences in speed. So, if we did a simple X++; on the older machine, the entity would move slower than the newer machine. So the idea is simple, figure out the frame rate of the machine, and base our movements off of the frame rate. I call that the speed factor. Now, in order for this to work, we have to have a base frame rate. I usually pick 32, as that is a good number. So if our machine had a frame rate of 32, our speed factor would be 1. If our frame rate was 64, our speed factor would be 0.5. We move twice as slower on the faster machine, that way speeds are consistent across different machines.

So, lets create this class. Create two new files called CFPS.h and CFPS.cpp. Open up the header file first:

First, we have a single control for accessing our speed facor, and frame rate. Again, a singleton object that we should be used to using by now. Next, we have OldTime, which is used to calculate the Frames per second. Then we have LastTime, which is used to calculate the speed factor. SpeedFactor is the current speed factor of the game (of course), NumFrames is the games current FPS, and Frames is the frame count when calculating the frames per second (explanation for all these below). Notice that all of them are private members, so to access our FPS and SpeedFactor we have two get functions. We don’t need anyone messing with those variables directly. Then, we have a simple constructor, and an OnLoop function to calculate everything.

Now, open up CFPS.cpp to add the actual code:

I thought I’d drop a note in here, since I have had some people miss this; whenever you make a variable of a class static, you also need to declare it elsewhere. Notice I have CFPS::FPSControl at the top. If you fail to do this, you’ll get an undeclared error.

Okay, we have a basic constructor, setting everything to 0. Next, we have our OnLoop function where all the magic happens. The first calculation we do, is finding the Frames per Second of the game. This is where SDL_GetTicks comes in. SDL_GetTicks returns the number of milliseconds that have passed since we have called SDL_Init. So, effectively, 1000 milliseconds equals 1 second. Now, notice the condition I am checking. I am checking if the OldTime (which is currently set to 0) + 1000, is less than the current tick count. Think about it, if OldTime is 0 + 1000, and 1001 milliseconds have passed, that means at least 1 second has passed. Why is that important? That tells use to restart the FPS counter.

Notice inside the if statement we then set OldTime to SDL_GetTicks, set NumFrames to the Frames count, and reset our Frames counter. So, going with the example above, OldTime now becomes 1001. Now, 1001 + 1000, is the next calculation, so another second must pass. Concurrent with this, is the Frames++ at the bottom of that function. This continuelly counts up, until the OldTime resets it. I hope that is easy to understand.

Next, we have the actual calculation for the SpeedFactor. Like I mentioned earlier, the SpeedFactor determines how fast to move objects. Now, for a better explanation. Say we are on a really slow computer that gets 1 FPS per second. That’s a really bad computer by the way. We have the base movement rate set at 32 (our made up number). So, ideally, any computer will move objects 32 pixels per second. So this 1 FPS computer will move the object 32 pixels every second. Now, jump to a 10 FPS computer. We still want to move 32 pixels per second. So, that’s 1/10 of 32 right? So, for each calculation we move 3.2 pixels, and after 1 second, we’ll have moved 32 pixels.

To calculate this, we base it on how fast the computer is currently going. This is what LastTime is for. LastTime holds the time it took for the last loop in the game. So, in the constructor it’s currently 0. Now, say we have an FPS of 10. That means we have 10 loops in the game every second. How many milliseconds is that? That’s 100 milliseconds. So, 100 / 1000 (for 1 second), is 1/10. The same number we got above. Now multiply this by our desired movement rate, and we have our Speed Factor! I’ll be showing you how to use this later on, just try to understand how we calculated it.

And lastly, we have our two get functions that return NumFrames (FPS), and the SpeedFactor.

Okay, so much already and we still have a long way to go!

From the last tutorial we loaded an area, 1.area, we’ll be leaving this, as well as everything else from that code. But, we’re going to take one thing out right now. Open up CApp_OnEvent.cpp and remove the following:

We aren’t going to be controlling the camera anymore, but we’ll be controlling our main Player who will dictate where the camera goes. Note: In the last tutorial I had some values backwards for the camera! Please read the notes in the last tutorial for the fix. This new tutorial will have the fixes already in place, but without any explanation.

Now, lets go ahead and add this new Player to the game. But first, some explanation. Remember, anything that moves in the game or that can be interacted with (besides the Map), is an Entity. So, our main Player will be an entity. But, Player is distinct, he likes certain things other Entities do not. So, instead of simply doing CEntity Player; we need to create a class just for Player. But! Before we can even to get to making the Player class, we’re going to need to extend the Entity class. Things like this include the ability to Move an Entity, Collision (what we’ve all been waiting for), Animation states, and Entity Flags. Jumping and a few other things will have to wait until the next lesson (sorry).

So open up CEntity.h and change it to the following:

Oh geez, what happened, and where did all this code come from?! Sorry, for all of you who just fainted, maybe you’ll understand a little bit more now why this tutorial is so long and took so long. It’s a lot to handle, let alone trying to teach to everyone. One step at a time.

First, we have the basic things still there, OnLoad, OnLoop, OnRender, and OnCleanup. The two new virtual functions are OnAnimate and OnCollision. Now, OnAnimate is used to define Animation States, like I mentioned earlier. This is useful for selecting the right animation when the Player moves left or right. The second, OnCollision, is called when an Entity collides with another Entity.

So, for example, if EntityA and EntityB collide, what happens? Well, first, neither can pass through each other; that’s the easy part. The other part, is that EntityA needs to know EntityB collided with him. Such as, Mario falling on a spike. The spike notifies Mario, “Hey, I killed you! Change your animation and die.” Well, the thing is, we cannot notify the other entity when the collision happens. One important reason is that, if the Spike kills Mario, Mario may not have been able to notify the Goomba that he killed him. So, what we do instead is store everything in a queue. This is the new vector called CEntityColList. This stores any collision that have happened when all the entities have moved. And once all movement has taken place, that is when we’ll notify all the Entities of collisions, and call OnCollision.

Whew. Also, in correlation with this, is Collides function, which is used to determine the actual collision (more on this later). Also with this, is four Col_ variables. These variables are used to offset a collision for an entity. Back in previous tutorials we had a Yoshi image we were using. If you notice, it would make little sense to use the width of the image for collision purposes. Yoshi doesn’t actually come to the edges of the images; so, we have to offset it a little, so when Yoshi runs into a wall it actually looks like his nose is hitting the wall, and not being a few pixels away. And since these variables are used to collision purposes only, I have prefixed them with Col_.

Now, for some movement explanation. Whenever an Entity wants to move, we do not move it to where it wants to go immediately. What we do instead, is move it in the direction we want it to go at a certain speed. Remember the whole CFPS class? That’s why time based movement is so important. So, in the new OnMove function, we pass it how fast we want our Entity to go. If we want the Entity to move 1 pixel a second to the right, we would do OnMove(1, 0). Now, I wish it was this simple, but it’s not. In real life we don’t move in steps. We move according to speed and acceleration. Meaning, it takes us a little time to start moving at first (inertia). It looks unnatural to have entities jumping around.

So, to get past this, we have six variables SpeedX, SpeedY, AccelX, AccelY, MaxSpeedX, and MaxSpeedY. Using these is simple. First, the MaxSpeed variables cap how fast the entity can go; if we didn’t cap it, the Entities would continue to go faster and faster into infinity. The SpeedX and SpeedY are the current speed of the entity. If these were 1, again, that would be 1 pixel per second. Now, the AccelX and AccelY, determine how fast we increase or decrease our speed. If AccelX and AccelY are 0, then we aren’t moving at all. If AccelX is 1, then our SpeedX is increasing over time. Now, this is where it gets a little confusing with the Speed factor.

I want my player to increase in speed 1 pixel per second. This would be:

Notice we multiply the AccelX by the Speed Factor. That’s because we want to increase the speed 1 pixel every second. If I wanted to increase the speed 1 pixel every loop, I would leave the speed factor out of it. Now, when OnMove receives these Speed variables, it also has to figure in the speed factor:

(MoveX and MoveY are the arguments passed to OnMove). Now, the SpeedX and SpeedY only determine how fast we want to move per second. So we have to multiply it by the speed factor. A little hint for you people out there, the entire speed of the game is determined by the Speed Factor! If we changed the Speed Factor of the game, it would determine how fast anything in the games moves. Slow motion deaths anyone?

Now, whenever an Entity moves, there are some things to consider. Say in one loop we are supposed to move the Entity 4 pixels (slow computer perhaps, or really fast entity). Now, lets say 2 pixels away there is a wall. Now, if we checked 4 pixels in front of use, we wouldn’t let our guy move. But, we still want him to move as close as he can. So, to move this 2 pixel distance, we have to check every pixel along the way. Now, you might be thinking this will be slow. Well, not really. Someone with a 100 FPS who wants to move 5 pixels a second (a reasonable speed), will move less than one pixel every loop (0.05 to be exact). So, every loop, this entity moves 0.05 pixels over. That means we have 1 or 2 checks when checking for collisions for that entity. More explanation on this later when we actually implement moving.

Before an entity is allowed to move, we have to check a few things. The first is if the entity collides with the map, and the second is if the entity collides with another entity. This is where the three PosValid functions come in. The first, PosValid(), is the main function that handles the other two. It checks to see if the tile the entity is trying to move to is valid, and also checks the entities. The other two PosValid functions determine what a valid tile is, and what a valid entity is. Again, more explanation later.

Now, last for movement, we have MoveLeft, MoveRight, Flags, and StopMove. Now, MoveLeft and MoveRight are simply flags, true or false, that determine if the entity is moving left or right. If true, the AccelX will be set a value, causing the entity to move. Now, StopMove simply sets the AccelX in the opposite direction until we reach 0. Again, we don’t stop suddenly in real life, we gradually stop. The last item, Flags, is used to determine a few things. In the second enum, you’ll notice several flags.

These are used to determine certain properties about an entity. For example, an entity that is affected by gravity will have the ENTITY_FLAG_GRAVITY turned on. An Entity that can go through walls, will have ENTITY_FLAG_GHOST turned on. An entity that only collides with the map, and not other entities, will have ENTITY_FLAG_MAPONLY turned on. Now, notice how we have them numbered in hex. This is because we’re treating the Flags in binary. This way, we can activate multiple flags at once:

Wow, what a load, but still more in the class to explain. Next, we have some Animation variables. There are only two of them: CurrentFrameCol, and CurrentFrameRow. These two determine where on our image we start to find individual frames of an animation. A CurrentFrameCol and CurrentFrameRow would be the top left of the image. Moving over one column would change things. Think of it like tilesets. Look at the example image below:

(Save this Image for this Tutorial)

Last, but not least, we have variables to indicate if a variable is dead, and the type of entity. You’ll notice we have another enum, like the Flags, to specify the type of entity. This is important when dealing with collision events. So, back to the Mario and Spike example; lets say a Goomba happens to step in a spike. Now, in Mario world, the Goomba would not die. So, the Spike needs to know that entities type. Simple enough I think.

Okay, lets get into the core of the class now. Open up CEntity.cpp and lets have some more fun. Since we have had so many drastic changes, I am going to go through this line by line with the basics, and then move on to specific areas of the class. So, starting at the top we have our basic constructor, and statics:

Everything is simply set to 0, NULL, or some respective value. One thing to notice is the MaxSpeed variables. Set these to whatever you like. Usually this will depend on the particular entity that is in the game. Such as Mario will be able to move faster than a Goomba. Notice that I have grouped two classes into one file; that is okay to do sometimes! OnLoad is the exact same, so skip over that, and then move on to OnLoop:

Lots of new things here. First, remember MoveLeft and MoveRight are used to indicate if the entity is moving left or right (duh). If both are these are false, we call StopMove, which will handle settings Acceleration in the reverse direction so we come to a gradual stop. Below that, if MoveLeft or MoveRight are true, we give AccelX a value. 0.5 is an arbitrary number, you probably want to mess with this until you find a value that you like. Just below that, we have a condition checking if gravity is turned on for that particular entity. If it is, we set AccelY. This will cause our entity to fall down. Again, this is whatever value you want. The larger the number, the faster you will fall. Next, below that we have our SpeedX and SpeedY. Again, we increase the Speed of the entity over time in correlation to our Speed Factor. Then, below that, we check against our MaxSpeed variables to make sure we only go a certain speed. Finally, we call OnAnimate for our entity to animate, and then OnMove, which will actually move our entity.

Moving on, we have a few changes to OnRender:

First, we have added the Camera X and Y to the rendering coordinates for the entity. This makes the entities render in connection to where the camera is. This way, if the camera moves, all the entities will in respect to the camera position. Next, we have added CurrentFrameCol and CurrentFrameRow to the X2 and Y2 of OnDraw. This makes it so we can set different animations.

The first column has Yoshi facing the left, while the second column has Yoshi facing to the right. When we move to the left, we will want to set CurrentFrameCol = 0, so that Yoshi appears to be walking left. And when we move to the right, we will set CurrentFrameCol = 1, so that Yoshi appears to be walking to the right.

Skip over OnCleanup, nothing new there. We then have OnAnimate:

This is fairly straight forward. Like I said above, depending on which direction we are moving, we set the animation. Next, we have OnCollision:

Yay, an empty function. This function will be called whenever two entities hit each other. This entire time we’ve been creating an class for basic entities. In order to take advantage of this function, you will need to create our own class (like CPlayer, which we’ll do later on in this tutorial) and override this function. This is because the action taken by an entity depends upon it’s type. Like my earlier examples, a Goomba will not react the same way to a collision with a spike as Mario would.

Next, we our OnMove function.

This function is quite a bit to take in. Lets see if we can straighten it all out. First, MoveX and MoveY are the where we want to move our entity. Remember up above, we call this passing our SpeedX and SpeedY. So, calling OnMove(1, 0) we would want to move 1 pixel to the right every second. At the top, we check our Speed, and if 0, we don’t do anything (duh). Below that, we do something I explained earlier. We multiply MoveX and MoveY by the speed factor. This gives us the correct movement per second. Just below that, we figure out the values for two new variables, NewX and NewY. These will be our X and Y increments. Remember, I mentioned above that this method is pixel perfect, so we need to inch closer and closer to our desired position. Now, we set our NewX and NewY to our speed factor because this is how much we should use to inch closer and closer to our desired position.

Below that, we have a seemingly infinite loop. This is where the movement magic happens and collision. First, we have a condition to check if the entity is a ghost, if it is, we increase the X and Y regardless if a collision has happened. We still call PosValid though, because this will notify entities of any collision that have taken place. Notice in PosValid we pass the current X and Y, along with adding NewX and NewY. This is where we want to go, so we check if that spot is empty.

If the entity is not a ghost, we do normal collision. We check X and Y separatly because we may be able to move up but not forward (think jumping into a wall). If the position is valid (empty), we increase the X or Y, if not, we set SpeedX or SpeedY to 0 which causes you to immediately stop (this is as close to reality as we need, if you do run into a wall you usually stop immediately). Now, below that, we change MoveX and MoveY depending upon our NewX. Say our MoveX was 2, and our NewX was 0.5. We would slowly decrease MoveX until it reaches 0. Once it does, we have come to our desired position and we are done. The 8 if statements below check if MoveX and MoveY have reached 0, and break out of the loop.

Moving on, we have StopMove:

This one is fairly straight forward. Depending on our Speed, we set the Acceleration in the reverse direction. So, if we are moving right, we set the acceleration to the left. The last if statement is simply a boundary to how slow we need to be going until we stop. If we didn’t do that, it’s possible that we could be stuck in a loop of moving left to right.

Next, we have a function that determines collision of two boxes. I will say right now that this function was borrowed from Cone3D (), and then modified. If it works, why fix it?

Anyway, lets take a look at it to see if I can help explain. At the top we define 8 variables, to define 8 sides. 4 sides are for the first object, and 4 sides are for the second object. Basically, we are doing bounding box collision:

So, in a very basic sense, we want to check if two boxes have overlapped. The easiest method, is to determine if we have not collided on all 4 sides. So first, we determine the locations of all the sides:

Look at the figure below to get an idea:

The top and left, are the X,Y of the object, and the right and bottom, are the X+Width-1, Y+Height-1. We subtract one in order to get the true coordinate of the side.

Next, we finally do the checking. What we do here is to check if one of the 4 sides of the first object are out of range of the second object. If one is, then we cannot possibly be colliding. But, if all 4 checks fail, we are colliding. So, if bottom1 is less than top2, that means the Bottom side of the first object is higher up on the screen then the Top of the second object:

Finally, if all checks pass, then we return true for a collision. One note, remember that the Col_ variables are used to simply offset the size of the entity. If the entity is 32 width, but we offset by 2, that means when we check collision we use the Width of 30.

Moving on we find some more fun. We have our 3 last functions, the 3 PosValid functions. Overall, this functions basically determine if a collision has taken place. Remember, earlier OnMove will call PosValid to determine if a requested position is open to move to. So, keep in mind that NewX, and NewY in these functions is where the Entity wants to move to, not where it currently is.

Lets first look at PosValid. This function will determine any type of collision that has taken place, and return true or false. Now, this function basically has only two type of collision, Entity to Entity, and Map to Entity. That’s what PosValidTile and PosValidEntity are used for.

Now, the first collision we check for is a Map Collision. This is done by first grabbing 4 variables about our Entity. Basically, we want to know all the TileIDs that this entity is over. This is done by grabbing the X (and the Col_ offset) and dividing by the TILE_SIZE. This gives us our TileID for our X. The same goes for the Y variable. These two calculations determine our StartX and StartY. Now, EndX and EndY are determined in a similiar fashion, but we want to also add the Width and Height (just like we determined sides in the Collision function above). This will give us an area of tiles that this entity is over:

Now that we have the Start and End of tiles, we simply loop through them:

Inside of this loop, this is where we check each tile to see if it’s a valid tile to move into. It the tile happens to be a wall, we would set the Return variable to false, to indicate that this requested position (hence the name PosValid) is not good:

Notice the new function GetTile, we’ll define this later on in this tutorial. But to explain it here, GetTile will return the CTile of any X and Y coordinate. After we get the tile, we pass it on to PosValidTile for it to figure out if the tile can be moved over or not. So, for a moment, jump on over to PosValidTile:

Remember the enum in CTile.h at the top? Those enums were a list of types that you could give a tile. They are used here now, to determine if a tile can be moved on or not. So, that’s basically what we do here. First, if the Tile is NULL (which you should always check your pointers), we return true (meaning, yes, they can walk on this tile). Next, we check if the tile is a TILE_TYPE_BLOCK, if so, then no, the entity cannot walk on this tile. And finally, for all other types, yes, they can walk on this tile. Simple enough.

Now, jump back to the PosValid function. You will then find another loop:

First, we do a simple check with our Flags again, this will check if we have the ENTITY_FLAG_MAPONLY flag turned on. If so, this means we’re only checking collisions against the map, so we don’t worry about Entity collisions. If we are checking collisions, then we jump to the loop. The loop is fairly simply, we go through the EntityList and pass each entity to the PosValidEntity, along with NewX and NewY. So, Jump on over to PosValidEntity:

Okay, this function is actually quite simple. We do some checks first on the Entity (the Entity we are wanting to collide with) to determine that this Entity is not the same Entity we’re moving (Mario cannot collide with Mario). That’s the “this != Entity.” It simply checks to make sure the Entities are not the same. We then check to make sure the Entity is not NULL, not Dead, and doesn’t have the ENTITY_FLAG_MAPONLY flag turned on. So far, so good. If all these checks pass, then we finally pass it to the Collides function of that Entity, passing along our Entities coordinates and Width/Height (with Col_ offsets). Remember, if any part of an if statement fails, like this != Entity, none of the other code in the if statement will be executed.

So, if the Entities do collide, finally, we use our new CEntityCol class. This will be a queue of collisions that have taken place. So, we push our Entity into EntityA, and the other Entity into EntityB, and then push it into the list. Finally, we return false, to indicate that this position is not valid. Wow, we are almost done!

Don’t rush out to compile, it won’t work. Why? Because, remember that GetTile function?

So, let’s add this into our code. Open CArea.h and add two functions at the bottom of the class:

Then, open CArea.cpp and add the functions:

I know, I know… they are more complicated than they look. First, look at GetMap. GetMap simply returns a CMap pointer at the given coordinates. It’s just like GetTile, but for Maps. Now, how it works is first by determining the size of our maps. We then translate our X,Y into an ID, and then return the CMap pointer. I won’t go into how translating X,Y into an ID works, because I believe this is explained in the last tutorial.

Now, go to GetTile. We determine the MapWidth and MapHeight, again (and I suppose this can be optimized), and then grab the Map with GetMap. We do a simple check for a NULL pointer (hint, hint), and then turn our X and Y into Tile coordinates. So, if our TILE_SIZE was 16, and our X was at 128, our Tile coordinate for X would be 8. Meaning, we are 8 tiles over. We finally then send this over to the Map GetTile. (Oh yes, one other function). This is why we have a GetMap function, if you are wondering. Rememember, CArea is a bunch of maps making one big area. So, we will have to determine which map is needed when grabbing tiles.

So, jump over to CMap.h now, and add this at the bottom:

Then, open CMap.cpp and add this at the bottom:

This is basically just like GetMap, but uses the TileList instead.

We’re almost done!

Just a few more changes to go. Create two new files called CPlayer.h and CPlayer.cpp. This class will be our main player and will extend our new CEntity class. So, open up CPlayer.h:

I won’t explain any of this other than it’s overriding all the virtual functions from CEntity.

Now, open up CPlayer.cpp:

Again, just like CEntity, but simply overriding the functions. One minor note, look at OnAnimate. In there we check our SpeedX to make a modification to our MaxFrames. Basically, if SpeedX != 0, (which means we are moving) we set our MaxFrames to 8. If we aren’t moving we set it to 0. Now, remember our Yoshi animation above, it has 8 frames for walking. So, if our Speed is not 0, we make Yoshi walk, otherwise we make it look like he’s standing still. This is the area where you would define other animations, like Idle, Walking, Running, Jumping, and so on.

Now, open up CApp.h and add the header file at the top:

Then, add two Players in your class:

Then, open up CApp_OnInit.cpp and initialize them:

Simple enough. We set PlayerX, the other Yoshi, over, so that we’re not on top of each other initially. Now, just below this add this extra code:

Remember I said earlier, we’re going to make the camera follow our Yoshi. Now, open up CApp_OnRender and change this:

To this:

This change is also related to the Camera bug I mentioned above earlier. Open up CCamera.h and change the TargetX and TargetY from ints to floats. Also change the SetTarget ints to floats.

One last change now! Open up CApp.h and add this to your code (you should already have OnKeyDown):

Then, open up CApp_OnEvent.cpp:

To go over this quickly, we basically check if Left or Right is pressed, and set MoveLeft or MoveRight on our Entity to true. If the key is depressed, we set it to false.

Now, we’re done! Remember to grab the Yoshi picture above to make sure he shows up right. Also, I changed the 1.map to have TILE_TYPE_BLOCKs in it. You can grab an updated one here: Example Map. Since this tutorial is so lengthy, and took me a long time (sorry), please be sure to let me know of any bugs or something I forgot to address. Thanks.

P.S.
In the next tutorial, we’ll see how to react to collisions that happen. In this tutorial, though we pushed collisions into a queue, we didn’t do anything with the queue yet.

SDL Collision – Tutorial Files:
Win32: Zip, Rar
Linux (CodeBlocks): Tar (Thanks Jason!)
Linux (Makefile): Zip (Thanks Sergey!)

Today we’re going to learn something about extending the capabilities of SDL_Surfaces. If we take a look at OpenGL, what happens when we load a Surface and we render it specifying a width and height bigger than the Surface’s original width and height? It gets automatically scaled (unless you specify you want to be repeated). In SDL there is no automatic way of scaling surfaces, so we’re going to make a (relatively simple) routine that does the trick.

First, the prototype of the function:

What are these parameters? Well:
Surface: The original surface the caller of the function wants to be scaled.
Width: The width the caller wants the scaled surface to be (we use Uint16 because this is SDL’s standard for width).
Height: The height the caller wants the scaled surface to be (we use Uint16 because this is SDL’s standard for height).

Got that? If you didn’t, try reading it over again; if you did, then let’s move on.

First, we have to check if the Surface’s width and height are valid; this is simple to accomplish:

We don’t want a null pointer specified, since it will make BAD things happen when we try to read data from the surface. Secondly, a surface with 0 width or 0 height wouldn’t be a good idea, so let’s just return a null pointer when either of these things happen.

Now we need to create a surface that suits our needs; we’ll do this using the SDL_CreateRGBSurface function:

Here we’re declaring and defining the return surface. We want its specifications to be the same as the surface we got from the caller, so we do so, and then the width and the height should be the same as the ones the caller specified. Looks pretty simple to me .

Now comes the math part. We need to calculate the scaling (or stretching) factor to be applied when we copy the surface’s pixels. It’s not as hard as it seems, we just divide the width the caller wants by the width of the surface, what have we calculated then? If you calculate the scaling factor for the widths, you’ll get the number of pixels you need for each individual source pixel, in other words, each pixel you read from the source surface has to be drawn SCALING_FACTOR_X times over the width in order to stretch it (the same goes for the height).

Calculations:

Casting might be bad to some of you, but it’s necessary here since we need the scaling factors as a double. This probably could have been done better, like checking for w = 0 and h = 0, but this is just a simple tutorial . We’re just doing here what I explained before.

Now we need to do the actual drawing. This might look overwhelming, but it’s not as hard as it seems. We’re just going to make 2 for-loops to run across all the pixels on the source surface, and then 2 more loops for drawing STRETCHING_FACTOR pixels for each pixel that gets read from the source surface.

Here we go!

I’m not going to specify the DrawPixel and ReadPixel functions here, as they can be gotten from the SDL documentation wiki (http://www.libsdl.org/cgi/docwiki.cgi/Pixel_Access), though my prototype might be a little different, they work like this:

The principle is pretty easy:

The DrawPixel call might look weird to you, but actually what happens inside is this: Draw a pixel on(the return value, stretching_factor_x * source_x because the destination moves each time and then blit the amount of pixels we need, same for y, what color do we need? The color that’s on the source surface at the x and y position, because we need to blit it scaling_factor amount of times).

Why the strange X and Y coordinates? Well, imagine we need to make the width twice as bug, look at this crappy drawing:

Source surface:
---------------------------------------------
|x,y       |0,0       |1,0       |2,0       |
---------------------------------------------

Destination:
---------------------------------------------
|x,y       |0,0 & 1,0 |2,0 & 3,0 |4,0 & 5,0 |
---------------------------------------------

See? When at pixel (0,0) we need to draw a pixel at (0,0) and (1,0) because we need 2 pixels on the destination for each 1 pixel on the source (following the X-axis because it’s the width), the same goes for the Y. We’re actually just skipping what we’ve already drawn, _stretch_factor_x * x is actually ‘Move to the corresponding pixel on the destination. It makes the (2,0) on the drawing say that it should begin its drawing at (4,0) on the destination, then it loops o_x untill it’s smaller than 2, drawing first at (4,0) and then when o_x increments at (5,0). It’s THAT easy.

Finally we return the desired surface:

Here an overview of the full function:

I hope you learned something with this tutorial, maybe I’ll write more tutorials in the future (perhaps something on texture repeating? ).

See ya!
Creature

IMPORTANT NOTE: I DON’T NAME SURFACES LIKE TIM DOES. WHEN HE CALLS IT Surf_Display, MINE IS SIMPLY SurfDisplay, WITHOUT THE UNDERSCORE. MAKE SURE YOU KNOW THIS, AND ADAPT TO THE TUTORIAL ACCORDINGLY. ALSO, WHEN I MAKE PROTOTYPES IN CLASS DEFINITIONS, THE ONLY STUFF I WRITE IN THE PARAMETERS AREA (I.E. THE PARENTHESES) IS THE TYPE OF DATA TAKEN, NOT THE NAME OF THE DATA TAKEN. THAT NAME IS ONLY IN THE ACTUAL FUNCTION DEFINITION, AT LEAST FOR ME.

This tutorial is based on everything you’ve learned by now, if you’ve been following the tutorials in order and have just finished the Maps tutorial. Get ready to get a glimpse of creating your first real game! (Not counting that fabulous tic-tac-toe.) Similarly, the code this comes from is from all the code you’ve written up to the Maps tutorial, and including it. It would be wise to make a new Code::Blocks project (or a new DevC++ project, or whatever), because this tutorial will delve a different way for a bit, and you don’t want to mess up your existing code for the upcoming Collision Detection tutorial. Speaking of that, this tutorial will introduce you to very simple collision detection, on a tile-based board.

If you’re all ready, open up your [new] project and let’s begin!

First, we need an introduction to Sokoban. For those of you who have never played this unusually fun and addicting puzzle game, here’s how it goes. There’s a player that you control with the arrow keys, and he pushes boxes on tiles to their ‘home’ locations. Those locations are special tiles on the board. Once all the boxes are at ‘home’, the level ends. The challenge, though, is that the boxes are positioned initially in such a way that makes it a puzzle. A box can’t be pushed into a wall, or out of a corner, etc., so it becomes harder. That’s all there is to it!

Here we go. This tutorial, like the last few, will only instruct you as to where to put the code I write; there will be no full documents, unless they’re new. First and foremost, we need to modify CTile. Add another element to the typedef enum statement at the top.

You’ll see why soon.

Also, we need to make a new function in the CMap class that checks what the TypeID of a given tile is. Add the appropriate prototype in the class definition, and add this function in CMap.cpp:

Simple enough.

Sokoban needs blocks. Let’s make a block! The CBlock class is going to extend CEntity. We’re going to make this new class for the block inherit all the attributes (variables) and methods (functions) of the CEntity class. It also has its own attributes and methods that don’t exist in the CEntity class alone. A good example to illustrate this is geometry. The ‘parent’ class is the Shape class. It has the attributes of area, color, and perimeter. A child is Square, which has those same attributes due to inheritance, but also has side (because it’s a square), and Shape doesn’t have side because it could be a shape with no straight lines. Circle is also a child, because it inherits area, color, and perimeter, but it has a radius attribute for itself; etc.

So open up two new files, CBlock.h and CBlock.cpp.

And…

After the class definition, we have ” : public CEntity.” This is what tells the compiler that this new class extends and inherits the attributes and methods of the CEntity class. This class, much like the CEntity class, has its own vector of CBlocks. Sure, it makes sense to just use the CEntity::EntityList vector in its place, but we’re going to need a vector of just CBlocks (not including the CEntity that will be CPlayer).

Next, CBlock has an attribute that says whether or not it’s located on its ‘home’ tile. The constructor, CBlock(), sets that value to false, and the rest of the values which it inherits from its parent class, CEntity, are set to their default values, as well. The next function, CheckForHome(), sets the OnHomeTile boolean value to true, if the TypeID of the tile under the block is TILE_TYPE_HOMEOFBLOCK. Otherwise, it’s false. There isn’t a return statement because this function just deals with CBlock’s personal variables. The final function, OnMove, is very simple. It takes in two integer variables, MoveX and MoveY, and increments the block’s X and the block’s Y by those amounts, respectively. (Remember, even though the class didn’t set an X or a Y variable, CBlock inherits those two from CEntity, so they’re allowed to be manipulated. And they exist.)

Next, we need to implement a player, in kinda the same way.

CPlayer, a child of CEntity, will inherit every one of its attributes and methods, and we will define our own and maybe even override the inherited methods. Make two new files, CPlayer.cpp and CPlayer.h, and open up CPlayer.h.

Then, open CPlayer.cpp and let’s define the functions.

A little explanation. Just like with CBlock, ” : public CEntity” is to extend the CEntity class.

In the CPlayer class, we’re defining five new functions, OnMove and the four “can he move in a certain direction” functions. OnMove is simple: two integers are passed, and the CPlayer’s X and Y coordinates increment by exactly that much. (Remember, CPlayer has the X and Y attributes, even though they weren’t defined in CPlayer.h, because he INHERITED them from CEntity.) Here’s where it gets a little trickier. Those four other functions are the collision detection functions. They check whether the player can move left, up, right, or down, and return what the result of the check was. So let’s examine CanPlayerMoveLeft() closely.

First, look at the top of CPlayer.h. The typedef enum statement, like others before, makes YES equal to 0, NO equal to 1, and BLOCK equal to 2; this is because it’s much easier to remember YES, NO, and BLOCK, than it is to remember that 0 is the same thing as YES, etc.

The function first checks if the TypeID of the tile to the left of the player is TILE_TYPE_BLOCK. If so, then the function returns NO, meaning the player cannot move left (because a wall is blocking his movement). Then, the function checks if there’s a block there. It does this by looping through every one of the CBlocks in the static BlockList (which are automatically added when the CBlocks are loaded…we’ll get to that a bit later). Every time it loops, it checks the X and Y coordinates of the block, and if a block is to the left of the player, then the function returns BLOCK, which will tell the program that the player has a block to the left of him. There are two caveats, though. First, if there is a block to the left of the player, but there is also a TILE_TYPE_BLOCK (i.e. a wall) to the left of that block, the player cannot move, and the function returns NO. Similarly, second, if there are two blocks to the left of him, the player can’t move (he’s not THAT strong!), and the function returns NO. Otherwise, it returns BLOCK. However, if NONE of those are true, then the function returns a simple YES, because the player has a free spot to his left.

That repeats for each direction. The purpose of this function is so that, when the OnKeyDown() function is called (in CApp), before moving the character we test if he can move. That said, let’s move on to the implementation of these functions.

We need a way to load the blocks. Just like with the maps and areas, we’re going to have a directory next to your exe called blocks, with (so far) one file in it: 1.blocks. Make that file, position it accordingly in the directory tree, and open it. Our first level will have blocks at these coordinates:

(160, 128)
(160, 192)
(224, 160)
(224, 192)
(160, 288)
(64, 288)

Make two more new files called CBlockControl.h and CBlockControl.cpp, and open up the header.

And…

This is a class that will load every one of the blocks and their locations from a text file (namely, blocks/x.blocks, where x is the level number). When the static function is called, it takes in a char array. As we’ve done before with Tim’s tutorials, it reads that file. That file contains a number (in level one’s case, 6), followed by a next-line/return character. That number is stored in the integer BlockCount. Then, the function loops through every one of the blocks in the file (with the for loop), and loads their respective X and Y coordinates. Inside the for loop, a TmpBlock (TeMPoraryBLOCK) is created and its X and Y coordinates (attributes set by CEntity, and inherited by the CBlock class, remember) are set as the values in the X and Y integers in the for loop. Then, the TmpBlock is inserted into CBlockControl’s static vector of CBlocks (CBlockControl::BlockList).

So, it seems that now we have everything needed to actually implement everything we’ve just written; to bring it all together and make a level. Well, first we have to accomodate for one slight change. There is no longer a CCamera. We don’t need one as the map can’t get bigger than the one level. So we have to change something in CArea. Remember the function CArea::OnRender(SDL_Surface* SurfDisplay, int CameraX, int CameraY)? Well since we don’t need a camera anymore, we don’t need that function anymore. But don’t toss it! Who knows, we might later need the function for any additions you decide to make. So let’s make a new function:

Add the prototype to the class definition (make sure it’s public), and write the function in CArea.cpp:

We now have two functions with the same name, but they have different parameters, which is allowed. It does the same thing, except there’s one map to render so there’s no need to figure out which is the first map to render. Duh.

Finally, open up CApp. We’re gonna put this thing together. In CApp.h, add the following things:

Remember, this isn’t the whole thing; this is just what you need to add in the appropriate places. I think you already have the new function, but make sure it’s there, in any case.

So then, in CApp.cpp… In the constructor, CApp::CApp(), add statements that define Moves as 0, and SurfBackground as NULL (like SurfDisplay). In CApp::OnInit(), we need to almost completely rewrite it:

Let’s talk about this. The first two if’s start SDL, like we know already. The third is just something I thought would look nice. I have this cool red graphic that I made, and I put it in gfx, and called it background.png. This statement uses our CSurface function OnLoad and puts it on SurfBackground. Next, an area is loaded. I’ll get to what’s in that area file in a second. The next statement loads the player. Remember, CPlayer inherits everything from CEntity, and since CEntity had an OnLoad function that loaded the entity from an image file, so does CPlayer. And thus, ActionJackon (which we declared in the class definition) has it. NOTE: MY PARAMETERS MAY BE DIFFERENT FROM YOURS, SO CHANGE THEM AS IS NECESSARY. THERE’S NO NEED FOR TRANSPARENCY, AT LEAST NOT YET, SO JUST REMEMBER THAT.

ActionJackson is pushed back in the static EntityList vector, and then CBlockControl loads all the blocks from a file. Remember, it’s static, so we can run it without having declared an object/instance of CBlockControl. Then, like I promised WAAAAAY back, CBlock’s static BlockList vector would get those blocks. And, like we need to do and like we did for ActionJackson, we need to push the blocks back in EntityList, too. Finally, we just need to set initial X and Y coordinates for ActionJackson, and that’s all for OnInit().

Go to OnRender(). Rewrite it as this:

Since we loaded a background to SurfBackground, we have to draw SurfBackground on SurfDisplay. And this MUST be the first render statement because otherwise, the background will be drawn OVER the other things. Also, the new function we created for CArea is called, taking only the filename and no camera coordinates (since we no longer need a camera).

Finally, the meat of the game. Go to CApp::OnKeyDown(SDLKey sym, SDLMod mod, Uint16 unicode). Erase all that stuff involving camera movement, and rewrite the function as this:

WOW. Let’s go through that bunch of code. The same switch statement remains as before, but the inside is different. Let’s take just the case of SDLK_UP. If the UP key is pressed: First, the function checks if the player can move, and that is done by calling the CanPlayerMove…() function and checking its return value. If there is a block (i.e. if CanPlayerMove…() returns BLOCK), then a for loop is run. For every block in CBlock’s static BlockList vector, there’s an if statement that checks if that block is the block that is next to the player. Otherwise, this function could just move any random block up, and that would obviously not be good. So this just figures out which block is next to the player. Once that’s figured out, that block moves up, and the for loop continues. It’s not going to return to the same block again, so it just keeps running until it’s out of options. Then, ActionJackson moves up, sort of “following” the block. And the Move count increments up by one.

If ActionJackson.CanPlayerMove…() doesn’t return BLOCK, none of that happens. The next if statement checks if that function returned YES. In this case, ActionJackson very simply moves up, not disturbing anything else, and the Move count increments up by one. Finally, if CanPlayerMove…() returns NO, nothing happens, so when up is pressed and the player can’t move up, he DOESN’T.

This repeats for every arrow key. There we go! The game works! Now let’s just make a use for CBlock’s boolean attribute, OnHomeTile. Go to CApp::OnLoop(), and rewrite it as this:

After the existing first for loop, a new boolean value is created. By default, BlocksAreHome is set to true, but that changes immediately if it isn’t true. The next for loop runs through every block in CBlock’s BlockList vector. Each of the blocks the loop runs through calls its CheckForHome() function, and accordingly sets its OnHomeTile boolean to true/false. Then, the block in the for loop is checked to be on its home tile with the if statement. If it’s not on its home tile, BlocksAreHome is set to false. Otherwise, the for loop continues, leaving BlocksAreHome true. Finally, after the for loop, if BlocksAreHome is true, Running is set to false, and the game ends. This is just all I’ve written for the end of the level; feel free to add your own end-of-game stuff.

Now the game is perfect. All you need to do is make the area, map, blocks, and graphics files. Thankfully, they’re all packaged below. Also, in Define.h, set TILE_SIZE to 32, MAP_WIDTH to 20, and MAP_HEIGHT to 15.

The directory tree should be as follows (numbered by sublevel):
1. Sokoban (directory)
2. blocks (directory) gfx (directory), maps (directory), tilesets (directory).

In the blocks directory, put the files in the following .zip archive:
MediaFire – blocks.zip

In the gfx directory, put the files in the following .zip archive:
MediaFire – gfx.zip

In the maps directory, put the files in the following .zip archive:
MediaFire – maps.zip

In the tilesets directory, put the files in the following .zip archive:
MediaFire – tilesets.zip

And, should you need to refer to it, here are the full source files (with a few commented-out changes; ignore those):

SDL Sokoban – Tutorial Files:
MediaFire – Sokoban.zip

Linux: Tar (Thanks Gaten)

COPYRIGHT:
Copyright 2008 Arseniy Banayev

DISCLAIMER:
I will not be held responsible for any damages, reversible or irreversible, to your operating system, personal files, applications, or the physical computer itself, brought upon as a result of compiling and executing the given code or opening the provided files in the above packages.

The first thing you need to do is download SDL mixer from the SDL website. It’s also included in the SDL library I provide on my website. Be sure to put the include files in the same directory as your SDL include files, and your lib files in the same directory as your SDL lib files to make things easier.

Start by opening your project, and going under the linker settings. Add SDL_mixer after SDLmain, something like:

mingw32
SDLmain
SDL_mixer
SDL

If you don’t remember where to find all these settings, hope on over to the first tutorial SDL Tutorial Basics to get a refresher on linking. If you have a .lib file, instead of a .a library file, use the browse button to find the library file that way.

Just a little side note here about sounds. SDL_mixer treats any sound in memory as a chunk. This chunk basically contains the frequency data. What’s nice about SDL_mixer is that it takes this data and sends it to the audio output, meaning it has taken care of all the hard work. So all that we have to do is load our data, from a WAV file for instance, and then send it to SDL_mixer to be played.

First, create two new files, CSoundBank.h and CSoundBank.cpp. Open up the header file first:

We have a static control object first, this lets us add sounds and play sounds from anywhere in our program. Think of this as your master control for adding/playing sounds. We then have our SoundList, this is a list of SDL mixer sounds. Now, a Mix_Chunk object contains the information needed to play a sound. What we will do later on is load a wav file into a Mix_Chunk object. Think of it as the sound equivalent to SDL_Surface. Then we have some basic functions for loading, cleanup up, and playing a sound. Simple enough.

Next, open up CSoundBank.cpp:

This is also pretty straight forward. We have our static control, our empty constructor, and then our loading function. We basically take the filename of the sound to be loaded, and try to load it via Mix_LoadWAV into the Mix_Chunk object. Notice I am making a temporary object first, and then throwing it into the list. At the very end of the function, I return the ID of the last inserted sound. So, for instance, say I loaded SoundA and SoundB:

The ID for playing this sounds later would be returned by the OnLoad function.

Okay, next we have our cleanup function which goes through the list and frees the sound chunks. Simple enough, just like SDL_FreeSurface.

Lastly, we have our Play function that actually plays the sound. We pass an ID (the one we got returned from the Load function) first. We do a little boundary check to make sure the ID is valid, and then actually try to play the sound. The Mix_PlayChannel takes three arguments:

The first specifies which channel to play the sound on, -1 means use the first available.
The second specifies which sound chunk to play.
The last specifies how many times to play this sound (loop). -1 would be infinite.

We haven’t done much with channels in this class, but the class is easily changeable to add that functionality. Basically, a channel allows you to set certain settings to certain sounds. For instance, you can set volume or panning on the first channel, so any sounds played on that channel would be affected.

So lets do a little test now. Open up CApp.h and add the header file, and add some variables and functions to the class:

Now, open up CApp_Init.cpp so we can load some sounds:

Now, to make sounds when we press a key, open up CApp_OnEvent.cpp and add the function:

We aren’t done yet, we have to do a little bit to start SDL_mixer. This is just like starting up SDL, but instead we need to start up SDL_mixer to access sounds. Open up CApp_Init.cpp and add the following somewhere after SDL_Init:

Mix_OpenAudio basically Inits SDL_mixer. This function takes 4 arguments. The first is used to specify the frequency, 44100 is usually a good number. But depending on your wav files, you may have to change this. Another common number is 22050. I won’t get into detail about frequencies and such, just leave it alone unless you really need to change it. The next is the format, again, it’s best to leave it unless you know much about audio (it’s basically the size of the samples used, 8bit or 16bit). The next is the number of channels, 1 = mono, 2 = stereo. Note, these channels are different than the other channels I was talking about before. The other channels are “mixing channels,” basically streams that I can push audio through. These channels though, are the number of audio outputs. Think of it like the number of speakers that you might have. 2 speakers, 2 channels. The last number is used to set the size of the samples (in bytes). Again, unless you really know what you are doing, it’s best to leave these numbers alone.

To tidy things up, we need to make sure we stop the SDL_mixer service when we are done, as well as freeing any sounds we may have loaded. So open up CApp_OnCleanup.cpp and add the following:

And we are done! Try compiling, and pressing the 1 and 2 keys to here some sounds. If you need some WAV files, download the project files below to grab them.

SDL SoundBank – Tutorial Files:
Win32: Zip, Rar
Linux: Tar (Thanks Gaten)

We’re going to need several files in the beginning, Define.h, CArea.h, CArea.cpp, CMap.h, CMap.cpp, CTile.h, and CTile.cpp. So create these blank files. What we are going to do is have one Area object, this Area object will have many children Map objects in a vector (like the Entities in a vector). Within each of these Map objects, they will have a vector of each individual tile. So basically, we have a bunch of tiles that make up a map, and a bunch of maps make up an area.

Lets start by opening up Define.h. This file is going to hold some constant values, as defines, that will define things like map width and height, screen width and height, and tile size. These are going to be some values that we will be using throughout making our Maps and such. Add the following below to define.h.

We’ll get back to what these values mean later, but WWIDTH and WHEIGHT are the values set in SDL_SetVideoMode. So open up CApp_Init and change that function call to the following:

Simple enough. Next, open up CTile.h. This class is going to define a single tile on a map. In gaming terms, a tile is basically a single square graphic that we draw to the screen. Remember the animation tutorial, each frame of Yoshi could be thought of as a tile. So when I say we have a map made up of many tiles, we are taking these tiles and repeating them in a grid sequence.

And since we have a single graphic containg all of our tiles, we only have to load one graphic, and not several for each tile. Each tile then needs some properties. The most obvious is which graphical tile to use. Take a look at an example tileset below:

You’ll notice that the very top left has an ID of 0, and going to the left it increments in 1s. This is called the Tile ID. By using the ID, and the size of each tile (TILE_SIZE), we can know which tile to draw to the screen. The next important thing is TypeID. This determines what type of tile it is. Some examples might be, invisible (don’t draw a tile), block (like a wall), or ground (player can walk on it). You can define whatever TypeIDs you want, but these are the most basic (other examples might be water, fire, ice, etc…). That’s basically it, this Tile class only has two members (for now, later on it will contain information for animated tiles). So lets push this class together inside of CTile.h:

Notice the enum used. This lets us assign or check the TypeID, and know what it is at the same time. So if I did TypeID == TILE_TYPE_BLOCK, I would be able to notice in my code that I am checking for a block type of tile. TypeID == 2 isn’t as easy to interpret. If you never used enums, think of them like const variables. The value never changes. Also, the starting value defines the rest, notice I have = 0 on TILE_TYPE_NONE. From there the rest of the variables would automatically be assigned values in increments of 1.

Now, lets open up CTile.cpp and finish the code:

Pretty straight forward. Next, lets look at making some maps. The first thing we need to consider is that our maps will be text files. So we need to come up with a file format, that way we can easily edit our maps outside of our code. And possibly later you could create a map editor.

Each map is going to have a width and height, defining the number of tiles. So a map of 10×10, would have 100 tiles in it. We are going to make all of our maps the same width and height, so we don’t have to define that within the map files (MAP_WIDTH and MAP_HEIGHT). The part that we do need to add though is the TileID and TypeID for each individual tile. We are going to use the file format that I came up with, as it is relatively simple. Take a look at the 5×5 map example below:

0:0 0:0 0:0 0:0 0:0
1:0 1:0 1:0 0:0 0:0
1:0 1:0 1:0 0:0 0:0
1:0 1:0 1:0 0:0 0:0
1:0 1:0 1:0 0:0 0:0

Each tile within the file would consist of 0:0, effectively being the TileID:TypeID. A space would be the deliminator between the tiles. A concept rendering if this map may look like this:

For this tutorial we will be using 40×40 maps, since that is a pretty decent size. And instead of printing an example out for you to copy, click on this link here:

Example Map

First create a folder in the same directory as your exe called maps. This folder is where all your maps will be. Save that map as 1.map. Also, make another folder called tilesets in the same directory as your exe, and save the tileset above as 1.png.

Now that we have a file format for our maps, lets start designing the class that will render this thing. Open up CMap.h:

A few of the basic things are here, OnLoad and OnRender. OnLoad does what you expect, loads a map from a file, and populates the TileList. The OnRender also does what you expect, properly puts each tile on the screen and draws them using the Surf_Tileset. Lets define what these functions do, now open up CMap.cpp:

Lets start at the top. The constructor sets the Tileset to NULL, obviously. Next we have the OnLoad function. First, we are clearing out any old tiles, that way if we load twice, it won’t have double the amount of tiles, effectively loading a new map. We then open up a FileHandle, and try to open the requested map file. Now, we go through the map file and grab each tile. This is accomplished by using the two loops. The outer loop is the Y axis loop, going from the top row to the bottom row of the map file. The inner loop is the X axis loop, going from the left most tile, to the right most tile. Pay attention to how this loop works, because it is also used below in the OnRender function. It basically goes from the top left tile, to the bottom right tile, 1 tile at a time. Inside of those loops we create a temporary tile, and load the file information into it. We then push that into our TileList, effectively saving the tile. We close the filehandle, and we are done.

Next, we have the function to render a map. Notice the MapX and MapY arguments. These tell use where to render this map on the screen. This is useful later on for moving maps around. First in the function we check for a valid tileset, because we are going to access this tileset directly and don’t want to cause a crash. We then grab the TilesetWidth and TilesetHeight in Tiles. This is important, because we need to know how many tiles a tileset contains, not its actual width and height. That way we can match up a TileID to a tileset. So, a Tileset with a Width and Height, in tiles, of 2×2, would have 4 tiles on it, but in reality it would be 32×32 pixels. So, a TileID of 0 would match the first tile, a TileID of 1 would be the next, and so on. TileIDs repeat on the next row, from left to right.

Okay, next we have that same loop again, going through each tile (Please note that these X and Y coordinates here in the loop are also in number of tiles, they aren’t actual pixels). This time, however, we have an ID variable. This ID is incremented by one each loop, and will allow us to grab each tile in the map. So, first we check to see if this Tile should even be drawn, by checking the TypeID. If it is TILE_TYPE_NONE, we skip over it with continue. After that we figure out where to draw this tile on the screen. This is done by taking the MapX and MapY (effectively offset coordinates, because they offset a map from 0, 0 to somewhere, which makes it seem like a map is moving), and taking the X and Y coordinates in the loop. We have to convert these X and Y coordinates back to pixel coordinates, which is done by multiplying it by the size of a tile.

After that, we do something with the Tileset. What we are doing is calculating where on the Tileset to grab the appropriate tile. This is by grabing the TileID of the tile first, and then converting that to a Tile coordinate. A little bit of explanation here. We have our 2×2 tileset, and a TileID of 1. Figuring out X, we would get 1 % 2, which would be 1 still. We when multiply that by the TILE_SIZE, and get 16. That is the correct X coordinate for the Tile. Same with the Y, we put 1 / 2, which is 0.5. Since this an integer operation, the .5 is automatically dropped. Thus we are left with 0. Which is also the correct row. Now, say we had a TileID of 2. 2 % 2 = 0, and 2 / 2 = 1. See how the X repeats in a pattern? 0, 1, 0, 1… And notice how Y increases every time it goes past the Tileset Width? 0, 0, 1, 1. I hope this is clear, as it is somewhat hard to explain.

Next, we actually draw the tile to the screen using the coordinates we just calculated, and then increase the ID to go to the next tile. A little side note here, we could, for the sake of speed, create an OnRender_Cache function that would perform this same operation, but would draw to a Surface defined in the CMap class. Something like SDL_Surface* Surf_Map. Then, the OnRender function would render the Surf_Map only, and not perform any operations. But also take note that that method does not necessarely work later on when we want to animate tiles.

Okay, cool! I know that is quite a bit to take in at once, but don’t fret! It’s really not too bad once you get the hang of it. I want to say that right now we could create Map objects and render maps just fine. This would be ideal for games like Mario and Megaman, as they are just one big map. But for games like Zelda and Metroid, it won’t work too well. That is where Areas come in. Just like maps having file formats, each area will have its own file and file format. Each area is going to have a tileset to load, the size of the area, and the maps that are to be loaded in each area. Here is the area we are going to be using below:

./tilesets/1.png
3
./maps/1.map ./maps/1.map ./maps/1.map
./maps/1.map ./maps/1.map ./maps/1.map
./maps/1.map ./maps/1.map ./maps/1.map

Save this into a file called 1.area, and save it in your maps directory. Just like maps, this area will tile maps. I won’t get into detail because I think you all have the point by now.

Open up CArea.h and lets begin:

This class is going to similar to the Map class in some ways, but different in others. Similarly, we have MapList that will hold our maps, just like the Map class had a list of tiles. Also, as have a Load function and Render function. Now the differences, we have a static AreaControl, much like Entities have a static control. This will allow us to manipulate an Area from any class by using this object. Next, we have the AreaSize which is the number of maps. We are going to assume that areas will always be square, so an AreaSize of 3, would be a 3×3 area. If you wanted to, and I don’t think it’s necessary, you would have AreaWidth and AreaHeight. Next, we have a surface for the Tileset. You probably noticed that within the CMap class we never actually loaded a tileset. That’s because the Area is going to do it for us, and then pass that pointer to the CMap class. That way each map doesn’t load a tileset for itself, but effectively all maps share the same tileset. Again, if you wanted each Map to have its own tileset you can easily modify the class to do so.

Okay, now open up the CArea.cpp class:

Quickly, going from the top, we declare the static object, and then set the AreaSize to 0. Then we have our Load function. It works just like the Load function within CMap, except there are a few differences. We have to load tileset first. We try to load this tileset into the surface, and if it fails return false. We then load the size of the Area. Okay, after that we have two loops, just like maps, that will go through and grab each map filename. It will then create a map object, load the map, set the tileset to be used, and then push it into the list. Pretty simply and straight forward.

Next, we have the Render function. We calculate the actual Map width and height, in pixels, first. This will let us find the first map to render. Some explanation first of what I am trying to do. Since an area can be of any size, like 100×100 maps, we don’t want to go through all the trouble and render every single map. We only want to render the maps that are visible in the screen area. For our size of a screen, 640×480, only a possible 4 maps can be visible at one time (like standing at the corner of 4 maps). So what we have to do is calculate the first Map ID to grab. This is going to the first map to render. From the first ID, we know the next 3 maps to render. The one to the right of the first map, the one at the bottom of the first map, and the one at the bottom right of the first map. How is that accomplished? Look at the image below: