[SDL Rendering] no z-ordering / depth buffer

[basisbit]

I started to implement support for rendering using the SDL2 renderer instead of using our old OpenGL 1.x based graphics rendering. You can already test the work by building + running the SdlRendering branch. One issue that I came across is that the SDL renderer is a pure 2D renderer only. It does not support any z-ordering or depth buffer. Thus, one option would be to implement our own z-ordering and then draw stuff from background to foreground. Another option would be to just drop any pseudo-3D drawing, so stuff gets drawn in required order automatically. This is mostly already done anyways. So far, I think only the current roulette songs view code actually requires the depth buffer. That code is inefficient and should be rewritten. Maybe at the same time, the songs view could also be refactored, so it is object oriented. Once this is done, creating and modifying new song selection views would be much easier.

I'd be happy about any help or comments.

[s09bQ5]

I like the idea of using the SDL Renderer for our drawing. Having looked through the code, I see the following problems:

• The Lua plugins are given access to the OpenGL API and we don't know which functions are in use by out of tree plugins.
• ProjectM does all drawing with OpenGL.
• The credits contain a 3D scene.

I think it is best to make SDL Renderer a build option that disables ProjectM and replaces dglOpenGL with a wrapper around SDL Renderer that only implements the functions we use. The credits would be dropped until we have a replacement and the wrapper can be extended if we come across a Lua plugin that uses a function we don't support yet. To simplify the wrapper, things like fUseMipmaps and fUseDisplayLists from UFont and fPboEnable from UVideo should be disabled (The latter already is always disabled).

[basisbit]

@s09bQ5 from what I remember, the lyrics coloring and drawing coding would need an extensive rewrite to make it work with SdlRenderer. This and also SdlRenderer being much slower and resource expensive when doing frame-by-frame redrawing of everything ( <- reusing the currently existing code) were the reasons why I stopped work on this branch 1.5 years ago. Another place that requires a bit of work is the video-frames drawing code, which currently also requires a valid OpenGL context within its thread afaik.

[s09bQ5]

Does not quite fit the topic, but it is close enough to remember it here: https://github.com/p3/regal is a library that might be able to emulate the legacy OpenGL functions we use on OpenGL ES and newer legacy-less OpenGL versions.

And there is also https://github.com/lunixbochs/glshim and https://github.com/ptitSeb/gl4es