Over the last couple of days, I’ve spent a bit a bit of time cleaning up and fixing things for my game engine, so I thought I’d do an update on it. If you’ve tried the engine or the games before, and it didn’t work, it’s worth trying it again now: I’ve fixed lots of issues in the engine, and put up new versions of all the games and all the source codes, so everything should be up to date now, and you should be able to build the projects in any Visual Studio version from 2003 and later. Also, the games appearently run fine on Linux, using Wine, but I haven’t tried it myself (I’m not a linux guy).

Pixie is a 2D game engine (which is good, because 3D games are a bit lame anyway. Don’t worry though, I’m building a 3D engine on to of it too) for C++, specifically designed to be easy to use and run on as wide range of computers as possible. It will check the players system for DirectX, and make use of it if it’s there, but it doesn’t require it. There’s no annoying runtime librarys or dlls you have to ship with it: In fact, you can bundle all your data files into your executable if you like.

At the base level, Pixie is using optimized software rendering code to draw rle-compressed bitmaps to the screen rather quickly. And if you’re a hardcore graphics programmer, you can use that functionality as it is for your game. But I’ve also added a few things on top of that, like sprites, buttons,  animations, text etc, and by using those, you’ll probably get more done on your game in shorter time. For those of us doing retro stuff with pixel art, there’s a special mode you can enable where Pixie ensures there’s no blurring or weird scaling distorting those precious pixels, keeping things sharp and crisp regardless of what system it’s running on.

Pixie is totally free by the way. And by free I don’t mean the bogus "free" of the Open Source world, where they force you to do all sorts of things to comply with the license. I mean proper free, as in "public domain". This means there’s no license agreement for Pixie: It doesn’t even belong to me, it belongs to all of us, so we can all use it for whatever we want. Want to sell a game you made in Pixie? Just go right ahead. Want to write a book about it and bundle the engine and the game source codes? Feel free. Want to set up your own site, rename it to Fairy and claim you wrote it? I’m not going to stop you (though itwould be rather cheeky )

I’ve used Pixie for a couple of game demos so far (and I’m working on a full game as well, but I’m not ready to talk about that yet), and it’s getting quite good now. Check these out, if you haven’t already: they’re good demos of Pixies capability. None of them took longer that a week to do, and the RPG-style game (Kassandra) only took 48 hours (but a quite intense 48 hours, I tell ya!). So it can be rather quick to get things done with Pixie.

The source code is available for all of these games, but I warn you, it’s a bit messy in places, as I was a bit rushed when making them…

I’ve also done a little utility for managing poser files (I call it Poser Content Manager), and I used Pixie for that as well. Again, source code is available.

More recently, I’ve been writing a couple of tutorials introducing the basic concepts of Pixie.

The first one is a simple Hello World tutorial, where we just draw some text to the screen. But it also walks you through some of the basic concepts of Pixie, and shows you how to set up a new project for Pixie using Visual Studio.

The second tutorial is a bit more interesting, as it shows how to make a bouncing ball, but I also explain in-depth about how bitmaps work in Pixie, and how to work with files.

There’s some documentation available for Pixie too. It is generated from comments in the source code, and it’s not fully complete yet, but it’s an ongoing project. The documentation for Pixie can be found here.

And finally, I have set up a forum for Pixie where you can ask for help or just generally discuss things related to it. And ask me to add features even. There’s nothing on there at the moment, but be assured that I’ll keep an eye on it and do my best to help out with any problems.

Check out the main Pixie page to download it and the available source code samples.

That’s it for now, hope you’ll give Pixie a go at some point, and let me know what you think

In some previous posts, I’ve talked about the indie 3D engine I’m making, and today, I’ll be talking a bit about how I will handle materials and lighting. As with every part of this engine, I will  keep it simple, and focus on techniques that have a big visual impact with little added complexity.

Remember this figure from the entry on the basics?

I already talked about the vertices/indices bit, but didn’t go into any detail about the material bit, apart from mentioning that we only have one material per mesh (and possibly multiple meshes in a model).

Lighting and materials are important concepts. As well as making things look nice, materials are important to distinguish between different types of objects and surfaces, and lighting and shadow helps define the shape and position of objects.

The first thing to keep in mind, is that there’s no way we can simulate real-world lighting, where incomprehensible numbers of photons collide with as many molecules, and all sorts of physics magic happens. We’re not going to come even close, and we’re not even going to try.

What we will do (as with everything else to do with games and graphics programming), is to use an approximation . It’s not a goal in itself though, to keep improving this approximation  – we’re aiming for a workable trade-off between performance and visual result. For this engine, I won’t touch any of the more recent shader-based effects, as it would not make a big enough difference to warrant the extra work and the added complexity. I want this engine to run on more primitive hardware too, so as to maximize the potential market for the games using it.

Static vs Dynamic

There’s two basic concepts we need to keep separate when we discuss lighting: static anddynamic. In most games, most of the objects shown on screen are static, meaning they won’t move around relative to the other objects. This is the level, or world, that the action takes place in. Others (and fewer) objects are dynamic, meaning they can move around freely in the world. Those are the enemies, things you can pick up, projectiles, the player character and so on.

We’re also going to have lights in the world. The simplest case would be to just have one light source – the sun – but commonly we’ll have multiple light sources, especially if the game takes place indoors. And lights can also be static (meaning they won’t move around) or dynamic (meaning they can move freely).

Vertex Lighting

Most 3D hardware supports simple lighting, meaning we can set an ambient lighting level (which affects every surface in the scene equally) and add a few directional lights, point lights and spot lights to our scene, and have the 3D hardware handle it for us, by calculating lights for each vertex, and then interpolate the lighting values across the surface of each polygon, and it will do it in real-time, recalculating the lighting every frame, so it will work with both static and dynamic objects and lights.

This is certainly useful, but it’s got some limitations. First of all, we might need more lights than the handful that are supported by the hardware, especially for larger levels.

There’s ways around this, for example by doing more lights by rendering the scene more times,but that can slow things down quite a bit. Another problem is that it doesn’t handle shadows, which are an essential part of lighting, so we are going to have to do some extra work to get shadows. All the shadow techniques are quite expensive in terms of performance though, and some can have an impact on the time it takes to create models for the game too. And yet another problem is that for large polygons, the fact that light is only calculated at the vertices and interpolated across the surface, might cause lighting to look wrong in places.

Lightmaps

There is a nice solution to some of these problems: lightmaps. Lightmapping is a technique where you take the scene (objects and lights) and run it through a lightmap generator program. This will calculate the total light value for every pixel of every surface in the scene, and store it in textures. These new textures, or lightmaps as they are properly called, are then used in the game, in combination with the standard textures, to give us a fully lit scene, without the need of making any lighting calculations at run-time (though it does incur a slight cost in terms of using two textures for every surface – but this overhead is low).

The lighting calculations we use when we generate the lightmaps can be as simple or as complex as we like. We can easily generate shadows as part of it, or use advanced lighting techniques such as radiosity, and it won’t affect the performance, as it is all done as a separate step, before we import it into the game.

Light maps can make a massive difference, at a low run-time cost: if you look at the image above (from Quake3 Arena), you can see a scene using plain vertex lighting (top) and the same scene using lightmaps (bottom). We can clearly see some of the limitations in vertex lighting here – the red ambience is dominating the image, and there’s an obvious lack of shadows, making shapes blend together and distances hard to judge.

The obvious disadvantage of lightmaps is that it only works for static objects and static lights – as soon as any of them move, we’d have to re-generate the lightmaps (and that would be too slow to do at run-time). Fortunately, most things in a scene can be static, and we don’t really need dynamic lights (but we could use one or two moving lights in addition to the lightmaps if we really needed to, though they wouldn’t cast shadows). So we will be using lightmaps for lighting the level/world, and vertex lighting for dynamic objects, and stay away from moving lights altogether. Remember, keep it simple!

Environment map

There’s one more thing I’ll be adding to the light/material model: Environment maps. Environment maps are not necessary by any means – all they really do is make things look shiny. But they are quite easy to implement, works well even on older hardware, and you can easily disable them without causing any disruptions to gameplay, or even cause things to look wrong. They can be used both to make reflective surfaces (like chrome) and to add specular highlights, for glossy materials, so we’ll be adding support for them, but making sure it is easy to toggle the on and off.

The Material

So, to sum things up, a material will consist of a basemap (so we can have things look like wood, stone, grass etc), a lightmap, and an environment map. All the maps will be optional, so we’ll handle all combinations. Additionally, we’ll be able to set the color of a material, which can be useful if we want to reuse the same basemap texture for differently colored objects.

All in all this makes for a fairly simple material, which will still allow for great visual impact. We’ll get into more details when we come to implementing this, so consider this more of a statement of intent

Growing up in the 80′s, I was a proud owner of a Commodore 64 and later an Atari ST. They were "home computers" and you hooked them up to your TV, to play games or write code. Nowadays, we all run or computers on large, crisp monitors, at very high resolutions, but those just didn’t exist back in the days.

Time passed, technology got more advanced, and before you knew it, you could run all your C64 and Atari ST stuff on your PC, in a window on your desktop. Emulators, great stuff. But you know what? It didn’t look anywhere near as nice. The colors where the same, as was the resolution, and all the pixels were obviously in the right place, but you still found yourself thinking "I remember it looking much better".

Don’t think it is your mind playing tricks on you. In some ways, things DID look better back in the days. When hooked up to old worn-down TV’s with yesteryears technology, usually by means of a coaxial cable, the video output of the old home computers was severely degraded. Today, we wouldn’t find that image quality anywhere near acceptable, but back then it was the norm. And the weird thing is, in some ways it made the graphics look better than it really was.

Pixels would be a bit more glowing, and blurry, and bleed into each other, and have a subtle "ghost" effect to them, as some hues would bleed more than others. In addition, there would be slight gaps between pixels, causing what is commonly known as a "scanline" effect. All these things combined to give a sort of illusion of smoother color gradients and softer pixels.

On a modern monitor, like when running under an emulator, you won’t get that, which is a real shame. Especially since the art for those old games was hand-pixelled to look good when blurred and bled, as they were created on old CRT screens.

So, I’ve spent a little time trying to come up with an image filter for my game engine, which will take a pixel image, and make it look more like it would on an old TV screen, by emulating the artefacts we’ve come to know and love. I’ve got the concept worked out, and I’m in the process of converting it to a pixel shader, so that it can run fast enough for realtime use. That means that any game using my Pixie game engine will be able to just turn RetroFilter on or off as it please

The main reason I’m developing this is that I want it for the RetroBox project I’m working on (you can read more about this in previous blog entries), as I want to give it that proper oldschool feel to it.

There’s a annual event in Sweden, called Swedish Game Awards, where students compete in making the best game. Last year, SGA held a "warmup" competition, also open to non-students, where you had to make a 2D game in a week. The theme was "Vikings and the future". After all the fun I had making Kassandra I just couldn’t resist joining this as well. I did most of this game in a weekend as well, though some of the art was done in the preceding week. Here’s the result: Baby Viking and the Alien Invasion.

When I started working on this, I didn’t really have any ideas for it, but I knew I wanted to make something fun. I browsed through some of the Poser stuff I have, and had a look at the online poser stores too, and when I came across the baby, I got the idea to equip him with a huge axe, and thus the idea of "Baby Viking" was born. The rest sort of fell in place rather quickly: aliens, and the stealing of crops and cows as the main elements.

You can move between the two levels by climbing the ladders, and when you are located directly below a spaceship, and that spaceship have their hatch open (the transport ray is on), you can hit it with your axe, thus rescuing the cow or any crops that are still on their way up. The stage clears once you’ve taken out the number of aliens idicated in the top-right corner.

This is about all I had time for in time for the competition deadline, and I almost got the last bit in too – a teleporting alien which fires bullets at you. It made it in about an hour after the deadline…

If you want to give it a go, you can download Baby Viking here.

The source code is available as well for those interested. It uses the Pixie Game Engine(included in the download) but it is somewhat messy, as I had to rush things for the deadline…

Download the source code (needs the game if you want to run it):
Baby Viking Source Code – 923 KB

Hope you will enjoy it, and feel free to comment on the game (you don’t even need to register to post) as I’d love to hear what you think of it.

And a big thanks to Patrik Karvonen for doing the music on very short notice.

On and off, I’m working on a dungeon crawl game, where you just run around in dungeons, kill monsters and find treasure. I’m not really ready to reveal much about the game itself yet, but I thought I’d show you the characters and monsters I’ve made for it so far. I use a program called Poser to make these, which makes things quite easy

First out is the player characters. In the game, you’ll be able to choose between male and female for your character. I wanted them to look like proper adventurers, carrying lots of stuff with them.

Here’s one of the monsters – a Goblin. In my world, goblins are small and mean, and a quite primitive people.

And here, another classic fantasy creature – an Orc. I see orcs as being quite powerful and fearsome warriors, quite uncivilized and cruel, but not outright monsters.

And last, but not least, my take on the Troll. I don’t really like the Lord of the Rings type trolls (which is pretty much what I used for my Kassandra game), but prefer something a bit more like, from a fairytale, but with an edge Ideally, I would have wanted it more hairy, but I couldn’t find a good way of doing that in Poser.

I’d love to hear what you think about them, so feel free to drop me a comment (which is quick and easy, and you don’t have to register or anything).