pikuorguk

My game engine now has scrolling tilemaps in it. I have arbitrarily chosen each tile to be 32×32 pixels, and the maps to contain 256×256 tiles. This gives me a virtual display of 8192×8192 pixels to make tile-based games in. 8192×8192 pixels is a lot… just over 67million pixels. Storing that as a bitmap would require a bit more RAM than my PC has.

This is why tilemaps are good. Big game areas, not much RAM usage.

Drawing them is easy. Draw tiles in a bitmap, then have a 2D array that says where each tile goes. Each tile is numbered, starting at zero. Scrolling is easy too, you just draw a different part of the 2D array on the screen. This makes a slightly jerky scrolling tilemap though since the smallest unit you can scroll is one tile, rather than one pixel. To implement smooth pixel-based tilemap scrolling requires a little bit of thought.

Not much mind.

I did it by having an offscreen buffer that was two tiles larger in both axes than the screen, giving me a 1 tile wide border around the screen. Now, when scrolling, I copy that buffer onto the screen, adding or subtracting an offset to decide which part of the offscreen buffer to use. When the edge of the buffer is hit, I reset the screen back to the centre of the buffer, and redraw it using a different part of the tilemap.

Enough waffle, here’s some code:

    void TileMap::DrawMap(BITMAP *bitmap)
    {
        masked_blit (buffer, bitmap, scr_xoff, scr_yoff, 0, 0, buffer->w, buffer->h);
    }

    void TileMap::RenderMap()
    {
        for (int y = map_yoff; y < map_yoff + buf_theight; y++) {
            for (int x = map_xoff; x < map_xoff + buf_twidth; x++) {

                int xx = (tilemap[x][y] % (int)(tiles->w / tile_size)) * tile_size;
                int yy = (tilemap[x][y] / (int)(tiles->w / tile_size)) * tile_size;
                blit (tiles, buffer,
                    xx,
                    yy,
                    (x - map_xoff) * tile_size, (y - map_yoff) * tile_size,
                    tile_size, tile_size);
            }
        }
    }

    void TileMap::ScrollMap(int x, int y)
    {
        map_xoff = x / 32;
        map_yoff = y / 32;

        scr_xoff = x % 32;
        scr_yoff = y % 32;

        RenderMap();
    }

Note that the ScrollMap() function doesn’t test for wandering off the edge of the map, and it dumbly redraws the whole map every time. These are things I will change later.

For a video of it in action, click this link.

Originally published at Error_Success. Please leave any comments there.

I’ve made some more progress on my game engine since last time. I’ve been concentrating on the sprite subsystem, making it so I can have things moving around the screen. All of this is being controlled by the XML file, so most of the coding has been quite generic; creating “manager” classes and storing things in lists. And parsing XML… lots of XML parsing. It’s the type of coding you can spend hours on, but have little to show except a bunch of classes and a single sprite on the screen that does nothing at all.

Well in the spirit of learning something new, I decided it’d be good if my games could have sprites that followed patterns on the screen. This could be used in shooter games, or as the beginning of an AI in some sort of top-down car racing game. This post on the Shmup-Dev forum introduced me to Catmull-Rom splines, and after a few hours I had little test sprites making their way around the screen. With a bit of modification, I then made it so that I could have “chains” of sprites chasing each other around the screen, all glued to the same path.

So now I can have enemies enter the screen, fly around a bit and then disappear off the screen again.

I need to think up some way of timing the appearance of entities on the screen. Currently I use a frame counter, but it’s a bit of a hack at the moment.

I recorded a video that demonstrates it a bit better. http://www.vimeo.com/8015369

Originally published at Error_Success. Please leave any comments there.

I thought it about time I showed some sort of progress, so here’s a short video demonstrating the menu system my game engine has. The screens aren’t hard coded, the XML control file defines what screens the game has, how they link up and so on. Even the menu options and their actions are defined in the XML file too.

Now I’m making sprites work, which should make a more interesting video.

The video was captured using CamStudio, which is a neat OpenSource screen capture program. I was going to use Fraps like everyone else does, but it doesn’t seem to record Allegro games.

For reasons I don’t understand, embedding the video here doesn’t work. Instead you will need to click this link to see the video.

Originally published at Error_Success. Please leave any comments there.

My code running a Lua script

Well, this is a bit fun! One of the main points of my game environment is that I should be able to easily modify entity behaviour without having to hard code anything into the environment itself. After a bit of thought, the programming language Lua seemed to be the best idea.

I was completely amazed at how easy it was to add this to my own software. After compiling it up, a surprisingly small amount of code is required to get the basics working. It was harder working out how to extract the Lua script from the zipfile I am using.

The screenshot illustrates a very simple Lua script that does nothing more than contain a function called “think” which looks like this

– Basic test
function think(xpos, ypos)

print (”xpos = ” .. xpos .. ” ypos = ” .. ypos)
x = xpos
y = ypos
return x, y
end

So it takes in two parameters, prints them out, then returns them back to the host C++ application. So my C++ application calls the function in Lua, that prints out the values it received, and then returns them. If you look in the debugger you can see it all works

Now to work out how to expose data and functions in the C++ application so that Lua can use them. I need things like “getPlayerPosition” and so on.

Originally published at Error_Success. Please leave any comments there.