Author : Filipe Medeiros
Page : << Previous 2 Next >>
are strongly advised to upgrade it. This tutorial was written between versions 2.2 and 3.0 of Allegro. It does not cover the new truecolor and hicolor features -- it only covers 256 colour graphics. For information on using higher colour depths I suggest you look at Shawn Hargreaves' `Pot of Gold', linked from the Allegro web pages mentioned above. Most things should still work for older versions, but some things may not -- such is life. Versions of Allegro older than 3.0 all require C++ support to build. You don't have to program in C++ if you don't want to, but you must have the support. Either upgrade Allegro to v3.0 (recommended) or install djgpp's C++ support (see `readme.1st'). If you don't upgrade your Allegro version, you may need to rewrite some of the sample code in this tutorial. Hopefully more recent versions of the above packages will retain backward-compatibility with these versions; if not, you will again have to figure the changes out for yourself. You *will* need the GNU make utility, despite the fact that `readme.1st' marks it as optional. It is a highly useful package, and Allegro is designed to be built (painlessly) using it. The latest version (as of writing) is `mak3761b.zip', which is compiled with version 2.01 of djgpp and will *not* work correctly with version 2.00. Most people seem to program using one of three systems: some people use RHIDE, some use Emacs, and others use simple text editors and the make utility. This tutorial will not attempt to force any of these systems onto you; you should program in whatever environment you like best. When the examples get written, makefiles will be included, and possibly RHIDE projects too.
1.5 Before we start...
This tutorial is aimed at people of a range of programming abilities, from those who have only just learned to those who have much experience already. If you feel a section is at all patronising, don't read all of it -- most likely that section is aimed at people below your standard and all you need to do is skim it to familiarise yourself with the commands it introduces. have enclosed some sections' titles with [ and ], indicating that the topic is either advanced, complicated, tedious to implement or just a bit of a tangent. Don't read it if you don't want to. A big issue in writing games is inspiration -- if you can't think of something to write, then you can't write it. At first you will probably either not think of anything, or think of too many ideas which seem far too complicated to implement. If you can't think of anything, relax and read this tutorial. Use the example programs as a base, add new things to them and personalise them. As you read through you will get a better idea of what can and cannot be done. Look at commercial games, too -- see if you can firstly see how they do what they do, and secondly improve upon them. Don't assume it's completely out of reach -- as you gain experience you will be able to see different ways of doing things. Remember, the authors wrote it somehow; it must be possible. If your ideas are too complicated, the above point applies again -- the more games you write, the better you are at writing them and the more games you are able to write. In almost all situations for beginners, the key point is to start simple and get a working game early on, then build up from there. This technique does have its disadvantages but for now it should be fine. Last of all, games are supposed to be fun; that's their purpose. You cannot write a fun game if you're not enjoying writing it. If you find this tutorial boring then I've written it badly and it should be changed, so please tell me. This tutorial is for you and others like you; enjoy it!
2.1 What is Allegro?
Allegro is a game programming library, mainly written and coordinated by Shawn Hargreaves. It is a very good library; it is fast, and has a large number of features. For full information, see its web pages:
http://www.talula.demon.co.uk/allegro/
2.2 Where to find Allegro
Allegro is available primarily from the links on its web site (see Section 2.1: What is Allegro), notably as part of the djgpp distribution at `ftp.simtel.net'.
2.3 How to install Allegro
Create a directory for it, anywhere you like (it doesn't have to be in your djgpp directory tree) and unzip it, preserving its directory structure (pass `-d' to `pkunzip'). Make sure it has, for instance, created a directory called `docs'. When that's done, go to Allegro's base directory and type: make
This should then go all by itself, and finish with a short message telling you it worked. If this does not happen, read the Allegro documentation if you have not already done so (in the allegro directory -- `allegro.txt', `faq.txt' and particularly `readme.txt'). If you're still stuck, try asking on the Allegro mailing list -- `allegro@canvaslink.com'. See the `Contact Info' section at the end of Allegro's `readme.txt' for subscription information. Most people just reply to the mailing list, though, so if you're not subscribed you should point this out and ask people to Cc: their replies to you as well.
2.4 Testing the installation
The installation is pretty much self-testing, because it compiles all the example programs and utilities. However, for completeness I have included a short program to check the header file and library can be found. To perform this test, cd to this tutorial's src directory and type:
make test2
If there are no errors, great. If it can't find `allegro.h', `liballeg.a' or `-lalleg', the installation didn't work correctly and you should reread the documentation in more detail.
2.5 Using Allegro
This duplicates briefly what the Allegro documentation says. Firstly, any source file which used Allegro functions or variables must `#include <allegro.h>'. Put this *after* any standard header files -- in particular, it must go after `#include <stdio.h>' -- to prevent clashes between the header files.
Secondly, you should call `allegro_init()' near the start of your program. This initialises some important general things in the library and is essential. You also need to initialise any individual subsystems that you will be using, but we'll come to that later. I suggest that you make `allegro_init()' the first thing in your `main' function.
Thirdly, at link stage you must link in the Allegro library. This is accomplished by adding `-lalleg' to the *end* of your linking command. The linking command is the one which produces the executable file; it may be the only command you use. During this tutorial, though, I will encourage you to split your projects between multiple files.
For an example of this, see `test2.cc' in the `src/tests' subdirectory of the main tutorial directory. Anyway, enough of that -- let's get on to the interesting bits.
3.1 What does a game need to do?
Most games are built around the same basic concepts. There are, of course, exceptions, and I am not a professional game coder, but in my experience the following system generally works very well.
1. Initialisation
First of all we need to put the game into a known state, so that it always starts in the same way. For example, you might want to start the player in the middle of the screen, make a maze, or create a random map. All that would go in here.
2. Main game loop
The game will need to keep doing things, over and over again, until the player dies, wins, gives up, or whatever. So we have a main game loop. It has three main components:
A. Input -- getting input from the player
B. Processing -- moving things around, responding to the input
C. Output -- sending information back to the player, usually by putting it on the screen but also by way of sound
3. After the game
When the game has finished, we may need to do some other things, like tell the player why it finished, update a high score table, or something like that.
In reality the above is usually also contained in a larger loop, so that the game can be played over and over without dropping to the OS in between, and there's some initialisation before the outer loop and tidy-up code after it, e.g. loading the high score table from disk on startup and saving it again on exit. At first, though, we'll just do a single run of the game per execution.
3.2 Proposed
Page : << Previous 2 Next >>