On, Tue Jul 25, 2006, kschnee@xxxxxxxxxx wrote: > I was reading about "Scalable Vector Graphics" (SVG)
This would require either a new dependency to a SVG parser library or
Maybe you could use an external renderer, such as cairo (if it supports SVG) and operate on a binary filebuffer returned by it.
Can and has been done. The attached file was sent to me some time back (January 2006, in fact), and renders an SVG drawing into a PyGame surface.
Here's a bit more information, including author, licensing, and my test results:
Glad to hear it's working nicely. Just a quick thing - that version had a memory leak in it, so you probably don't want to use it much :-P This new version is slightly expanded upon but contains the same basic idea. I'm publishing my website in a couple of days. Will upload it there and include README, INSTALL, etc. Feel free to make a debian package or anything of the sort. I'm fine with LGPL - that's what it will be when I get round to labelling all the files as such.
I'm more than fine with you getting the code placed wherever you'd please really. It's okay in its current state, and the _pygamesvg.so library could be implemented by any SVG rendering library as long as they provide the methods, so it's modular in that aspect too, with no dependancy on any SVG rendering library. I'd be glad to participate in a discussion about having it included in pygame if I was CC'd the relevant thread.
Just good to hear it was of use really :-)
On 1/17/06, Terry Hancock <hancock@xxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 19 Dec 2005 22:22:50 +0000 Paul Giannaros > <ceruleanblaze@xxxxxxxxx> wrote: >> Attached is the library - simply run `python setup.py install` to >> install it, then run test.py to see if all went well. It requires >> libsvg-cairo, cairo, libsvg, and SDL. If the setup script has >> problems finding the headers simply tweak the directories it >> looks for them in. I'm intending to release the library publicly >> as LGPL, but feel free to have it under whatever license you >> would prefer. >> >> I made a couple of changes to the module in that there is a >> Python frontend that makes things nicer to use - optional >> function arguments, a couple of convenience functions, etc. The C >> module (_pygamesvg) has also gained a 'size' method, that will >> return the width and height the given SVG should be rendered at >> (this is required by pygamesvg.toSurface) >> >> Hope it all works well - works pretty good here :-) > > Finally had a chance to look at it. Built fine on Debian "Sarge" > with some "testing" packages ("Etch" by now, I guess), and > unofficial debs from Cairographics. I didn't have to install any > deps from source. > > Only one warning: _pygamesvg.c:141: warning: function declaration > isn't a prototype > > And it works! -- I brought up your SVG test file and one of my own. > > > The package is missing some stuff like "README", "INSTALL", and > "COPYING". No license is mentioned, I'm hoping you're okay with > LGPL or a compatible license (i.e. same as PyGame). I would be > happy to add this sort of stuff, I could probably even make a > Debian package and/or get it into the "Cheeseshop" for Python. > > Although I'm thinking very seriously about just depending on your > module in my own code, there was some interest in putting a patch > to do this directly into PyGame, which might be a greater benefit. > I could follow that up myself, but it's your work, so I don't want > to speak out of turn. > > I can't thank you enough for doing this! I can see it's not a > terribly long program, but I haven't programmed in C in at least > two years, so I'm very rusty. This was a really critical hump in > the game engine project I've been working on, because I wanted to > store cel animation data in SVG format, both to save space and to > guarantee scalability. You really removed a stumbling block for me.
Sadly, I did not get around to any of that packaging work, but I'd hate to see this package lost, as it is a very nice ability to have.
What this package allows you to do is to render the SVG "on the fly" in your running game.
One possible problem I've realized since then is that it's very likely that SVG rendering is pretty slow, so you might want to do this sort of thing at compile time (or else cache like crazy). And if you're going to do that, dependencies on things like Inkscape in your build process (which can be used on the command line, BTW) are less onerous.
But I haven't worked with it nearly enough to be able to say for certain if that's true.
Cheers, Terry
-- Terry Hancock (hancock@xxxxxxxxxxxxxxxxxxxx) Anansi Spaceworks http://www.AnansiSpaceworks.com
Attachment:
pygamesvg-0.1.1.tgz
Description: GNU Unix tar archive