[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
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.