Raytrace3.cpp

Raytrace4.cpp (With Multi-Threading)

Warning, there is a massive bug in the multithreaded version above code that went un-noticed since I was developing using an optimized release build.  Thankfully, my colleague discovered it when trying to build the demo. See the above post for a fixed and improved version.

A simple example of 3D point rotation and projection done in software.
SpinningCube.cpp

My first focus for LiteGame engine is the most broad kind of architecture, that of modules.  When I talk about modules I
reffer to things like the renderer, the sound system, sprite library, entity factory, etc.  The peices of code who’s job
is to manage a specific area of work.

A common pattern that I see in my programs is that many modules need their code to be executed in three main stages of
the application:

At startup        …onInit()
Once per frame    …onTick()
and before exit   …onFree()

In the past I have organized things loosely as follows:

#include "module1.h"
#include "module2.h"
// entry point
main( )
{
    // initalise modules
    module1_onInit( );
    module2_onInit( );
    // main game loop
    while ( game_is_running )
    {
        // update all modules
        module1_onTick( );
        module2_onTick( );
    }
    // release modules
    module1_onFree( );
    module2_onFree( );
}

It dawned on me when starting this engine that this is realy a very ugly structure.
Everytime we add a new module, we have to make changes to this file in four places.  On top of that,
we drag the header of each module into our main file, in order to access three of its functions.
Things become more complex still when we start locking the framerate, and load balancing these modules.

A nice solution would be to have some manager that can look after our collection of modules, and call their
functions at the correct times.  This also seems like a good place to insert timing code, so that we
can ensure that onTick() can be called at a set rate, giving us a constant tickrate.

An obstacle presents itself, as to how we register these modules at compile time, without any
one centralised point to explicitly register them.  I will present a solution, but please write to me if you
know any others, I would love to hear about them.

A nice solution is to (ab)use the way C++ initalizes static data, to execute code that will register
each module before the program even reaches main().  Observe the following:

struct sRegisterModule
{
    sRegisterModule( void (*onInit), void (*onTick), void (*onFree) )
    {
        module_add( onInit, onTick, onFree );
    }
};

Here we see a class that has only one method, a custom constructor that takes our module entry points as parameter.
When this module is contructed it will pass these functions to the module manager which will register a module, properly.

This doesnt seem all together so usefull until we see what happens when we include the following code inside of our module:

static sRegisterModule module1( module1_onInit, module1_onTick, module1_onFree );

Since module1 is a custom type, global static variable the compiler has to construct it at program launch.  Thus the constructor
is executed, and our parameters are passed to the module_add() function.  Thus we have found a smart way to give details about our
modules to the module manager in a distributed way.

Then our main() function can be reformed as follows:

#include "module.h"

main()
{
    module_initAll();
    while( game_is_running )
    {
        module_tick();
    }
    module_freeAll();
}

With this system a module is completely self contained, and simply needs to pull in the module manager library.  As far as I can see this is a nice basis to structure farther developments to the engine.

As I write this Ludum Dare 28 is underway, and unfortunately I am not taking part.  I planned to, I wanted to, but I have had a terrible cold for the last few days, and all of my energy has been zapped from me.  It struck me that writing a game from scratch in C++ for Ludum dare is fairly hardcore, even with the likes of SDL to make things easier.  What would have been nice is a simple engine to take the pressure off me, so what little strength I have I could have put into just making a game.

That said, I love programming the tricky engine parts, and I don’t like using bulky, bloated off the shelf engines.  I want something I made myself.  So it seems that if I spend my time wisely, making a nice game engine, I could make something amazing next Ludum dare.

I have also received many emails and messages from people wishing that I can write some tutorials on making a game engine, from the bottom up, from the simple things, to the hard things.  So what is to stop me from satisfying these two goals, making an game engine, and documenting the process and my ideas along the way for other to read.  Perhaps others could also use my engine for similar events themselves.

https://bitbucket.org/AidanDodds/litegame

I have started a GIT repository, where I will push my code as it develops.  I will also document the main elements of the engine publicly here.

Lets hope this little project spawns some great games in the future!

An idea came to me the other day, while I was writing some 2D drawing functions, specifically the timeless ‘plot’ function.  In case you don’t know, the plot function puts one pixel on the screen at a given location.

This is a function that has to be fast, because it is convenient to use it in some places such at line and circle drawing.  Image drawing on the other hand can be optimized in may ways making plot redundant for that use.

Here I will present a nice and generic plot function, that is useful when you cant optimize pixel writes, or are too lazy and just want to get on with other things.

A simple plot command may be as follows…

inline void plot( int x, int y )
{
    uint32 *pixels = screen_buffer;
    pixels[ x + y * screen_width ] = colour;
}

One problem that must be tackled with a plot function is this…  what if we draw off screen?  For instance with Plot( -1, -1 ).  In this case, the program has been asked to write to memory that it doesn’t own, and will cause all sorts of terrible bugs.

Well aha, we can fix it with the following code…

inline void plot( int x, int y )
{
    if ( x < 0 || x >= screen_width  ) return;
    if ( y < 0 || y >= screen_height ) return;
    uint32 *pixels = screen_buffer;
    pixels[ x + y * screen_width ] = colour;
}

That may have stopped us from crashing the program when a pixel is written off the screen but what might that do for the performance.  Branching is terrible in performance critical code, and this function may get called 1000+ times each frame.

I had an idea to help speed things up a little, by getting what we want, without the branches.Have a look at this code…

inline void plot( int x, int y )
{
    bool off_screen |= (x < 0);
         off_screen |= (y < 0);
         off_screen |= (x >= screen_width);
         off_screen |= (y >= screen_height);
         
    // 0xFFFFFFFF if on  screen
    // 0x00000000 if off screen
    int mask   = off_screen - 1;
    int index  = x + y * screen_width;
    int index &= mask;
    
    uint32 *pixels  = screen_buffer;
    
    pixels[ index ] = colour;
}

Here I have replaced the branch instruction with a mask operation.  In this case whenever we may write off screen, it will redirect the write to pixel [0,0].  Yay, now the program doesn’t crash anymore, and the performance shouldn’t suck too much.

There is however the problem of this distracting pixel in the upper left corner that may flash all kinds of strange colors now.  One hilarious solution is to do a final plot(0,0) with black, before you present the screen, giving up this pixel all together.  I would never be satisfied with that solution because it is just ugly.  A solution that I was able to use (because I am rendering to an intermediate screen buffer) is to allocate one more pixel then I need.  Change this one line, to have a + 1.

   int index  = ( x + y * screen_width ) + 1;

Every time I reference, the screen buffer, I first + 1 to the pointer to skip over the [0,0] pixel.  So, we treat the screen buffer as starting from [1,0], making the first pixel invisible and ofscreen.  Thus in effect, our masking operation ensures that it uses pixel (-1,0) for all off screen writes, which is legal memory now, but not visible.  The downside here is that a +1 of the screen buffer everywhere is still a bit ugly however.

Anyway, that’s my hopefully interesting take on the timeless plot(x,y) function…

A long time has passed since my last post here, largely because I was hired by a great software company, and I’m having a great time there!  I would like to point out that due to the nature of my work, I am bound by an NDA, so everything I write here pertains to my own personal projects and not the company’s.  That said… while I have less free time then usual, I still have a huge drive to work on projects in that which I do still have.

I am currently working on some awesome things, which I want to get around to documenting, such as:

• Fast [quad / oc] tree ray casting using only bit shifts, for a voxel renderer, and a Fez clone.
• Writing an embeddable Java Virtual machine as a scripting language for my game.
• Refactoring and extending Fake86 emulator, to aid in writing boot loader games for the PC (largely through adding a debugger).

On a different subject, I finally got some time to make UI mockups for some programs I want to write.  The first picture shows an 8 bit chip tune composer, which should map nicely to my sound engine I have already programmed.  My goal here was to take my love of Albeton Live and push that into a 320×240 resolution for a fixed sound system.  I have never likes the text interfaces of other 8bit ‘tracker’ music programs.

Incidentally here is a screenshot of the sound core, showing 4 waveforms: SAW, PULSE, SIN, and TRIANGLE.  An interesting feature is that each channel has independent bit crushing, which can be seen in channel 3, and 4.  Channel 5 is the LFO or vibrato oscillator, and channel 6 shows the white noise source.

This is an incomplete mockup for a pixel editor I want to create.  I wanted to take my workflow from Photoshop and streamline it into a 320×240 program, with only the feature I use.

An interesting idea is to release both programs bundled together as a retro game makers app pack.  The sound engine for the chip tune composer could be released as a stand alone library, making it easy to plug into any games.

Also I found this a very interesting to read.  Someone has written up an explanation of a AI following and path planning system for platform games.  This is something I have often thought about myself, and feel it would be nice to experiment with in future.  Check it out:

http://www.ludumdare.com/compo/2013/11/24/path-planning-ai-in-platformer-games-a-layered-approach/