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

Re: [pygame] Re: pygame with SDL2 proposal



Leif, thanks for your emails. It could be helpful if you have a proposal, that you put it forward.

I think you've definitely made your position, and your priorities clear about what we should do. However, so far I don't see a clear proposal from you with any support. Perhaps if there was one we'd have a better idea about what you are planning to do. And people could decide if your plan is something they want to do.

However from what you've written, I don't feel that this proposal will fail to deliver 'modern' features you're after. You seem to have missed the part where we said a few times that new SDL2 features would be added. If there's people interested in adding the additional SDL2 APIs to this work, no one will stop them, and they will be supported. Additionally, it's been pointed out to you that several other python libraries exist which are based on OpenGL with textures. People can use them today. A few of those libraries are featured on the front page of the pygame website.

Compatibility is important to me, and I think I've put my best case forward about how I think it will save us effort in development.  Not to mention saving effort for the hundreds of thousands of people who are currently using pygame. I think compatibility is important to other developers because there are a few other implementations of the pygame API which aimed for compatibility. Additionally, I think it prudent we do a spike test on linux to see if things are actually going to be good enough, and I think we can decide to change approach if it turns out that compatibility is harder than expected after wider testing.

Perhaps there is support for a new, from scratch pygame with modern features for real developers developing real games which breaks compatibility. To find out, a proposal for such would help.


For the record, I think some of the things that you've mentioned are good ideas backed up by evidence, sound thinking, and fair criticism. Thank you for your contribution and passionate discussion.




And to summarize some parts of the conversation so far, including the changes and clarifications to the original proposal:


cheers,


On Tue, Mar 21, 2017 at 1:39 PM, Leif Theden <leif.theden@xxxxxxxxx> wrote:
I'll add, so that my comments don't seem too caustic, that the maintainers have gotten more responsive recently. The "don't accept patches" comment isn't as true as it used to be.
On Tue, Mar 21, 2017 at 7:27 AM Leif Theden <leif.theden@xxxxxxxxx> wrote:
At this rate, we can expect SDL 2 to work in 3 years...all in the name of compatibility? It doesn't help that Rene is also maintaining the webpage... he's got no time. Let's be realistic, there are very few people who have the will or ability to deal with the pygame code base; and with the maintainers past record of not accepting patches, this transition will be very slow.

This dual library approach sounds like a nightmare to implement. Consider that you will effectively be writing code destined to be thrown out when SDL1 is no longer needed. You clearly must not value your own time, to be spending it on throw away shim code. There are significant differences in SDL 2 that you will be writing and maintaining adapter code for, like Leonard mentioned. Pygame isn't some mission critical piece of software. Let 1.9 be, and put all new patches into getting SDL2 working for 2.0, and let there be broken changes. Let someone else maintain 1.9, if they have a desire to maintain it.

And putting priorities into the software rendering subsystem is harmful. The old tutorials and books are not useful, because no games or applications use software rendering. Students will still hit a performance wall because they are taught to use surfaces instead of textures and will just move onto another platform because "Python is slow".

Python and pygame could rule the SBC educational market, but it is so slow on those platforms without hardware acceleration that it become frustrating to use.

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.
On Tue, Mar 21, 2017 at 6:15 AM Thomas Kluyver <takowl@xxxxxxxxx> wrote:
On 21 March 2017 at 10:48, René Dudfield <renesd@xxxxxxxxx> wrote:
It sounds like you're still not convinced though. I can make the tree first, and we can see what it looks like more easily. If it turns out to be not such a good idea afterwards we can always remove sdl1 support.

I'm not entirely convinced - maintaining compatibility with SDL 1 and 2 sounds like the sort of thing that *should* be easy, but could leave us with a lot of corner cases where one or the other doesn't work, and result in confusing issues when a game is tested on one and then unwittingly played on the other.

But I don't know SDL well enough to understand how big the difference is, and the transition doesn't interest me enough to work on it myself. I'm satisfied that I've made my case, and you're evidently not convinced, so go ahead and do it as you've planned.

The one detail I'd ask for before any SDL1/2 release is a Python API to get the SDL version number, if there isn't one already, so when people report issues there's an easy way for them to find out which SDL they're using.

Thomas