Re: [pygame] pygame with SDL2 proposal

[Lenard Lindstrom <len-l@xxxxxxxxx>]

Okay, let's clear up a misunderstanding. This not an /either/ GPUs /or/ 
CPUs issue here. SDL2 adds windows, textures, and renderers. But it 
still supports surfaces, even screen surfaces. So a Pygame 2 will add 
new object types for the new features while keeping surfaces, unless we 
no longer want image file support or text on the screen. The only big 
compatibility issue I see is that events are reorganized in SDL2. I 
emulate SDL1 events in my patch set to maintain backwards compatibility.

The real question is do we want to add SDL2 features to the existing 
Pygame code base or pull a Python 3 and redesign the Pygame api for 
ascetic reasons.

Lenard Lindstrom

On 17-03-20 04:18 PM, Leif Theden wrote:
> I'm not really sure how to respond to this wall of text. Ian, you are 
> really trying to make the case that a software renderer making simple 
> shapes around the on the screen is better than a GPU?  Why then are 
> basically all games these days using a GPU?  Please, don't answer it, 
> because I'm not sure if you are trolling or not, and don't want to 
> risk derailing the tread with this...honestly quite ludicrous 
> assertion you've made.  The proof is in the pudding, so to speak, and 
> the pudding is certainly not software rendering anything.
>
> Anyway, I don't think the typical use case for games is drawing 
> lines.  People want sprites, and they want them to rotate, scale, and 
> translate quickly.  Pygame1 cannot do this, but SDL2 can.
>
> I would say maybe there is a niche for pygame1, a toy for drawing 
> lines and breaking students dreams of building a game using python.  
> There is a real desire for a fast python library that doesn't have the 
> magic of say, Kivy, or even pyglet, but isn't slow and cumbersome either.