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 <tak...@gmail.com> wrote: > On 21 March 2017 at 10:48, René Dudfield <ren...@gmail.com> 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 >
