Last night I was experimenting some with a different cloud style at the behest of my girlfriend. I’m not really sure which I like best at the moment, but I figured I’d go ahead and post a screenshot and see if anyone had any thoughts.
These clouds look more "cloud-like" certainly, but do they fit with the miminalistic style of the other elements?
Tonight after it cools off some, I’m going to start restructuring the code to be quite a bit cleaner. Currently I have only built a few classes, namely the ShivaVG related classes, and a set of other game related classes.
The ShivaVG classes:
The game classes (so far not many):
I think the first thing I need to work on is writing a manager for drawable objects that will handle loading and setting up all of the VGObjects. The reason I want to go this route is that I know at some point it will get too expensive to draw the static objects using vgDrawPath each frame. Instead I’m going to set up the VGObject class to have a flag defining whether the object is static or not. If it’s not static, it will be handled like it is currently – no change. If it is static, however, I’m going to render it and read it back into a VGImage (which in C# is really just an IntPtr) which will be used for subsequent rendering.
Another issue requiring me to set up this manager class is gradients and how Inkscape saves them in the SVG file. When you set up a gradient in Inkscape, it creates a child element under the svg:defs element, and the child elements of that element are the stops with the information needed to define the gradient to ShivaVG. The actual path that uses the gradient merely holds its ID. So to get gradient parsing working I’m going to have to parse all the gradient definitions into a list of some sort of gradient structure, then when parsing path attributes, request-by-ID the gradient defined in the style attribute of the paths.
I’m not sure how this will all be laid out or if I may end up with multiple managers (probably), but I know I also need other manager-level functionality for keeping tracking of drawing and other things.
I am really enjoying developing the SVG Ninja Game here, and I got to thinking about my process. Right now I really don’t have a concrete plan as to what bits of the project I’ll immediately be working next, and I think this is a benefit rather than a hindrance.
What brought this minor realization to the fore for me was just now while I had decided to do some new art for my level, namely the clouds. As I was drawing the clouds in Inkscape, I went to set them up how I had them before and realize, oops, I need to implement cap styles for path stroking for these to render correctly. I really like that I can implement little chunks of functionality driven by what I’m doing on the art side.
I think most of my enjoyment of this particular project is driven by the fact that I’m the closed loop for the whole pipeline. I do the art, I see it in game, I do more art, I write more code to display that new art and so forth.
I meant to post this about an hour ago, but I ran into a minor roadblock. After setting up the parsing for the stroke-cap parameter of the style attribute, and setting up the set call in my draw function, my little clouds still had square ends!
So first thing I do is go and search around to see if anyone else is having the same issue with OpenVG or ShivaVG in particular. No luck there…. I poke around the ShivaVG code some, and then the test suites. I compile and run the dash test and I’m looking at the code…I noticed it calls draw twice, once for fill and once for stroke, which is a bit odd. Eventually after going back and forth a few times I thought, “Well, it seems like it’s always setting the join style with the cap style…hmm.” I try that and voilà!
So, remember folks, if you’re setting up stroke cap styles, you have to set the join style as well!
And here’s the result of my process, this time:
Now with clouds, which are just straight paths stroked with the "round" end cap style. Rendered at 6xAA.
I sat down today with the project in order to get some rudiments of movement working, and quickly ran into an issue. Namely, in the old version of the project in C++, I wasn’t directly drawing the ShivaVG paths. Instead I was drawing to a pixel buffer which was then used as the texture for quads. This enabled me to have an absolute position in the scene for any given object, and movement was a simple matter of translating the quad around. That made sense in the old project because it was the easiest way to draw the objects in the first place. Not so in the new project.
So, what did I do you may ask? Well, after much mucking about in the OpenVG spec and other searching around, I became a bit stumped and was almost ready to rewrite my code to do things the old way. However, with a bit of rethinking, I realized that if I change all the path objects to use relative coordinates (a setting which I had disabled in Inkscape because I was getting lazy earlier when writing the parsing code, but which is no longer an issue after I refactored it), I can simply update the initial move to command in the path, and clear and reinitialize the path data, which will give me a simple path-specific translation. Wonderful!
Amusingly enough, if you do this using paths that are forced to use only absolute commands, you get a nice ‘Scream‘-like effect:
The rects are drawn differently, so they don't melt.
I also figured out how to enable anti-aliasing in SFML, which makes things look a lot nicer. Unfortunately, my development PC is a little low-end in the graphics department so it performs rather badly at 6xAA.
Don’t have much time to expand upon this, so I’ll let the screen cap do the talking.
Implemented a VGRect class that can handle rounded or regular rectangles.
Ninja, now with 100% more Style (attribute)!
I decided to burn some midnight oil and get the style parsing working properly, since SVGLib doesn’t ever fill in the attributes. Currently things like miter and join styles aren’t supported and it will break if you have stroke-width specified in pixels (with “px” at the end). However, for my purposes it works great! Here’s a screenshot of everyone’s favorite (well my favorite at least) ninja!
In order to brush up on my C# skills I decided to go ahead and revive my on and off again project that I’ve written about here previously. Unfortunately all the progress I had made before was lost in a harddrive failure (well…several failures of ill timing) along with my art resources. Since I’m starting over anyway I figured I might as well write it in C# instead of C++ to save myself some time.
I also went ahead and recreated my artwork in Inkscape based on the old screenshots I had uploaded here for my previous posts. I’m fairly happy with the results thus far:
SVG Ninja, right, recreated from the old bitmap on the left.
As can be seen I have recreated the old look fairly well, with some minor modifications to the shape of most of the body parts save the head. The eye I think is quite a bit better in this version, as it seems a bit more expressive.
I might end up changing the colors and possibly the shape of the legs some down the road. I mainly wanted to knock out a quick and dirty SVG version of the original art.
I also did a fair amount of digging earlier today in regards to OpenVG implementations, and ran across a very interesting project called KompazzVG, which is an OpenVG implementation based on Anti-Grain Geometry. You’ll want to check out KompazzVG’s SVN.
Of particular interest to me is some code in the test_tiger_ri (render instance? I haven’t looked at it closely) sample program which loads in a giant array of SVG path commands from a .c file and converts them to OpenVG paths. It’s significantly cleaner than the solution I was using in my old project and it seems a great jumping off point for this second attempt.
More to come on the SVG project soon!
This post is titled “Life and…” because I also wanted to mention that I’ve recently moved back to Southern California and it’s great! I’m looking for a new job down here, so if anyone knows of anything, don’t hesitate to contact me.
Edit: This was initially intended to be just one post, but after detailing some history on the project, it has grown quite long. I’m going to be splitting it into two or more parts for the sake of organization and sanity.
Some preface to this to outline the history of this project over the past couple of years. So about 2-3 years ago now, after playing this excellent flash game which has finally gained the recognition it deserves, I started designing some programmer art in the form of a very small pixelated ninja as well as some samurai enemies. The idea was to create a game in homage to N, but to focus on very different elements (combat, stealth), including a “ninja grappling hook/ninja rope” with mechanics lifted from Worms.
As noted above, initially I started out drawing very small bitmap images of my main character and some enemies. The idea was to go ahead and build a simple 2D parallax scroller. This was going all well and good, and I had assembled frames for probably 5-10 animations. At this point, I was starting to get burnt out drawing sprites, which I’ve always found to be rather ineffective at capturing motion in two dimensions. The project got moved to the back burner for a while, and I basically lost interest for the next six months.
Eventually, I was playing around with Inkscape and managed to build a much nicer, vector based ninja character. Initially the idea was to simply replace my older, much lower resolution bitmaps with the newer, differently styled character in the simple parallax scroller engine. Soon, however, I became dissatisified with this idea for the same reasons that sprite sheets have always left a bad taste in my mouth.
So I decided then that, hell, why not just rasterize the loaded SVG file and animate it with a simple bones system. I outlined some basic guidelines for the project.
These guidelines turned out to be the cause of the project’s very long term back-burnering. I evaluated dozens of libraries, code snippets and projects over the course of the two years between me realizing these requirements rather limited me and the present.
Initially, I settled on Cairo, and actually got a fairly workable prototype, that allowed me to render my level and character, and I even got movement and basic collision working. However, I quickly found out that Cairo’s rasterization process is horrendously slow, allowing me to rasterize and render only 1-2 very very simple (talking like… move to, line to) paths per frame. Very soon after that, I found out that Cairo tries very hard to disallow the user of the library from accessing any internal representation of the path data. After fiddling with Cairo for a couple of months, I ditched it entirely and the project went back to the dreaded back burner.
Fast forward a year or so, and so began my attempts to use QT4 for rasterization and rendering. First thing to check: Is it fast enough? QT4 gets the green on this, it can rasterize and render hundreds of paths per frame. Perfect! Second thing to check: Can I access the path data? Hellfuckno. QT4 tries very very very hard to abstract almost every detail of what really goes on from the user level library programmer. Third but relatively minor issue: licensing. I would be unable to sell the game even if I completed, without purchasing a QT license. A good friend that owns one offered to publish the game for me if I ended up using QT. Great, I thought, now I just have to change the QT lib so I can get at the data I need.
Two weeks or so of fiddling for an hour at a time, and I hit the roadblock for QT, which was that my changes to the lib were essentially returning garbage data. The guys at Trolltech support were AWESOME and given that I wasn’t even a license holder, and I was poking around in the lib itself, I’m suprised they helped me so much. Infinite kudos to Trolltech guys, you are awesome. Alas, project again goes on the back burner after Trolltech is stumped by the odd behavior as well.
Fast forward again some, I’d found a great little vector rendering lib called ShivaVG based on Khronos Group’s OpenVG. I checked my first two Important Factors in Evaluating a Vector Rendering Library for a Game Project, and determined that 1) Shiva was indeed fast enough, rendering the rather complex (and famous) tiger.svg example at a decent 70ish FPS (maybe more, might have had v-sync). The second factor, access to the underlying path data, was a no brainer, because ShivaVG contains absolutely no loading functionality. The tiger’s head was comprised entirely of arrays in a header specifically for it.
Great! I thought, now all I have to do is find a good library to load SVG files. So I poke around, and nothing really surfaces, so I dig deeper and basically come to find out that a good lightweight SVG loading library written in C/C++ actually doesn’t really exist at all. There are some standalone libs written in Java, Python, C# etc., but none in C/C++.
Project, back burner, back burner, project. You two should get comfortable, it’s going to be long wait.
Tune in next time for part two, in which I detail the current status of the project, as well as the nifty things I’ve built to support it.
Here is the programmer art ninja character in his semi-final state (he may get more detail/patterns at some point):
Neuron Spew 