This post is a portion of Part 2 in my on going series about 2D Game Development using the Allegro 5 library. These posts are in course order. You can see all of the posts in this course by clicking the “2D Game Development” button at the top of this site.
- Part 2.0: 2D Graphic Basics
- Part 2.1: Starting the Code
- Part 2.2: Initializing Allegro Graphics
- Part 2.3: Using Fonts and Text
- Part 2.4: Graphical Primitives
It’s time for my favorite chapter of any book: the second chapter. There is just something so magical about it. You have made it through the introductory items, and your appetite is whetted for the knowledge that is to come. This chapter is where your journey truly begins. Talking about game development is all well and good, but it is all just talk until you can actually get something up on the screen. We are going to look at 2D objects and the world in which they live in this chapter. So, without further ado, let’s get our hands dirty (figuratively).
2D Graphics World
Humans perceive everything in three dimensions. With the exception of individuals who have sight in only one eye, people are able to perceive depth. It always amuses me when someone tells me about amazing hi-def. 3D images. I always rebut that everything we see is in hi-def. 3D imagery. Due to our “perception”, 3D feels like a very natural topic. It is because of this that working with a 2D world can feel so abstract at first. Essentially, in a 2D world everything is perfectly flat. There is only up, down, left, and right. There is no towards or away from the viewer. What we give up in realism and familiarity, we gain in simplicity and performance. While a 3D world is governed by three directions (x, y, and z), a 2D world only has two (x and y). While 3D movement is achieved by performing arithmetic on matrices, in a 2D world movement is just a manner of addition or subtraction. You may be wondering to yourself “why such a large jump in complexity?” The answer is simple: perspective. In a 3D world, as objects move around they get bigger, smaller, or skewed. Essentially the perspective of the object relative to the viewer shifts. This is not something that generally happens in a 2D world. Since everything is flat, the perspective is fixed. The result is that things tend to be much easier.
In 2D, a square is a simple four sides with no perspective:
In contrast, a 3D “square” is called a cube. It has six faces twelves sides and involves a lookers perspective. This means it will look different depending on your positive relative to the object.
Until the future that science fiction has been selling us on comes to fruition, video games are stuck being displayed on a screen. Therefore, it is a pretty good idea to understand the fundamentals of what a screen even is. A screen can be thought of many different ways, and in development we use all of them.
At its most basic, a screen is an array of pixels. These pixels (short for “picture elements”) are the smallest usable points of a screen. The next time you are by a screen (monitor, TV, etc), get really close and look (I know your mother probably told you not to sit too close to the TV, but don’t worry; I won’t tell her if you don’t). Chances are that if you have decent vision, you will barely be able to make out these vague little squares. Those are pixels. When speaking of a screens resolution, we are referring to the number of horizontal and vertical (respectively) pixels a screen contains. For instance, an older monitor could only display in 640 x 480 (640 horizontal pixels, 480 vertical pixels) while a newer model can display at 1600 x 1200 and higher! We can lower the “resolution” our monitor is displaying at as well. This doesn’t actually reduce the amount of pixels we have. It just simulates having fewer pixels by grouping the actual pixels up. That way, what we see as one pixel, may be four or more pixels together. Each pixel is made up of three channels: red, green, and blue. If you have ever heard the term RGB, those three colors is what it is referring to. Numerically speaking, a huge spectrum of colors can be represented by scaling each of those three colors from 0 to 255. For instance, black can be represented as (0, 0, 0), white is (255, 255, 255), red is (255, 0, 0), medium grey is (127, 127, 127), and a hideous magenta color is (255, 0, 255). I can go on and on about color theory, but that is a bit off topic. So what we have so far is that a screen is an array of these things called pixels and each pixel is just different intensities of the colors red, green, and blue. Got it? Good.
Another way to think about a screen is as an Etch-A-Sketch. If you have ever used an Etch-A-Sketch, then you know pretty much how they work. You painstakingly draw a picture (one point at a time no less) until you have a piece of art. When you want to draw something else, you shake it until the picture goes away. Then you begin drawing again. That is almost exactly how a video screen works (even the drawing one point at a time part). The only difference is that a screen completes the drawing and erasing approximately 60 times a second. That’s a lot of shaking!
The act of drawing to a screen is called rendering. As a game developer, you are going to spend a lot of time thinking about, working with, and improving the art of rendering an image. Luckily, this is something that a library like Allegro makes pretty easy for us. In a nutshell, think of rendering as spinning the dials on an Etch-A-Sketch perfectly, and really fast. We will look at rendering here soon once we get to drawing shapes.
The final way in which we look at a screen is as a grid. The “square” nature of pixels and screens in general make them perfect for a grid layout. With Allegro, we treat the screen as a sort of inverted Cartesian coordinate system. That is, all points can be described as a combination of an X value and a Y value. The X value represents the horizontal, or left to right, direction while the Y value represents the vertical, or top to bottom, direction. The origin (or x = 0, y = 0) can be found in the upper left hand corner. That means that as a point moves rightward, its X value increases. Likewise, as an object moves downward, the Y value increases. In 2D game programming, there is no negative X or Y values as that would be off of the screen.
In the next post, we will go back and look more closely at the code from Part 1.2