[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] "Paths"
- To: pygame-users@xxxxxxxx
- Subject: Re: [pygame] "Paths"
- From: Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx>
- Date: Sat, 23 Jan 2010 20:14:19 -0800
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: pygame-users-outgoing@xxxxxxxx
- Delivered-to: pygame-users@xxxxxxxx
- Delivery-date: Sat, 23 Jan 2010 23:14:31 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=UcqbjiOPB9CkSJUnR/djWDpqRYvwwKvGRpXEPFf/J3g=; b=D7b6uhLoQ85Je/iAFoymV8Wp1+FvkS5PTVhmmZGjAQTkBVh4berlci3fp08qhjHKeS zHMcoms3W/jcWwSA0GDdsrHwDsDnXw57FANzhNInxXNq+Me4oozL2vVsRTSZ3nVpjeoA lb6DYVL8soYvwKi0Wh8XTwZp4t0m6ruzyTV7E=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=cvqA8cfYJ98P1QeRLEuzw9nl2SPPKj6fdN6z5X0onEP7qAr4ZT82M9zPLGI+zDEk45 Jtg00Up0s/E91w8N5jCwn1BvFprvaWFNquShsJgIGOGuTwGUIxuI5cqoOK6nZT/Nfg0a vDCoTzqrCvuDEkxgbBXT9Xb8D3HPD3rldHPIc=
- In-reply-to: <E7F1B4EE-F522-41C1-B26F-7A9115537F53@xxxxxxx>
- References: <E7F1B4EE-F522-41C1-B26F-7A9115537F53@xxxxxxx>
- Reply-to: pygame-users@xxxxxxxx
- Sender: owner-pygame-users@xxxxxxxx
In python, aggdraw (a wrapper of the very very awesome Anti-grain geometry) can do that path stuff:
and aggdraw can be used to make pygame surfaces.
...such apis can be very cool tools to have, but are usually too slow to use for drawing your whole scene on a frame-by-frame basis (they are best used for drawing stuff onto surfaces or textures, and then using the faster routines to work with the surfaces/textures). With software rendering systems (like pygame), you can actually get away with limited use of such apis, but on hardware-accelerated apis, such things usually demolish your frame rate quite quickly.
... speaking of which, using CoreGraphics specifically on iPhone often results in much less than satisfactory performance results. The best results are either programming with OpenGL ES, or using CoreAnimation Layers or UIViews. CoreGraphics can be used to create CoreAnimation layers to work with, but is a dog for drawing stuff to the screen directly.
... and it doesn't take a month to get stuff on the screen with OpenGL ES, you could get functional in a week, I'd say.
On Sat, Jan 23, 2010 at 4:16 PM, Bill Coderre <bcbc@xxxxxxx>
So I've been hacking Mac OS X's "Core Graphics" as a way of learning iPhone coding (gotta sharpen those job skills), and I was wondering if there's an extension to pygame or python somewhere that implements "path" based graphics.
In this model, you do stuff roughly like this:
1) Open a path in the current context (graphics device, in pygame, I guess that would be a surface)
2) Move to a starting point
3) repeatedly add lines, rectangles, arcs, and bezier curves to the path
4) Close the path (which implicitly adds a line back to the starting point)
5) Fill or stroke (or both) the path, to get graphics to appear.
If I wanted to write python and use Mac OS X's core graphics, there's a bridge already built. What I want is to use my code on other platforms, specifically the OLPC. (I realize this might be an unreasonable expectation, since the OLPC has very little graphics horsepower.)
I am currently totally staying away from OpenGL, since it seems like it'll take me a month to make headway into that. Maybe, however, OpenGL already has path-based stuff.
Anyway, I figured I'd toss this out there, see what people think.