GFX with SDL. Lesson 3: Sprites | GFX совместно с SDL. Урок 3: Спрайты | |
Hello and welcome to this yet-another-tutorial. This lesson will be about the things that most 2D games use - sprites. In a way sprites are like objects. I'm sure that at some point in your life you have seen or have played Super Mario or some other similar 2D game. Think about all the enemies, blocks, coins, etc. that you saw in that game. All these are called sprites. The main character (Mario) is a sprite, the enemies are sprites, the coins are sprites, the tubes are sprites, even these things that you can stand on are sprites. Everything that impacts the game/player/monster in some way (eg: you can touch it) is basically a sprite. The background is simply a background - you can't touch it in any way. Sometimes some sprites are parts of the background (eg: a sun that is moving/rotating, but can't affect you in any way). Let's call them passive sprites. And let's call the sprites that can affect the player (and the player itself) active sprites. In our little sprite demo that we will create today, we won't seperate active and passive sprites. Altough the vikings could very well be active sprites and the sun a passive sprite. Active sprites need to collide with each other. And if a collision occurs, respond. That's all called collision detection and response. More on it in a future lesson. Besides being active and passive, sprites can also be animated or non-animated. And all sprites can have the possibility to change their x and y location on the screen. Sprite animation doesn't only mean that a sprite moves from point A to point B, but MOVES from point A to point B. Examples of sprite animation can be: a ball rolling (rolling animation while changing the ball position), somebody walking (animation of legs moving while moving the position), a blinking traffic light, a lighthouse, etc, etc. | | |
The sprite system that we will build today will consist of 2 parts: the sprite base, that we will use to store all the frames of the animation, and the sprite itself. The sprite itself is the thingy that moves on the screen. The reason why we have 2 classes in our sprite system is really simple. Usually in a game you have many sprites that look the same. In our sprite classes we will load all the animation data (frames) into the sprite base and then each individual sprite will access it from there. If we would load in all the data (images) with each sprite, then that would boost up the memory requirements a lot. | | |
