[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygame] Pygame vs RUDL



Hey Peter (again :) ),

> 1) I don't really see why so many people decide to use Ruby - Although some

Gets things done quickly - doesn't restrict me - doesn't irritate me -
easy to pick up.

> 2) I LOVE RUDL - at first it seems like a straight port of Pygame to Ruby,

SDL dictates a lot of the classes that you can make out if it, so they
really cannot be too different. That, and that Pete and I both think that
the library shouldn't look alien to the native libraries, and that I
"stole" a lot of Pete's code for getting something up and running quickly
are the reasons that they look alike. Lately I've been doing my own thing
more and more (although I stole the OpenGL code a few days ago :) )

> - pygame.draw : why not add the primitive drawing functions to the Surface
> class?

I thought about this for a while and decided that even though it was class
bloat, it was also the pragmatic thing to do. Nobody wants to search
around for methods...

It gave me a headache recently with my plans to include SGE, which has
almost the same functions. Should I break the API and make two different
sets of drawing functions to choose from? In the end I just ditched SGE
because it really didn't offer anything that other libraries didn't.
 
> And, more importantly: why does Pygame not accept alpha values for
> primitives at ALL, 

Doesn't it? Shame on you, Pete :)

> - In RUDL, I can do this:
> I think that having a special DisplaySurface class here is more intuitive.

We had a discussion about that, SDL's API is closer to what Pete
does. Another place is the music part, that I decided should be a class so
multiple songs can be loaded. SDL's API is quite rotten there, and
something like "stop" works on the currently playing song. Sounds
logical? It isn't in RUDL's API, since you can stop any of the songs and
the currently playing one will stop instead. Then again, you get some nice
DisplaySurface and Music objects to create! :)

> - RUDL supports SFont: I like bitmapped l33t effect fonts with alpha-layered

And it's easy to wrap!

> - RUDL implements the Surface.print( coord, text, color )  method from
> SDL_gfxprimitives, which is quite useful for temporary debugging output. If
> you use part of the library why not add support for this too?

Pete doesn't like those libraries because they are low on quality. I like
them because I can blame the makers if something goes wrong :)

> Okay, that's it for the comparison basically, but I have another request:
> Let the width parameter of those pygame.draw objects that can be filled
> default to 0 - just for the convenience factor.

Hm, is this Pygame specific? Can't see what good flat ellipses do?

> Oh, something else I discovered when working with both of these SDL
> implementations that may interest some of you is that they are exactly
> equally fast, as long as the fps rate is limited by gfx processing and not
> the language itself. (I coded the same app in both to test this)

Sounds logical, we can't really slow SDL down :)

Danny, createur de RUDL.

____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org