Cross-Post: Project Broadside Update

Work has been going along steadily on my main development project, Project Broadside. A team-based multiplayer FPS set in the skies, Broadside pits two teams against eachother in physics based airship combat. Captain the ship while your team mans the cannons, or fight it out as a crewman against the enemy team using pistol, sword or cannon. The first team to destroy the enemy ship and send it plummeting from the heavens wins! More info about Broadside here.

And now, the part everyone always waits for: art!

The final side-view Imperial Crew Pistol concept art.

The final pistol model changed quite a bit from this initial concept.

Final Imperial Crew Pistol Model

As you can see, the evolution of the pistol from concept to model introduced a lot of design changes. The original design was much less traditional.

For more development art shots of Broadside, check here.

SVG Game Engine – Process

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!

Now with clouds, which are just straight paths stroked with the "round" end cap style. Rendered at 6xAA.

SVG Game Engine – Bounds and Picking

Tonight I spent some time setting up the preliminary classes I’ll need for a

Ninja drawn with AA in Release mode.

Here's a shot of just the ninja rendered with 6xAA in the Release build.

skeletal animation system.  It’s all quite straight forward stuff, but just as a reference I have been using this excellent tutorial.

In the same vein, I also stumbled across some C# code for various types of 2D two-bone inverse kinematics solvers.  The 2D IK problem is simple enough for two bones that one can solve it analytically and come up with a pretty fast solution (certainly faster than cyclic coordinate descent, which is pretty fast).  I had planned on implementing either CCD or trying to do a Jacobian Transpose IK, but I think this should be sufficient for my needs, and the license is very liberal (free to use for commercial, just retain the license and a note attributing the author – nice).

Anyway, after setting up the classes for the skeletal animation and getting those compiling okay, I decided to go ahead and start dealing with the picking code.  Of course, this led to using the ShivaVG functions for getting the bounds of a path.  After setting it all up I was getting some odd results, so I eventually futzed around with the bounds calculation and eventually got it all sorted out.

Ninja with Bounds Debug Draw On

Can toggle debug drawing of bounds on and off with left control.

Subtract the amount that I am translating the ShivaVG c

ontext from the X and Y coords of the mouse click.

SVG Game Engine – Movement is Tricky

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:

Ninja Melt

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.

SVG Game Engine – With Style!

SVG Game Engine now parses style attributes!

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!

SVG Game Engine Project – Now in C#

Earlier today I did the first successful test of the C# wrapper for ShivaVG.  The rest of the day was spent rewriting the code to be flexible enough to load in a file with multiple paths and correctly handle all the different SVG

Initial output of SVG loading in C#

The first output of the SVG loader rendering with ShivaVG in C# using SFML.

command types.  I briefly got stumped earlier when I was expecting to see a green test path and was instead getting blank-white screen (white was my canvas clear color at the time) only to find out that the SVG loading library I was using has member variables for the stroke and fill colors on the SvgPath class but doesn’t actually fill them in correctly, instead always defaulting them to white!

Once I figured that out I was having some other problems, namely that ShivaVG/OpenVG doesn’t appear to support implicit SVG commands (that is, when a command is repeated immediately after one of the same type, it omits the command character).  I can write a workaround in my code, but luckily Inkscape has an option to force duplicate commands.

So more work to do, namely setting up the parsing of the style attribute from paths, which will allow me to get the rendering of my drawings to display correctly, instead of the not-so-attractive picture above.  I also need to rewrite the initial element parsing code, because right now there are definitely cases where it will miss elements and end up not rendering anything (it doesn’t traverse the tree correctly at the moment, it just looks under the root element for any path elements that are siblings of the first element).