They didn't explain those in detail because they didn't implement these concepts themselves. The GameNetworkingSockets library (and most likely also the internal network backend that was mentioned) provides them: > A reliability layer significantly more sophisticated than a basic TCP-style sliding window. It is based on the "ack vector" model from DCCP (RFC 4340, section 11.4) and Google QUIC and discussed in the context of games by Glenn Fiedler. The basic idea is for the receiver to efficiently communicate to the sender the status of every packet number (whether or not a packet was received with that number). By remembering which segments were sent in each packet, the sender can deduce which segments need to be retransmitted. https://github.com/ValveSoftware/GameNetworkingSockets

How did you find out their game used this library? Maybe I missed it but didn’t seem to be mentioned anywhere

They mentioned switching to the Steam networking backend, which for games is essentially GNS.

Ahh thank you, didn’t make the link between the names

> The system also has no relation to ChimeraOS, besides the unfortunate name similarity. ChimeraOS used to be called GamerOS and renamed itself to ChimeraOS later; however, at this point Chimera Linux was already in public development with its name in place.

Pretty sure the source engine used to have single-threaded audio for a long time. They worked around the buffer underrun problem by inserting calls to their sound update function at multiple points during the frame, like during rendering. Completely avoids the locking problem

You might want to check out https://adnauseam.io/ then.

If you're talking about Windows here, then you could write some code that intercepts the system calls used by common keyloggers (GetAsyncKeyState, SetWindowsHookEx with WH_KEYBOARD / WH_KEYBOARD_LL, etc) using hooking, an instrumentartion callback, or ideally a kernel-mode driver, then warns you if the game is trying to use them. Normal software should only really need to use the keyboard messages passed to its WndProc, which only receives them if it's in the foreground. So while there can be legitimate reasons for a game to call them, it's a good sign that something is fishy. This is not fool-proof though, as there are other methods to get system-wide keyboard input, but this would catch the simple ones.

WOW64 syscalls are indeed implemented using heaven's gate, the 32-bit ntdll calls into a "wow64cpu.dll" module, which does the long-mode transition and ends up calling into the 64-bit ntdll. Unfortunately manual syscalls are still possible (and widely used) on windows, either by hardcoding syscall IDs for common versions or performing very rudimentary "disassembling" of the ntdll syscall stubs.

Maybe tsc already does this, but why not just make extensive use of caching to get the compile times for "incremental builds" under control? Why would it have to re-check all 10,000 files in my project just because I modified a single file? That seems way more manageable (and less error-prone) than rewriting the entire thing.

The problem is that running Windows in a VM is an easy way of getting around current Anti-Cheat software. You can write a cheat that runs on the host OS and reads/writes game memory by directly accessing the guest memory. Even worse, the guest OS has no real way of detecting if you're doing anything malicious so it kind of just has to assume that you're trying to cheat if you're running a VM.

SDR works well and the latency is decent, but this would probably force you to drop the non-steam release or make some of the servers steam-only?

Documentation seems to say that they let you use the network from any platform as long as you have a Steam release. The bigger concern is that this requires linking with a closed source library, which means the open source version of the client could no longer connect to our servers without linking to a closed source blob.

That is sort of a non starter for us without some workaround like maybe hosting our own relays for the open source clients.