[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] pygame with SDL2 proposal

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.