I'm not sure why there was linear filtering when I was rendering at
1:1 pixel ratio, but it did happen. This fixes it by forcing
nearest-neighbour. The artefacting was caused by the linear filtering
blending with pixels outside the specified texture coordinates,
creating lines around everything.
Fun fact: the framebuffer technique CSE2 uses is demanding on the Pi
(1278x720 runs at 60 FPS when the framebuffer is forced to 852x480,
even though all the internal rendering is still 1278x720). I guess
rendering those extra 920160 pixels really takes its toll.
Apparently 2 VBOs wasn't enough. This bumped the framerate from 13FPS
to 20FPS in a stress-test (CSE2E at 1704x960 on a Raspberry Pi 3B
in X11 with the KMS OpenGL driver).
SDL2 will implicitly disable batching if we force a specific
rendering driver (apparently the user setting SDL_RENDER_DRIVER
counts too) for backwards-compatibility with older programs that use
their own rendering side-by-side with SDL2's. We don't do that,
though, so this commit forces SDL2 to use batching if it's available
(2.0.10 and onwards).
This should reduce stalling when the OpenGL driver is still
processing the buffer when we're about to upload to it.
Hopefully, this is what was making the OpenGL ES 2.0 renderer so much
slower than the SDLTexture renderer on the Raspberry Pi 3B (SDL uses
*8* buffers). Unfortunately, I don't have access to it right now, so
I can't test this.
These list what video/render/audio backends are available, and which
are currently being used.
SDL2 allows you to choose a specific video/audio driver with the
SDL_VIDEODRIVER and SDL_AUDIODRIVER environment variables,
respectively, but there's no such option for the render driver.
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.
