Archive for the 2D Game Engine Category

Further progress

Posted in 2D Game Engine on November 12, 2008 by zxdunny

Not a lot to show this time, but rest assured that work is progressing. 


I’ve spent the previous few days implementing the level manager (and entertaining visitors, which explains the lack of updates) – this is the code that controls levels and their associated layers. It’s the thing that does the rendering of the level to the bitmap, and manages the scrolling. Callbacks are implemented both pre-and post-layer rendering, so you can processing the image of the game area as it’s built should you choose to do so.

The demo I posted in my first post was basically the layer manager and tile manager being used to mock up a level, and this code now wraps all that up into one unit. The aim here is to reproduce that demo using the level manager to make sure things all work as they should.


A level is basically a list of TLayerinfo types, which describe the layer to be drawn, and the offset x/y that it should be drawn at. Layers, as have been seen previously, do not have to be any set size (though being at least the size of the viewable area is good if they don’t wrap), and have a few values associated with them –

callbacks – these are fired off into user-code before and after the layer is rendered

Offsets – used to render the layer at the correct position

Scroll scalars – used to modify the offsets above by a set amount (float values) to perform scrolling. This will all be wrapped up by the LevelManager.ScrollLevel() procedure. 

Flags – this value is a 32bit DWord which hold boolean values on each bit for flags such as wrapping and collision/notifications.

I’m currently considering allowing a list of “states” to be specified for each level, where each layer’s position is stored – this would make it easier for the user to specify how a level will look when for example, a player enters that level at different points in the level. However, that’s for another day :)

Now I have to get the level editor done – a tool that allows you to visually set layers up and move them around relative to one-another. The asset loading and saving code is done for the level manager, so it should be a pretty easy job to get this done.

When all that is complete, I can start of Sprites and how they interact. This is gonna get pretty messy – as I mentioned previously, if  a sprite is moving at 3 pixels horizontally per frame (quite fast) and hits a wall, then the collision will fire only when the sprite is actually intersecting the object it has collided with. Obviously, if you just want the sprite to stop when it hits something, you don’t want it to appear to be buried inside whatever it hit! This is just one of the problems I can foresee, and will take some figuring out.

Suggestions on how to deal with this problem would be gratefully accepted – my current methods as planned will consume a not inconsiderable amount of CPU to implement, especially as there could be hundreds of sprites per frame with this checking enabled… Of course, not all sprites have to collide but in a bullet-hell type shmup, you’ll want a lot of collision to be checked. Or not, if you render the bullets first (with no collision) and then the player sprite(s) with collision. It’s this sort of thing I can’t accelerate with hardware support.

Ooh, the possibilities :)


Getting started

Posted in 2D Game Engine on October 24, 2008 by zxdunny

It’s about time I started blogging again.

There’s been a fair amount of interest in this – I’ve been making a 2D game engine in Borland Delphi, and I’ve had some people ask me to blog about the design and coding process. So that’s what I intend to do. The engine should be fairly capable, and is built around classes designed to handle one part of rendering a game. 

The design is simple – a 2D game is (usually) a room or level, which consists of tiles which make up the background and sprites which can collide with eachother and with the background. To this end, here’s the structure of the classes:

TGameEngine – the overall wrapper for the game. This contains:

TTileManager –

Manages lists of tiles. Each tileset is of a given size (say 16×16, or 32×32) and the tile manager is responsible for drawing each tile to a given DIB. Tiles have two masks – a collision mask (currently 1bpp) and an alpha mask for blending. The alpha mask is used when rendering to the DIB.

The tile manager also contains mechanisms for referring to tilesets by name rather than by index. More on how this is done later. You can add or remove tilesets using the methods provided. Each tile can have two callbacks associated with it for pre-and-post-processing – you can, for example, render the tile yourself and add say a blurring effect after it’s been rendered, or if you want to modify the DIB before it’s rendered then you are free to do so.

TLayerManager –

This class handles layers. Layers can be any size, and made of tiles from any tileset that share the same dimensions. Each cell in the layer can have a callback associated both pre-and-post render, as with tiles. The Manager is responsible for maintaining a list of layers that are used to create a TLevel. It is the part of the engine that renders a layer to a specified place in a DIB – or, rather it renders a layer to a DIB by centreing on a specified point in the layer. 

TLevelManager –

This manages a list of TLevel classes. The TLevel contains a list of layers used in a level, sprites utilised by that layer and certain flags – if the layer can be collided with, if the layer scrolls (and at what speed if so), various callbacks associated with pre-and-post layer rendering etc.

TSpriteManager –

This manages and draws sprites, maintaining a list of sprites and their masks and animations. Like tiles, sprites have both a collision mask and an alpha blending mask, used to render them. Unlike tiles, they can be any size and can appear on any layer. When drawn, they can trigger callbacks to notify the user that they have been drawn, and also (if set able to collide) when they intersect with certain tiles and other sprites. They can have any number of animations (all of which must be of the same size, like a TTileset).


That then, is as far as I have got so far. I’ve put a demo up – here’s a picture of it:


A demo of Layers being used for parallax scrolling, and also demoing the post-processing callbacks of TLevel.

A demo of Layers being used for parallax scrolling, and also demoing the post-processing callbacks of TLevel.


You can find the demo at

Yes, it’s a bit Ghosts’n’Goblins, and I’m probably the worst pixel artist in the world… But it does illustrate the points above. Use up/down/left/right to move around. There’s no sprites yet, just layers. As each layer is drawn, a post-processing blur and darken is added to the DIB used to draw the display. This isn’t the final engine method, as it relies on crappy windows timers. You can see where I’m heading here.


I hope to port this to fpc, so I can develop for the new Pandora console due out any time now. Let’s see how far I get :)

Next up though is getting the sprites in, and then collisions. It’s going to be interesting to do proper collision (a doddle to see if something has collided, but not so easy to determine if something will collide, and how much it can move before it does… when you have sprites flying around at more than one pixel per frame, it’s easy to get things stuck in the scenery, or worse – fly right through it!

All things I shall have to address in time. God help me.