Manta-X: Toe in the code

Last post I talked about the overall folder and asset composition of a very old game codebase I found of mine (from 2004).

It looks like when I got it compiling back in 2014, I’d ported it to Visual Studio 2013, however the IDE is now crashing so I will use 2012 for now.

After more time than it should have taken, I configured cloc to skip the deps and dist folders, we have the following counts:

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C++                             54           1396            623           3742
C/C++ Header                    70           1077            209           2121
-------------------------------------------------------------------------------
SUM:                           124           2473            832           5863
-------------------------------------------------------------------------------

In short, just under 6000 lines of code excluding comments and whitespace. We really don’t have much here - much less than I expected to find. My memory is that this project was much bigger than it actually is, perhaps it’s because this is likley a “reboot” of an even older version that’s lost in time.

Time to dig in and see what we find.

Coding style

The coding style I used in this project is represented fairly well by FileReader.h

#ifndef __EVOLUTIONALCOUK_MXFILEREADER_H__
#define __EVOLUTIONALCOUK_MXFILEREADER_H__

#include "StdHeaders.h"

#include <fstream>

namespace MantaX
{
    class FileReader : public IMMO
    {
    public:
        FileReader();
        virtual ~FileReader();

        int openFile(const char *filename);
        int closeFile();
        
        int seekFile(unsigned int pos);
        unsigned int tellFile();

        unsigned int fileLen();
        
        virtual int readFile(char *buf, unsigned int len);
        
    private:
        std::ifstream	m_fin;
    };
}

#endif

Let’s break it down:

Not using #pragma once (this was 2004, I guess)
StdHeaders.h is a huge catch-all header file with lots of stuff in it
Everything is in the MantaX root namespace
Class names are PascalCase (thankfully, I wasn’t using the C-prefix that was popular back then)
IMMO - more on this later…
Method names are pascalCase, parameters are pascalCase
I obviously wasn’t aware of const-correctness
Class member variables have the m_ prefix.
Public / Protected / Private ordering
Using standard file handling (I wonder why there’s a dependency on Physics FS?)

So the codebase is looking like it has a Java-like style, not terrible but obviously a few issues.

One of the biggest problems I see straight off is the split of src and include. This isn’t down a public/private boundary, but just a straight up “headers go in the include folder and source goes in the src folder”. This is a pain in the ass to work with and if I were to do anything with this code for real, I’d defintely go about chucking it all under a single src folder.

Enginuity

Anyone who visited GameDev.net back in 2004 would remember Richard Fine’s (in)famous Enginuity series. This codebase has a bunch of stuff inspired by that series in here.

We have:

IMMO / MMOPointer - a basic refcounted smartpointer/memory manager system
Singleton - The dreaded singleton - let’s hope it’s not everywhere…
Profiler - I had performance profiling in a 6000 loc codebase. Ok then…

Curiously, I wasn’t using the “task” system or anything else from Enginuity at this point.

Likely I’ll find more concepts from this series when I go digging around further.

Maths

There’s a handcrafted Vertex2d, Vertex3d and Matrix4x4 class there. There’s some other single structures like Quad sitting around. Just enough basic maths to render 3d “sprites” I guess :)

There’s also some stuff like Triangle and Mesh and Model which looks like it’ll be awful :)

Containers

Something of an oddity is that I have a few container classes that basically wrap the standard containers. I have Map which is a thin wrapper over std::map and then HashMap, which looks like it is a std::map<int, T> where items are inserted with string keys that go through a crude hash to calculate the key. I’ll have to dig around to see where this is used.

The HashMap code has methods like this:

void insert( std::string key, T data);
T find( std::string key );

String copying, anyone? Ironic as this is likely a performance optimization. I guess that profiling system wasn’t used much :)

Reflection

One strange thing I found in the code from this cursory glance in the files is a reference to DTIClass and Property/PropertySet. It’s very likely I was considering reflection here, possibly as a way of serializing the Xml? Ah, this is where one of the uses of HashMap comes in. I’ve been very interested in reflection and other such things at runtime for a long time, so it’s not surprising that an old codebase from 2004 features some of it.

Wrap Up

This quick look over the code is already revealing. There is a lot of stuff that’s low level or not particularly focussed on the act of making the game. Perhaps this is because I’ve always been more interested in engines and systems programming and not the aspect of visuals or gameplay.

When I first found this codebase, I was wondering if there was anything I could use or even perhaps if I could pick up where I left off. That’s already looking doubtful, but I’ll keep looking over this code.

In the next post, I’ll take a look at the entity system.

Cheers!

Oli's old stuff

Tinkering with retro and electronics

Manta-X Code