The SVG Game Engine Project – History / Part 2

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!


6 responses to “The SVG Game Engine Project – History / Part 2

  1. Congratulations for all the works !
    Is it possible to have an access to the way you load svg file and then inject them in ShivaVG ? This could be helpful to build a quick way to draw GUI in OpenGL

  2. Thanks for writing up your process, saves having to even look at Cairo and the like. Depending on how far you have got with your Project Generator, you may want to check out a similar build tool called CMake.

  3. @Nathan, well the reason I’m using the project generator from Torque, and not something like CMake, is that I’m already familiar with it from my day job, and it’s all already finished and whatnot. It’s just a matter of making it work with my project rather than Torque.

    @JP, I would gladly release the code I use to read in the SVG, but it’s by no means a general solution. Currently, it only reads in path elements, and path elements inside group elements. For that reason, it would be fairly useless for the general purpose SVG loading.

  4. I just discovered this project, and am impressed. My pet project has been to create a game engine that focuses on SVG graphics and procedurally generated graphics for about two years now.

    My focus has been loading the SVGs, and not finding a library to render them at a decent framerate, however. I ended up writing my own C++ SVG parsing library, basing it on librsvg but with structural changes and optimizations along the way.

    I am still using Cairo for rendering, but ShiraVG looks very interesting — I am considering adding a ShiraVG renderer to my system.

    Thanks for your posts, I look forward to updates.

    • @Sebastien, Avenger, sorry guys I hadn’t been checking this blog or I’d have approved your comments, WordPress erroneously tagged them as spam. Thanks for the kind words and suggestions.

      @Sebastien, I never looked into SWF simply because it seemed overly cumbersome to me. Also, the idea for the project arose when I started fiddling in Inkscape, so it seemed a natural progression to have the simple workflow of Inkscape straight into the game engine. The GameSWF library does certainly look interesting. One requirement to make this work though is that rasterization be quite fast so that I can do things such as modifying the path data on the fly at interactive frame rates.

      @Avenger, I was very disappointed by Cairo, because other than the fact that it’s rasterization is terribly slow for my purposes, it is very robust. I’m currently working on reviving the project (new post to come soon, I figured I’d reply to these comments first though) and would love to share some code with you and vice versa if you’re up for it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s