Is this unrelated to the "Renderer" API? Just IMO, i'd rather use the Renderer API than trying to work with obsolete opengl and have cross-platform issues. Not worth getting working if it really has all these issues.
On Mon, Aug 13, 2018 at 1:15 PM, René Dudfield <ren...@gmail.com> wrote: > Yes! For sure. I think we should seriously consider it. > > TLDR; there are a few concerns, but it could be the best way forward. > > What do you(ses) think? Anyone want to try it out? > > > > I think we definitely could use something for what sdl-gpu does well. > Which is mainly automatic batch rendering to reduce state changes, but also > a rotation/scale API along with a nicer way to use shaders. > > - the author and other people have used it in various games, and it's > a number of years old now. > - People have used it on iOS and Android. Which both currently support > OpenGL, and these are where you need performance most. > - It's not in Debian, homebrew, Fedora or... (which is the same as 'is > it stable/mature and packaged well?'). > - The releases haven't been 'proper' and versioned yet. There's no > .tar.gz with the version in its name for example. > - it uses CMake (ya! for modern packaging). > - It's marked as version 0.11.0 (ie. not stable or finished). > - Currently it only supports OpenGL*[0] (which is still worthwhile). > - there is a windows/appveyor CI, but it's been broken for five months. > - it's mainly one author, but quite a few minor contributions. > - there's lots of interactive tests, but no automated tests. > - I'm slightly concerned it's too closely coupled to OpenGL, and some > of this may leak through. > > > The best thing about sdl-gpu is that it doesn't require you to batch up > your drawing calls first. So people using the API in a naive way can also > see performance improvements. However, (c)python has the high python > function call overhead, so in some ways we still have to avoid non-batch > rendering anyway. > > Some of these cons about packaging, and 'proper releases' could perhaps be > contributed. However maybe the author doesn't want this(or yet), rather > than doesn't know how or hasn't had time. There is a pkg-config script PR > been open for two years without comment, so I'm a bit afraid the author > doesn't care*[1 <https://github.com/grimfang4/sdl-gpu/pull/45>]. To be > fair, that Pr is incomplete, so maybe the author just doesn't want to do > this work, or wants to wait a bit longer before things stabalise... who > knows? Or just wants to support CMake only. Perhaps asking the main author > questions about it would be a good idea :) > > I'd feel more confident knowing someone I trusted who had used it, or > someone experimenting with it more and reporting back any potential > problems we'd have. > > > Note, however that there are several 'draw 2D things faster on OpenGL' > even done in python which are 'pretty good'. Including one I wrote (but > that mainly worked at the sprite level). Other groups (renpy, kivy) seem to > decide on 'hey lets roll our own!' where SDL is lacking. I think it's > better to contribute to a shared solution with the rest of the SDL > community. > > But perhaps it's worth us considering using or helping out one of the > dozen python options? For example, some people already use some of the > pyglet OpenGL drawing code on pygame. > > > The SDL2 option is to try and help get a batched API into SDL2 itself. > Then other backends would also be optimized that aren't using OpenGL. > Remember that OpenGL is theoretically deprecated now. Things like Vulkan, > Metal, Direct3d, and such. > And there has been some work on that, and discussion on that for some > time. But not much movement there. > > Note: sdl-gpu could(theoretically) be used from inside a SDL1 pygame :) > > > If someone has some time, I feel like patching in the 10-30 required > alternative function calls and just giving it a go could be a great first > step. > Which would be a search replace job with SDL_RenderCopy() into GPU_Blit(). > Full list on the github page *[2 > <https://github.com/grimfang4/sdl-gpu#conversion>]. > > Then we can better figure out the pros and cons... to determine if it's > worth us using. > To get around the problems with it not being packaged for > Debian/Ubuntu/Etc... we could just make it an optional compilation for now. > Then compile it ourselves in our binary wheels for these platforms, plus > contribute towards packaging on Debian/Homebrew. > > Maybe it's even possible for us to compile it in, and have some sort of > setting to enable/disable it. Not sure if that's possible, but that would > be best. > > > > Open questions for me: > > - Is there someone I know who can try it out, and report back? > - Will this be stable in the future and packaged well? Is this even an > aim? > - Will other backends be supported other than OpenGL ones? > - Can we include it without tightly coupling ourselves to OpenGL? Will > OpenGL leak out? > - Can we compile it in optionally, so that people can opt in? > - What other options are there for nice 2d OpenGL renderers? (pyglet, > renpy, ...) > - Can we get a confirmation from Sam/Ryan on if batch SDL2 rendering > would be accepted? > - Who will actually do this work? Does this work have to be done > before a pygame 2, or can it come later? > > > > > * [0] OpenGL 1.1, 2.0, 3.0, 4.0 OpenGL ES 1.1, 2.0, 3.0 > * [1] https://github.com/grimfang4/sdl-gpu/pull/45 > * [2] https://github.com/grimfang4/sdl-gpu#conversion > >
