This is the second part to the history of the SVG Game Engine project that I’ve been working on off and on for the past two years. If you haven’t yet, read the first post!
The amount of times I’ve shuffled this project between the back and front burners is rather schizophrenic, but it has a certain otherworldly appeal to me for some reason. Every roadblock I’ve hit has essentially caused me to lose interest for not insignificant amounts of time. Subsequently, I’ll be thinking of a project to work on, and instead of starting something new, and never finishing that either, I usually pull out the SVG project and try to get the basics working, while holding true to my Important Factors in Evaluating a Vector Rendering Library for a Game Project (see part one for what this ridiculously long, underlined phrase actually means).
Recently, probably near the beginning of December, I wrote a fast and dirty implementation of an SVG parser in TinyXML++. To keep it simple (compared to the SVG Spec. that is!), I implemented only functionality to read in path elements, as well as their attributes. After I worked that out, I merged that code with a simple example SDL/OpenGL project. Next, I added in functionality for drawing the paths using ShivaVG (or AmanithVG, more on this later).
Relatively quickly I had a working prototype that could render out my ninja character. It was, however, becoming a nightmare to manage all the libraries that needed to be built in order to build the project. At the current writing, it requires at minimum, TinyXML++, SDL, and ShivaVG/AmanithVG (no source for Amanith though). Now, this isn’t all that many libraries, but I was soon to implement Box2D, and further libs would only compound the problem.
What to do? Well, luckily from my exposure to the Torque Game Engine, I had access to the wonderfully useful Torque Project Generator. The idea is that you set up your source files, and the source files or binaries for your libraries, and the Project Generator will generate the necessary project and solution files for Visual Studio (or XCode equivalent, I guess, but I don’t do Mac development, so no idea how that portion of it works).
Thus I decided to go ahead and port the Project Generator to my SVG project in order to better organize things in future. The generator also has the benefit of being able to include/exclude only certain “modules” in your engine/project’s source directory (a module being a sub directory with a certain subsystem of your engine/project). This would be ideal for things like ShivaVG vs. AmanithVG specific code.
The next post I make will detail porting the Torque Project Generator to a generic, non-Torque project. Until then, here are some screenshots of the latest from the SVG Game Engine Project (from here on, the “vector game project” or “vector project”).
First successful output in game:
Don’t forget to enable the stencil buffer in SDL or OpenGL before rendering with OpenVG!