I've spent some time reviewing potential libraries for converting SVG to OpenGL, and have decided that while feasible it probably isn't a good idea to spend time on that feature for my present project. I figure it would take me at least a week to get a hack job done on one of those libraries, but even then there's a whole bunch of issues with SVG compatibility that would be painful to deal with. I reckon I'd need to spend about three weeks dedicated to getting that feature working, and that's too long for a project whose intended purpose is a stepping stone back into development. So for this game, I'll only use SVG as a raw file format for editing and use PNG within the actual game.
However from what I've seen, I'm pretty pysched about the possibilites for using SVG or some close derivative as a file format for game art. Once this project is over I'll put this feature on my "to do" list for the next game engine.
In case any of you are interested in SVG, I'll give a basic overview of my brief experimentation with the free libraries out there. While there are a few packages or image tools out there that are reasonable, unfortunately many of them use the GPL or an equivalent which is annoying if you aren't dedicated to releasing your game open-source (personally, I'd prefer the option to release my game under my own licence terms). That rules out the code behind Inkscape (GPL), Amanith (QPL), and Xara (GPL). If you are happy with releasing under those licence terms though you might want to give them a go.
There seems to be a library out there called OpenVG which aims to release a library for vector graphics for mobile phones, but as of this time I can't seem to find a decent version of the library. This might be useful in the future, but I cannot tell at this time.
The three potential libraries left that I found are ImageMagick, Cairo, and Anti-Grain. I haven't spend much time looking at ImageMagick as it's a large image conversion tool and requires a number of extra libraries to get SVG converison working. However it is released under a very liberal licence which allows you to take the few components you need and statically link them within your game.
Cairo is a vector graphics library that as far as I know is being used by Mozilla and several Linux distributations as part of their software. It also has potential for hardware-acceleration provided though another package called glitz. One slight downside when compared to the other two libraries though is it uses the LGPL; this isn't really that much of a problem as you can just dynamically link to the library, but it does mean it becomes more of an issue if you wish to change any of the code or if you wish to only distribute the part of the library you need. As of now I haven't looked that much as the Cairo library because I couldn't get it to compile straight-away; Cairo seems to assume that you are working on a Linux system within its makefile and I'll have to build it manually.
However, I have had a look at the third library, Anti-Grain, and I like what I've seen so far. Anti-Grain is a vector graphics library developed mainly by a hobbyist (Maxim Shemanarev) over the course of the last several years. From what I saw in tests the output looks pretty spiffy; it's used by a lot of people for rendering high quality map images and for scientific diagram tools. It comes with a very nice liberal licence; the author intends for users to just incorporate whatever functions they need directly into their applications. I could also get the code to compile without any major hassles, which is a big plus for me (most of these libraries expect you to jump through all kinds of hoops just to get them to compile). It's also totally software based; which some people describe as a potential problem; however from what I saw in my tests it seemed to be pretty darn fast:
This image shows the provided Anti-Grain SVG viewer with my "Red Army Test"; 256 SVG squirrel soldiers. The viewer managed to display this at what I'd approximate to be 5 FPS. That might seem a bit slow, and it would be if you were planning on using the algorithms fo real time display. However for reading SVG files to hardware textures it seems plenty fast enough to me. AS a comparison, Inkscape was really choking when I made that particular image; it would take several seconds to refresh the screen.
The downside with Anti-Grain is the author is much more of an algorithms person than an API; the library itself is designed to be a fast, low-level set of tools that people can use to build their own libraries, not as a library itself. Thus it will take a bit of work to write the conversion code from whatever formats you want it to do. However, from my brief peek into the code it seems pretty clean and well-written (maybe a bit sparse on the comments, but all libraries seem to suffer from that), and there's a fair few application examples to learn from. If all else fails the licences of ImageMagick and Anti-Grain should be compatible so some sort of hybridation between the two might be possible.
From what I've seen so far, I'd like to spend a few weeks later on seeing what I can do with games, SVG and Anti-Grain. However that will wait until after I've got my present project finished so I have a better idea of what I want it to do. I've got enough to learn right now on my improved basic engine structure that I'm presently coding.
New Game Hero Concept
While my initial intention was to have a penguin as the hero of Project Penguin (makes sense!), I've now decided to let the little guy sit this one out. This breaks one of the rules I set myself at the project state (rule 1 in fact: the game will include a penguin as the hero), which I feel a bit guilty about. What is weird is that my present game design work still work with a penguin hero; pretty much all the game is about is an avatar sliding around on ice. That works well with a penguin, right?
The problem I have is with the "feel" of the game. My penguin is now a defined character in my mind. I've got loads of pencil sketches of him, and have a fair idea of his personality. And frankly the penguin is too much of a bad-ass to star in a game about sliding around in an ice maze.
For my present view of Project Penguin, I'd like the game to be a carefree light-hearted family fun type of game, rather than cartoonish wanton slaughter. So Mr. Penguin will have to chill for a bit while until I make a game action packed enough for him to make his appearance.
Thus I needed a new avatar and look for the new game. Given I was getting a bit sick of the basic engine coding I took some time out to design a new character for the new Project Penguin. I've decided to go with the cutesy big headed kid approach, given that I'm pretty drawn to that kind of art style. Here's my first version; I think it looks pretty good, although I might have to make a few changes for the in-game sprite.
I'm still a bit undecided on the choice of main colour, but I think mustard yellow is the best I've tried so far. Given the ice will be light blue, it seems best to use a complimentary colour for the main theme of the character, which suggests to me yellow, green or red. The light red "Santa" look is pretty good, but looks way too Christmassy. The green "Link" look... looks way too much like Link. But I think the yellow and red colours combined with the ice blue go fairly well.
Tomorrow I'll spend a bit more time hacking through the basic classes of the improved engine. I'd like to get up to actual screen shots by next weekend at the latest, even if they're just of a mouse cursor on a black screen, but I want to get all the base functionality down first before I get to that.
I'd also like to try a bit more Dwarf Fortress, but that might have to wait...