SDL is written in C, but bindings are available for multiple languages, including C++ and C#. As it happens I was actually using it with C++. And there are other libraries you could use instead, like GLFW or Allegro.
I've never thought of C as being that much lower-level than C++, but I guess everything's relative.
The problem I find with many games made for Win95/98/XP is that the game uses one or more third-party libraries that were only "valid" for a year or two. After that, updates to the OS closed loopholes that the poorly-written old versions of the libraries relied on, but the poorly-written newer versions of the libraries released to deal with those issues then break compatibility with the previously-released game, which was never updated or patched.
Yep, surveillance_records.person_id is the same as surveillance_records.id, which is incorrect. I looked at the Github repo and there's already a report for it.
What I don't understand (and apparently this is my problem, not a bug) is how we're supposed to narrow the list down to three suspects in the next-to-last step, as the "Case Solved" text describes (Yeah, I cheated). The interviews with the two witnesses give a partial hotel name and a check-in date, but that returns dozens of results. The ending messsge congratulates us for reducing that list by using the surveillance records in some way, but I can't see how. The only other detail I have is "The guy looked nervous", which doesn't seem to have any connection with the surveillance records.
I have a 2TB SATA HDD in my PS2 fat. AFAIK that's still the maximum storage size possible with the FMCB/wLaunchELF software. I believe that an unmodded original network adapter should be able to take up to a 512MB IDE drive, but I'd have to double-check that.
I used to use a third-party "network adapter" (they usually don't have Ethernet, just an HDD connector) with SATA support, which still works fine (it seems like most brands stopped working properly after a certain homebrew software version), but later I bought an official adapter (IDE/PATA) and a SATA conversion kit (a kit specific to the PS2 network adapter, not a standard IDE-SATA converter, which sometimes work with the PS2 and sometimes don't) so I could try network stuff.
I don't think it was worth it, but these days it's probably the way to go since there no longer seems to be any way of telling the non-working aftermarket adaptors from the working ones; the companies making the bad ones just started putting the brand name of the one still working adapter on their products.
That's kind of the bare bones of how it works, underneath all the abstraction layers and pretty GUIs.
Then it evolves.
First, you start splitting your code into multiple source files, either because your programs get too big to keep scrolling up and down one huge file to cross-check things, or because you want to incorporate someone else's code into your program, and it's more than just one or two functions you can easily copy and paste. You can still keep compiling and linking all of this in one step, but the command gets so long that you make a shell script/batch file as a shortcut.
After that, you might want to mix-and-match various source files to target different platforms, or to make other bulk changes, and you start going down the rabbit hole of having your shell script take arguments, rather than having a dozen different scripts. And then one day you take another look at "make" and realize that whereas before it seemed like impenetrable overengineering, it now makes complete and obvious sense to you.
Then you discover using "make" (or a similar utility) to split compilation and linking into separate steps, which used to seem nonsensical, but now you're dealing with codebases that take more than a couple of seconds to compile, or precompiled libraries or DLLs, and you get comfortable with the idea of just hanging on to compiled object files and (re)using them when the source for that part of the program hasn't changed.
And finally (maybe) you look at some of the crazy stuff in fancy IDEs and understand why it's there; that it's just representations of all this other stuff that you now know about and feel competent with. I say "maybe" because I've been programming for over 35 years, occasionally professionally but mostly as a hobbyist, and there are still things in IDEs that I either don't understand, or don't see the point of having them. But knowing the underlying principles makes me feel comfortable enough to ignore them.
There are a couple of different USB devices (usually sold as just cables) that communicate with an app on the Android device. I tried a few that worked well at first, but for some reason became flakier and flakier until they wouldn't even start after a year or so. I'm pretty sure that the devices are still fine, but the app updates killed the functionality by degrees, to lock out clones and force customers to buy a new device periodically.
However, there is one decent company with a reliable software and device chain: DisplayLink. They have a free app, and sell their chips to various equipment manufacturers, as well as making some of their own.
I will warn you that you need to be careful about buying equipment that carries the DisplayLink compatibility logo, because there are some devices that use their chips but don't support the software. You also need to make sure that the device will work with your phone, i.e. USB 2.0 or USB 3.x. Not all USB-C ports are automatically USB 3.x.
I got a secondhand HP device intended to be used with laptops for a second display output, but it works great with my phone. HDMI output with sound and negligible lag. I can even use it with a hub and have a wired controller at the same time. Now if only my phone supported simultaneous charge and OTG hosting. Ah well.
You say active waiting, but I wonder if you mean a busy-wait? Busy-waiting is generally bad, but don't forget that your main loop is just what executes when the OS decides to give your program some processor time. If you just check a stored timestamp vs the current clock at the start of each iteration, and then do nothing unless enough time has passed, control will go back to the OS for a bit, not the start of your next loop, so it's not a true busy-wait.
The original PC's hardware timer was... not great, and I believe that the situation only got worse over time. I understand the desire not to waste resources, but modern OSs are designed with the fear of not fully exploiting resources, so there's only so much you can do.
Zero Page Homebrew. That guy is absolutely on top of Atari homebrew. Every relase, demo, and announcement, as far as I can see.
VRidge works great for me, I recommend it, but it presents to software as a standard SteamVR headset, so I don't know if that addresses OP's problem. Also, it's a paid product if you want to use it for more than a few minutes at a time.
Those bananas meant so much to every little hungry schoolgirl.
Sorry, I don't have any experience with that. I only played Wii and GCN games on my Wii. I switched to a Wii-U for the convenience of direct HDMI output.