Innocence wrote:

>>Peter Thoman:
>>I did the first 2 of that list (with RUDL, which I think is superior to PyGame btw
>>    
>>
>How so? On the paper RUDL is using PyGame as a template and PyGame
>seems to feature more functionality. 
>
RUDL is more Rubyesque. I used PyGame before, and RUDL got exactly those 
things "right" that I thought were less than ideal in PyGame. It's hard 
to explain - it's just that with RUDL, all the classes work like I would 
expect them to. I posted to the PyGame mailing list about this a long 
time (3 years?) ago, but I can't find my message in any of the archives 
now.
An example of what I mean by "rubyesque": To check for bounding box 
collisions between two lists of sprites, I just call collide_lists( l1, 
l2 ), which yields each colliding pair into a supplied block. Is that 
cool or what?

>PyGame is also more mature which I guess is the reason why it has fewer bugs.
>
That may be true, however I only ever encountered a single bug during 
all the time I used RUDL. That's just anecdotal evidence, but I believe 
it shows that RUDL is not too buggy to be useful. And if you do find a 
bug, you can always report it or even fix it yourself. The only bug I 
found (it had to do with stereo sound effects - seems like I was the 
first to ever use them) was fixed 3 days after I reported it.

>Sadly though, it seems that both projects are stalled in their current state. It's a real shame but understandable considering it's freeware :(
>  
>
Well, it's open source, so if there is something you would want to 
change / fix, go ahead ;)
Also, the main developer just posted on the forum less than a week ago, 
so maybe "stalled" is too strong a word...

>I see that other posters here (Florian Gross and Gabriele Renzi)
>recommend using only SDL (ie. without a wrapping like RUDL). Is this
>really an option? I mean, there must be a reason that modules like
>PyGame and RUDL exist, ie. for making handling easier. What's your
>take on this Peter?
>  
>
I wouldn't recommend it. If you use Ruby you are probably a fan of the 
rubyesque coding style - with all it's object-orientedness, block 
passing and syntactical convenience - which I don't believe a direct 
conversion of a C library can provide.