Currently it's confirmed running on Android(later builds on Samsung Galaxy S7, although somehow crashing on 1kIPS/1kCycles/sec due to still unknown reasons), Windows(active building platform(Windows 10, although should run on anything from XP and up due to MSYS2/MinGW compatiblity issues with older OSes) where I debug my apps on mostly using Visual Studio 2015) and compatiblity mode on PSP(haven't tested for some time, but should still run). Linux compilation(not distributed myself) should also still be possible, but can't test those due to not having LInux installed anywhere(closest is my phone 🤣 (Android) ). So currently generic x86/x64. some ARM processors(Android) and the PSP processor(32-bit MIPS32 R4k-based CPU, named Allegrex).
So in short:
- Windows
- Linux
- Android
- PSP(pretty much too slow to be workable atm, but it's the original target when I was started building the app(before switching to using SDL, but even now it should still work with the SDL1.2 included with the PSPSDK))
All timing is simply kept as amount of nanoseconds passed, which are added together and substracted(varying between 0ns and 1 second usually). So the values being added(any immediately substracted) are usually in the 0.0-1000.0 range when running in sync with realtime, although it can do additions as high as up to 1 second(1000000000.0 being added(once) and substracted(in tiny portions according to CPU cycle intervals, so up to 31.25ns(CPU running at 32MHz, which is the currently largest default(for 80486)))).
Since the CPU runs at a 1kIPS/1kCycles/second, the values being added to the core time(CPU core and emulated hardware core time) are 1000000.0(1ms) when they're at their biggest increase steps. The increase of the realtime loop(which syncs to system time to try to keep the emulation up to speed and not too fast(although it currently fails to get up to speed even on a Intel Core I7@4.0GHz)) is dependant on the system speed vs emulated speed(the time of the inner loop of the two, which should be taking 1us at the most usually, due to simple block count limits).