Re: [pygame] Pygame vs RUDL

[Pete Shinners <shredwheat@attbi.com>]

i think rudl is pretty darn good. i've actually had a bit of fun looking 
over the design options Danny and RUDL have gone through. both of us 
have been building our SDL wrappers near the same times..

i pretty much agree with peter thoman's views of the ruby language. it's 
actually quite well thought out and feature full. it also has a little 
extra 'barrier of entry' than what i've found in python, so i never 
really have given it a chance to dig in and toss it around. i feel some 
of the language is a little arcane, even though pretty well layed out.

when i was putting together pygame, i was coming from the pysdl library. 
this is just a straight shot of the SDL C interface into python. SDL is 
one of the best C libraries i have ever come across. very clean and easy 
to use. unfortunately, putting that into python really neglects all the 
features that python gives you, so i went about redesigning things a bit 
more python-y

for the most part i just meant to keep things conservative. i figured 
i'd be best not straying too far from what was already available.

two of the biggest bonuses for RUDL you mentioned. the fact that all the 
functionality for Surface objects is rolled in as Surface methods. this 
is more of a bonus for Ruby. it's much easier to implement this sort of 
thing in ruby. with a bit more work, python can do the same sort of 
things, but the design of pygame fairly difficult.

pygame is broken into many "equal citizen" modules. this means there's 
nothing you couldn't do in your own third party python module that is 
done in the real pygame modules. the pygame modules also export their C 
interfaces, which should technically make it easy to create your own C 
extensions that interface with pygame objects and other SDL calls.


 > $Display=DisplaySurface.new($ScreenSize)
 > $Display.flip()

vs

 > Screen=pygame.display.set_mode(ScreenSize)
 > pygame.display.flip()

yes, in hindsight i also prefer this sort of design. unfortunately it's 
a bit of a problem with the way python objects work. you can't really 
"inherit" base python objects from one another. plus this sort of 
internal management is pretty tricky from the C side of things. consider 
this a drawback of python really. looking back now i see how it could be 
done, but it's not an immediate concern.

fortunately, the separete "pygame.display" module works rather well for 
the way SDL is currently designed.



 > - 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?

pygame doesn't really use SDL_gfx. i have ripped the "rotozoom" 
functions from the library, but i have my regrets. there's enough 
"gotchas" included with the rotozoom code i haven't been too happy with 
it. still, it's pretty useful, so i haven't actually ripped it out. but 
i'm not too encouraged to go adding tons of other libraries into the mix.

unfortunately most of the SDL based code out there is pretty sloppy. 
i've seen it all cut&pasted between many difference sources, and in the 
end there's a lot of little cases that don't work right.


 > Let the width parameter of those pygame.draw objects that can be
 > filled default to 0 - just for the convenience factor.

done!  http://pygame.org/whatsnew.shtml


 > Now please don't get me wrong, I like Pygame a whole lot and
 > appreciate the effort put into it so I just want this post to be taken
 > as constructive criticism or, more precisely the ranting of a f00l ? 
 > > that demands the best of 2 worlds [;)] .

i hear ya. i'm glad there's other libs like pygame out there. i'm glad 
to see the competition, especially the good ideas that can come from it.



 > 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)

this isn't too surprising. in the "great language shootout" both python 
and ruby are always within a position or two of each other. i'd be 
curious to see if there were cases where one was faster than the other 
for a particular type of game. in the end i'd say they're both the equal 
tool for the SDL managing job. choose the one that gets the job done!




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