[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pygame] Pygame vs RUDL
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