The old locking/unlocking API was plain inefficient. Soon I'll move
upscaling to the backend anyway, to minimise the overhead where
possible.
Currently only the software renderer has been updated.
Previously, the window was a fixed size just like the original.
This change highlights a weird issue in CSE2: this doesn't exactly
match the behaviour of the original game, so why did I change it?
Simple: monitors had much lower pixel-densities back in the early
2000s, meaning that 320x240 and 640x480 weren't as laughably small as
they are today.
I like to think of CSE2's portable branch as Cave Story's equivalent
to Chocolate Doom: the point isn't to replicate the game's behaviour
100% - that's the accurate branch's job - no, the point of the
portable branch is to replicate the *experience* of the game, as it
was back in 2004. This means no commically-small windows.
This is the same reason font anti-aliasing is disabled, even in
versions of Windows later than XP.
Sidenote: the OpenGL3/OpenGLES2 renderers already had this feature,
but they used linear-filtering, causing the screen to be extremely
blurry in 320x240 mode. This renderer uses a better method, which
does apply slight blurring at the edges of pixels at resolutions
that aren't an exact multiple of 320x240/640x480, but otherwise it
resembles nearest-neighbour. This is way nicer to look at, and fits
the game's aesthetic. This feature will be ported to the other
renderers soon.
The backends need to have no dependency on the engine, otherwise
there'll be conflicts when we do stuff like include `window.h` in a
file that also happens to include "WindowsWrapper.h" somewhere.
Previously, the font batching system was very shoddy: basically,
glyph bitmaps would be cached to system memory, and uploaded
on-demand to the GPU.
The OpenGL3, OpenGLES2, and SDLTexture backends relied on
`cute_spritebatch.h` to handle batching. While nice, this library is
overkill: it's intended for managing a whole game, not just a couple
of glyphs. It also depends on C++11, which is something I'd rather be
without.
Being so complex, it appears that internally it spams the backend
when merging atlases together. According to bug reports, this causes
the game to skip a lot of frames.
Instead, I've ditched the system-memory-side caching, and made the
game maintain its own atlas. Unlike `cute_spritebatch.h`, this one
doesn't purge glyphs after they've gone unused for 30(?) seconds -
instead, glyphs are only purged when room in the atlas runs out, at
which point the oldest glyph is replaced. This method doesn't involve
creating or destroying atlases at runtime, avoiding the overhead of
whatever OpenGL/DirectX do internally when that happens.
Currently only the OpenGL3, OpenGLES2, and Software renderers have
been updated with this - the others will fail to build.
I know immediate-mode renderers won't benefit from this, but it
replaces the leaky old caching system, so it's still an improvement.
