C++ Sdl And Svg

[taltoris]

Hi, I'm a hobbyist/designer/coder in my other (real) life, and I've decided to try my hand at coding some sort of game. I decided to design a side-scroller using C++ (to easily apply physics to objects), SVG (so I can port to larger resolutions, maybe do some cool zooming effects w/o sacrificing quality), and SDL (because I found a tutorial online that covered some of the basics and decided to go from there).

I have an SVG sprite below.

All the body-parts are grouped and such, so I can (in theory) easily animate it by just rotating limbs about sockets. Here's my dilemma, I'm new to this, so I was wondering what's the best way to go about animating this thing?
I could just rotate multiple SVG files (limbs) in C++ and piece them together (maybe with the help of some animation xml file?). Obviously, this would be a lot of work.
Another option is that I could export a ton of SVG files, one for each frame of each animation, but this seems like it would be pretty memory intensive (duplicates of multiple layers, some of which are only partly seen). If I did that, I might as well just export every frame to a png or something.

What do you guys think, am I tackling this from the wrong angle? Or should I try one of the ideas above?

-Doug

 

[phrosty]

I would have a separate file (or heck, even embed it into the SVG, I think it is extensible) that defines how much each joint is rotated at 5ms keyframes.

SVG is normally too CPU intensive for games, but if you use a OpenVG renderer it will be hardware accelerated on the Pandora, so I guess it should be alright.

 

[taltoris]

I was just using the SDL_svg lib. I threw together a rudimentary program that just displays the sprite, moves it around, yada yada, and it seems pretty responsive on my laptop (2ghz core 1 duo, ubuntu 8.04). However, I don't know if the Pandora will be able to keep up after I throw a million more sprites, particles, and projectiles on an SDL surface. A 2D game should run at least 30-40fps at its worst.
If its going to seriously slow it down, then I guess I'll just have to use a sheet of Png's to get the job done, but I'd rather keep it as a vector that way it'll be flexible. (It'd be nice to be able to just change a small detail in one file and have it update the entire animation).

 

[Sphinxter]

Man sweet lookin' sprite. I would not render, I'd use the svg to generate png and animate those. The great thing you have there is the ability to generate png's of any size without loss for different platforms plus depending on your drawing program some real easy in between frame drawing by isolating the body parts. Best fps is consistent fps, the lowest is the max.

QUOTE

(It'd be nice to be able to just change a small detail in one file and have it update the entire animation).



<jaw drops>. That blew my mind.

I'm going to try svg for my next effort, seems really hard but you've sold me, worth it. Maybe we could script the export to png step and make that work.

 

[Svartalf]

I was just using the SDL_svg lib. I threw together a rudimentary program that just displays the sprite, moves it around, yada yada, and it seems pretty responsive on my laptop (2ghz core 1 duo, ubuntu 8.04). However, I don't know if the Pandora will be able to keep up after I throw a million more sprites, particles, and projectiles on an SDL surface. A 2D game should run at least 30-40fps at its worst.
If its going to seriously slow it down, then I guess I'll just have to use a sheet of Png's to get the job done, but I'd rather keep it as a vector that way it'll be flexible. (It'd be nice to be able to just change a small detail in one file and have it update the entire animation).


You may have to wait for the OpenVG or the ES 1.1 implementation to be exposed for SVG rendering acceleration on the SDL_svg lib to do this. The Pandora's probably going to be able to do what you're looking for, but you're a bit early yet on things. If you can get it pumping on a laptop, it should be decently there with the Pandora with rendering acceleration going on things.

 

[taltoris]

Maybe a better option is to use a mix. Say, SVG's for characters and animations, and Png's for backgrounds, projectiles, effects and the like. That way the machine won't get too bogged down rendering svg's but I can retain a lot of the functionality of the vector graphics.

Maybe we could script the export to png step and make that work.

This could be an option. If I stay committed to this project (who knows), then it might pay off to develop a program that can animate the svg and export to an appropriately sized set of pngs. This could actually take care of a lot of problems (like how do you horizontally flip an svg file anyway?). And if I decide to port to another platform, then I could just rerun the program at a higher set resolution for the new graphics.

I just don't want to spend too much time working on a sprite animator when I could be designing a game, ya' know. Maybe someone could collaborate with me on this.

 

[rlyeh]

You can make an hybrid system like the following:

Have all your data in SVG format.

On the program init, do all your rotations, animations, and squeezing stuff acording your game and your target platform. And render all your SVG graphics into PNG/Alpha-framebuffered frames in main memory according a given framerate.

Release the SVG data memory.

Run your game main loop using a classic 2D engine system that works with the on-the-fly generated flat frames.

Enjoy the speed up improvement .

 

[taltoris]

You can make an hybrid system like the following:

Have all your data in SVG format.

On the program init, do all your rotations, animations, and squeezing stuff acording your game and your target platform. And render all your SVG graphics into PNG/Alpha-framebuffered frames in main memory according a given framerate.

Release the SVG data memory.

Run your game main loop using a classic 2D engine system that works with the on-the-fly generated flat frames.

Enjoy the speed up improvement .

Maybe, but then you have to keep a lot of junk in memory, don't you? I could run into ram limitations...

It seems like an on-the-fly system would be faster than doing it all at the beginning of the program. But this is an interesting idea.

 

[sindbad]

You could mmap the image files, it usually saves you a lot of memory.

Anything should be fast enough for on-the-fly SVG rendering of a few tens-hundreds of sprites that don't change much.

 

[taltoris]

Here's how I think this is going to happen. SVG files can be manipulated by applying an "transform" attribute to a group tag.

Pretend.svg
CODE

<svg>
-----<g id="test1">
----------(...)
-----</g>
-----<g id="test2" transform="rotate(20)">
----------(...)
-----</g>
</svg>


Now, if I want to animate group "test1" to rotate, then I'll create some animation xml file.

Pretend_Animation.xml
CODE
<animation name="rotate" file="pretend.svg">
-----<keyframe frame="1">
----------< id="test1" transform="rotate(10)" />
-----</keyframe>
-----<keyframe frame="2">
----------<g id="test1" transform="rotate(20)" />
-----</keyframe>
-----<keyframe frame="36">
----------<g id="test1" transform="rotate(360)" />
-----</keyframe>
</animation>


Now the C++ file will load the text of the svg file into memory, apply the appropriate frame transformations specific to the frame specified by the animation file, and then load that svg text onto an sdl surface for that frame. Then, the main game loop would display whichever surface was needed for that frame. That way I don't need to use C++ to rotate the various bodyparts, it would just-reload a slightly different file, with the body parts already in the right position.

Here's another pic, these two files are the same, except for some transformations applied to the second one:

Since the animation file only references the original SVG, I could update the original and have the entire animation be changed as well.

 

[Sphinxter]

daaaamn, that's hot, found svgtest.c, no docs, linuxmotors is down, damn. Recommend an svg drawing program?

Wondering how you drawing is organized from that fragment. Not a total stranger to svg, I have a web service that spits out lollypop charts in it.

 

[.Gogeta§§J4BR.]

this looks very good! I'm looking forward to seeing more about this game =`]

 

[taltoris]

daaaamn, that's hot, found svgtest.c, no docs, linuxmotors is down, damn. Recommend an svg drawing program?

Wondering how you drawing is organized from that fragment. Not a total stranger to svg, I have a web service that spits out lollypop charts in it.

Inkscape is the one that usually gets mentioned, but to be honest I'm not a fan. If you can get your paws on Illustrator/Freehand/Corel-draw that's what I would recommend.

The above was made with Illustrator CS2 and a text editor for the transformations on my Mac.

The code is grouped kind of like this

CODE

<svg>
<g id="arm">

<g id="upper">
<path />
<path />
</g>

<g id="lower">
<path />

<g id="hand">
<path />
</g>

</g>

</g>
</svg>



That way if you add rotation to the "arm" layer, it'll rotate the entire thing. If you add rotation to the arm and more rotation to "lower", then it'll rotate the arm and bend it at the (pretend) elbow.

 

[multiplex]

Sounds about right. Mmm, vectors... Makes me want to run through Another World again.
The SVG specification has some support for animations on its own, but I'm not sure what libraries support it.

I wonder, won't this be terribly slow, though? Manipulating XML data, rendering SVG... Sounds both CPU and memory intensive. I wouldn't try it if I weren't sure the rendering could be hardware accelerated, which would leave some headspace for the XML parsing.
Maybe use a SVG library that lets you access the DOM, so you don't have to parse the document each frame.
If I were doing a vector based game, I'd use some kind of custom format, at least in memory. You'd lose a lot of nice effects, but I can't really imagine SVG being fast enough. Maybe I'm underestimating the hardware.

If you're just rotating, you'd get the same look by prerendering each group to a texture, and just position and rotate them, e.g. with OpenGL.

Or there's Flash, which is pretty efficient at this sort of thing, but I guess it won't be available for the Pandora for a while.

 

[taltoris]

Sounds about right. Mmm, vectors... Makes me want to run through Another World again.
The SVG specification has some support for animations on its own, but I'm not sure what libraries support it.
I wonder, won't this be terribly slow, though? Manipulating XML data, rendering SVG... Sounds both CPU and memory intensive. I wouldn't try it if I weren't sure the rendering could be hardware accelerated, which would leave some headspace for the XML parsing.

I looked at the SVG animation stuff, but I wanted a bit more modular approach with better control.

It probably will be slow, but after I render the SVG file to a surface then it becomes essentially bitmap. If I keep the surface around in memory, then it shouldn't be too bad.

I think.

But then again, I'm kinda new to this stuff, so it could be a little rocky. If I remember, then the GP32X had SVG support, but I never owned one so I know nothing about how well it worked or if it was accelerated. With this method, the only wait is going to be the "Loading..." bar at the beginning of each level, if that's how I decide to do it.

But thinking about it, maybe I'll give another chance to building a pre-rendering script that exports a bunch of pngs. However, this method would mean that there would be a lot of extra hard drive space required. So, I guess the question now is
Which is more evil: a large footprint, or longer loading bars for each level?

 

[Sphinxter]

Emerged inkscape, seems pretty stable.

 

[Game_over]

yeah Inkscape got extremely user friendly, all of my art started on Inkscape.

 

[torpor]

I've been using SVG to do this for about 8 years now .. What I do is create an SVG file with all layers properly labelled. I use Inkscape - and I always have the XML Editor open - always!! - and as I create the graphical object, I label everything properly.

I've written a C++ class that takes an SVG file and renders each object layer into its own PNG buffer.

For simple animations, I have multiple-frames of the animation encoded in the SVG simply as -independent layers- of the same object. In my case I've mostly been animating dials and knobs (I use it for user interface/panel design) and therefore for some controls, like a dial that has 4 states, I have "dial-a", "dial-b", "dial-c", "dial-d" states. (If your graphical objects file isn't too complex, another thing you can do is turn all the 'stateful' layers off - quite literally, set the hidden attribute - and then in between frames, modify the DOM directly to turn the hidden attribute off for the state that you wish to display. This is surprisingly usable.)

My C++ class takes these objects, creates a big hash table of them all, and renders the hierarchy of the objects properly in a list .. this means that for the 'statefully described' objects, such as "dial-*", my class knows to treat 'similarly named' classes as if they are states of the same object, graphically.

Since I order the objects in their layers according to the order I want them to render, I don't have to do much else - just blit the individual buffers per frame-update, and use the 'stateful' sub-lists to render data.

It works *very* well, and the advantage of being able to create entirely new interfaces, with brand new look, from Inkscape is tremendous. I can't recommend this technique enough for folks who are doing embedded systems control/GUI work, like I am ..

But .. for a game .. I think this technique would work within limits. It really would be good to have an animation library to glom onto SDL_svg or librsvg/libcairo, if possible. I toyed with the idea of doing an inline scene library between librsvg and libcairo along the way, I think there might even be something out there already, but its been about 2 years since I bothered with this - and my current libs work great for my synth panels and so on ..

So .. count me interested in your results! I too would like to be able to create an engine that gets its levels entirely from SVG data files themselves ..