Now the SDLSurface backend survives window resizes (also triggered by
alt-tabbing while in fullscreen), and the SDLTexture backend properly
regenerates its textures after a fullscreen alt-tab in DirectX mode.
Storytime: Cucky's original SDL2 port work involved using SDL2's
threading API to emulate the original WinAPI threading.
I can't be assed with that stuff, so I used the same trick Cucky did
for the Wii port, and hooked Organya up to the SDL2 audio callback.
This actually opens up the possibility for perfectly-synchronised
Organya playback. By that I mean, instead of needing a super
low-latency audio callback, I can have the callback synchronise its
audio mixing with Organya itself. I haven't done it yet, I plan to
soon.
When DirectX-SDL2 loses its device, it doesn't lose its textures,
just their contents, so we shouldn't remake the textures when we
regenerate the glyphs (that's coming next commit).
Has the same imperfections: if you regenerate the surfaces while a
text box is open (and while using Courier New I guess), the text will
regenerate with smaller spaces.
Surface-to-surface blits were broken (would draw to screen instead),
and the SDLSurface backend wouldn't even compile.
You know, I thought I tested each backend when I made those changes
to the API...
This way, I can use immediate mode, which is way faster than using
buffers for some reason. Since I'm not using profiles anymore, I
dropped the minimum requirement to OpenGL 3.1. If a driver doesn't
support Legacy GL, then it can use the slow buffer code.
But seriously, I need to figure out why using buffers is so slow.
If this was a common problem, Modern OpenGL wouldn't have made it the
only option.
For some reason CPU usage is still double that of the SDLTexture
backend (SDL2 uses OpenGL 2.1, with glEnable/glDisable-style
immediate mode).
If I downgrade to OpenGL 2.1, and use VBO-less glDrawArrays, I get
great performance. I just wish I knew what the AMD driver is doing
that's so much faster.
