Be sure to read author's response(s) to comments below the post. Some insights about why C++17 doesn't help with reducing the size of the codebase:
> My version (...) has to convert the data into formats usable by modern video and audio APIs (...) in an endian-independent way, and adds quite a few correctness checks (...) instead of triggering undefined behavior
> the original can basically do a memcpy to show something on screen, I need 1000 lines of OpenGL code…
> I don’t have global variables, but this in turn means more boilerplate to inject dependencies into objects on construction etc.,
> I try to be fairly type-safe, which sometimes means needing more code, additional data transformations etc.
As someone who is trying to develop a PlayStation 1 game using modern C++ (GCC still has MIPS 1 support so why not) I can almost feel the author's pain, even though I'm running into different issues. Getting today's abstraction layers to run on nearly 30 year old hardware is not that different from adding them to a game that was developed back when memory protection was not a thing.
Here are some of the issues I've run into so far:
- Having no access to the STL (which would be too bloated for the PS1) makes many C++ features unusable. The ones that do not rely on the STL, such as virtual methods for I/O drivers or constexpr for compile-time string hashing, are still useful though.
- The PS1 is, very roughly speaking, a slow CPU with a bunch of fast ASICs bolted on. Most of those operate asynchronously but require relatively high-bandwidth streams of data (display lists, textures, geometry, audio...) that has to be generated by the CPU in real time or provided by another peripheral such as the CD drive. Feeding multiple ASICs running in parallel is an exercise in buffering and synchronization.
- As if that wasn't enough, most peripherals have their own proprietary data formats: the GPU uses a nonstandard 16-bit RGB color format where the top bit is used to enable alpha blending, the audio mixer only supports a custom ADPCM encoding and so on. I had to roll my own tools to convert assets into these formats ahead of time.
- Coroutines or threads are usually not an option since context switching burns a significant amount of cycles. A lot of "magic" has to happen within interrupt handlers, but those must also be fast since IRQs occurring before the handler returns are occasionally dropped.
- The PS1 has a BIOS that provides APIs for accessing files on the CD and memory cards, but they are so limited and bugged that I was pretty much forced to reimplement a full filesystem stack, from the SPI driver that handles communication with controllers and memory cards all the way up to the VFS layer. And writing asynchronous filesystem drivers without even using coroutines is... not fun.
1. There are independent libraries implementing facilities from the STL for embedded settings.
2. The ones without independent implementations are very often ones you shouldn't be using in the first place, because they're slow in general or for your specific testcase (e.g. std::unordered_map come to mind - abstractly, very useful structures; but the STL interface+implementation is junk, performance-wise).
3. You have EASTL if you _really_ need it.
4. The STL is mostly data-format-neutral in the sense of not supporting any data format itself :-P
> My version (...) has to convert the data into formats usable by modern video and audio APIs (...) in an endian-independent way, and adds quite a few correctness checks (...) instead of triggering undefined behavior
> the original can basically do a memcpy to show something on screen, I need 1000 lines of OpenGL code…
> I don’t have global variables, but this in turn means more boilerplate to inject dependencies into objects on construction etc.,
> I try to be fairly type-safe, which sometimes means needing more code, additional data transformations etc.