sapphyrus · HackerTrans

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

sapphyrus

geçen yıldiscuss

> 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.

sapphyrus

3 yıl öncediscuss

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

sapphyrus

3 yıl öncediscuss

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

sapphyrus

3 yıl öncediscuss

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.

sapphyrus

3 yıl öncediscuss

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.

sapphyrus

5 yıl öncediscuss

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.

sapphyrus

5 yıl öncediscuss

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.

sapphyrus

5 yıl öncediscuss

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?

comments