Squirtle 0.2 released

Martin on 2008/08/28 13:37 of Super Effective 7

Version 0.2 of our Pyglet SVG mini-library, Squirtle has been released.

Changes include a new tesselator (with holes!) and a few bugfixes. Thanks to everyone who gave feedback and bug reports. As always, comments, bug reports, etc, welcome.

richard: I know this is quite a long way after the library deadline, but will people be able to use Squirtle 0.2 this Pyweek, given that the API hasn't changed since the initial release?

(log in to comment)

Comments

pymike on 2008/08/28 14:16:

Yaaaaaaaaay! (seriously I'm psyched again :-D) I drew a new SVG ship today and it loads fine. (I stuck to lines. No circles like in the last one) Were you able to fix the old one, though?

richard: I started using it yesterday and I'm already easily making a game with it :-) Shouldn't be hard at all for people to pick this up and use it.

pymike on 2008/08/28 14:34:

Line widths don't work. Maybe you could add that for squirtle 0.3?...

Martin on 2008/08/28 14:43:

Yes, your old ship works (although the radial gradient on the cockpit doesn't). Line widths are certainly under consideration as something to add, as is getting gradients to not suck. Can't make any guarantees as to a timeline though.

richard on 2008/08/29 01:58:

Bugfix releases are always welcome even this close to the comp :)

Treeform on 2008/08/29 04:11:

Is there a way to get around the gluNewTess and gluTessCallback? I would like to implement those functions in python.

Martin on 2008/08/29 12:34:

Windows users (and anyone planning on packaging Squirtle with a game) should note that there's a new release, 0.2.1, which fixes a crash problem which was reported on Windows systems. My bad for insufficient cross-platform testing. Again, available from the Super Effective website.

Treeform: It would certainly be possible to rewrite the GLU tesselator in Python. If you're interested in doing so, the SGI sample implementation is probably a good reference point. However, it's likely to be very slow. Is there a particular reason why you're averse to the GLU tesselator?

Treeform on 2008/08/29 21:41:

yeah sense i want to use this in panda3d. Panda3d does not provide access to GLU because it can also run on DirectX 7,8 or 9. So i have to rewrite all the OpenGL calls to panda3d calls which are quite different because there is no display lists or glVertex - but just vertex buffers.

sjbrown on 2008/08/30 23:38:

Martin, I found & fixed a bug. You taking patches?

adam on 2008/08/31 07:41:

I see you've already found this one, but for the benefit of everyone else: bugs@supereffective.org.

richard on 2009/08/27 01:53:

Hey Martin, just wondering whether you're interested in or have any thoughts about:
  1. supporting multiple layers (to be drawn independently or not at all), and
  2. ID-based access to paths.
These are things I think I'll need in my pyweek'ing next week...

Martin on 2009/08/27 10:05:

I've thought about these things. The key problem is that allowing access to subsets of the SVG makes it more difficult to draw everything at once in a speedy fashion. There's a trade-off here, and I plumped for the side of speed rather than fancy access.
 
That said, others have suggested the things you're asking for in the past. It wouldn't be completely impossible to rewrite things so that individual paths acted as vertex lists in a single batch, which could be indexed in a dictionary on the SVG object. However, then you run into the situation where every copy of an SVG requires its own copy of the geometry, which can add up to quite a lot of data.
 
As for multiple layers, I assume you're talking about groups, which I believe newer versions of Inkscape use for a layer system. Again, it's possible, but it would require subdividing the SVG more, which slows things down.
 
So, to answer your question, yes, I'm interested, but I'm not sure what exactly the best way to proceed would be, or whether it's something I want for Squirtle. However, feel free to bug me with any questions you have - I'd like to see this working as much as you would.

richard on 2009/08/27 22:21:

For my use-case the layers would be separate SVG objects rendered (or not) entirely independently. There would be no call for rendering the whole picture, so I believe there would be no performance issue. Loading such files to obtain multiple SVG objects would use a different API call to the current "load a file as a single SVG object" usage.

I'll have to look into the retention of path information. It may be that I can come up with an elegant method of retaining only some path information - perhaps by layer.

I'd not got around to looking into the actual SVG mechanism for inkscape's layers yet. I guess I'll be doing so today :)

Martin on 2009/08/27 22:40:

I think that's a pretty odd use case, if you don't mind my saying so. It's an interesting idea, but probably not something I'd put in Squirtle. However, I would be open to modifying Squirtle so that unusual ideas like this are easier to do.

richard on 2009/08/28 00:00:

It's actually not that odd - it'll all make sense once you see it in action. Assuming I can get it working next week :)