Visual Studio 2017 doesn't like them being 0 and 1: the compiled EXE
uses the small icon as the taskbar icon. Changing them to 101 and
102, like CSE2 did before the accurate-portable-split, fixes this.
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.
This used to be a feature before the accurate-portable split, I'm
just restoring it.
Previously, while the EXE itself had a unique icon, the window and
taskbar both used the generic 'small' icon, which the original EXE
only used for the window.
SDL2 gives us a way to assign separate icons to each, but it's a
little clunky: it's Windows-only, requires the icons be in .ico
format, and needs them to be embedded in the EXE as resource files.
Also, for some reason, SDL2 doesn't let us refer to them by name - we
have to use their numerical ID.
