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

Re: [pygame] Re: pygame with SDL2 proposal



I would say that many people don't use pygame for more than simple games or experiments, because simple graphics is largely all that it is capable of (and remain playable). I also don't think that the situation that Ian described is what the larger community would want, even if it is useful to him.

Hiding the complexity of the underlying graphics system should be a goal, so that students don't need to get lost in the implementation details. But not providing a way towards modern, high performance graphics is a mistake.

Slow rendering creates a source of frustration and forces people to get hung up on making it playable, when instead they could be applying more gameplay features.

Keeping a Surface-like API, (blit a texture?, reserve surfaces for CPU drawing) backed by textures and a fast framework seems like the way forward. But no developer here wants to commit to it, or even affirm that people want reasonably fast graphics.

Not everyone was raised on C64, NES and 16-bit graphics and they have expectations that computer graphics should be fast. Those systems, I'll add, were hardware accelerated.


On Tue, Mar 21, 2017 at 8:23 AM Thomas Kluyver <takowl@xxxxxxxxx> wrote:
On 21 March 2017 at 12:27, Leif Theden <leif.theden@xxxxxxxxx> wrote:
Students should be taught how textures work, where different memories reside, and that GPUs operate differently than a CPU. At this point I think everyone knows where I stand, so I'll just let it go, since my comments are not being taken seriously.

Leif, I don't think it's true that your comments aren't being taken seriously.

I agree with you that pygame has suffered from a shortage of maintainer time. But I take issue on a couple of other points:

1. I don't think it's realistic to teach all students about memory hierarchies and the differences between GPUs and CPUs, while they're also trying to learn lots of other concepts about how to build a game, and possibly even learning to program. Those are topics people will need to know about if they want to build games more seriously, but a lot of people using pygame are not doing it to build big complex games.

2. As Ian explained, the kinds of games many people build with pygame cannot easily be 'hardware accelerated', because they don't fit GPU work patterns. But there are still a lot of fun and interesting things we can do in CPU-based games! Pygame survives in a niche of people building simple games which don't need great performance. If we can expand that niche, great, but your plan sounds like jumping out of the niche and trying to compete with other higher-performance frameworks, which doesn't sound like a good idea to me.

Thomas