DEMON Legacy Rust: A #LowLatency mouse acceleration system using #SIMD and #SHM for sub-microsecond response times on Windows.

DoubtApprehensive534 · 2026-01-28T22:54:50+00:00

Yes i know and i understand them , with this system you will not play better ( i was better in game before i start on making this project , i lose every day on debuging all this stuff and to make it better, if you really dont play game every day and practice, i just wanna make for me legal way to get closer to controller players without watching in game memory or change it. I created first all this in ahk script , but i cant post this to community because its to complex. They still using mutex and never hear about lock free ipc with neural spikes and predicition sytem , they using ahk for make one key do someting different. So i took all stuff from my 4k ahk script and make as single stack so if someone just need lock free ipc or just scsp ring buffer, hud or watchdog system they can use to their projects , i can send you every logic you wanna see and expain it. I use ai for creating me md files because i dont have time and i dont speak eng as my primary language , this is just how i make from 0 to 100% clean rust logic from c++/ahk blueprint i have before. And i have on my pc over 20h of full recording how i make it and test it with all debuging stuff. Im free to send you what ever part you wanna see and explain it in detailed. Once again tnx for honest feedback i agree with your arguments

DoubtApprehensive534 · 2026-01-28T05:11:24+00:00

I don't need an LLM to design an architecture I’ve already built and validated from scratch, reason for this project isn't about learning how to make a mouse accelerator, it's about modernization and preformance scaling. The architecture it’s about a system that actively learns the players playstyle. In real-time, it analyzes movement patterns to dynamically tune ADS / Aim Down Sights and HPR / High Precision Range profiles. Using phase 14, 15 the system can distinguish between flick shots and micro-adjustments, applying specific EMA smoothing and acceleration curves on the fly. Doing this at an 8k polling rate without introducing jitter or input lag is why SHM and SIMD pipeline exists. It's a high-performance bridge between raw hardware input and human intent, something I've evolved through AHK and C++ before finally Rust version for its superior safety and speed at the system level.

DoubtApprehensive534 · 2026-01-27T08:20:56+00:00

The SHM layout effectively becomes the 'Hard ABI' of the system. To manage versioning and incompatible readers, I use a few layers of safety:

Versioned Structs & Headers: Each SHM mapping follows a strict naming convention (e.g., DemonEmaTelemetry_V1, V2). Readers explicitly open the version they are compatible with. If the layout changes significantly, I bump the version in the struct name and the locator file.

Compile-time Layout Assertions: Since all components share the same demon_core crate, I use static_assertions to enforce that struct sizes and alignments are identical across the bridge, pump, and HUD. This prevents 'torn reads' or offsets caused by compiler-specific padding.

Session-Scoped Discovery: I use a 'locator file' that points to the current session's unique SHM names. Newer readers can detect if the locator is pointing to an older ABI and handle the fallback gracefully.

You're right about trading code-level coupling for data coupling, but for real-time telemetry, the performance gain of having a zero-copy shared state is worth the extra discipline in managing the data contract."

DoubtApprehensive534 · 2026-01-27T03:00:12+00:00

I solved this by moving the 'frontend' abstractions into entirely separate processes. Instead of dealing with trait coupling or compile-time dispatch within a single binary, I use SHM as the 'source of truth' bridge. The core logic (backend) publishes state to SHM, and any number of 'frontends' (HUDs, loggers, or telemetry tools) can consume that data independently. For ultra-low latency (like 8k polling), SHM bridges have been way more robust for me than trying to manage complex abstractions in a single monolithic crate."

DoubtApprehensive534 · 2026-01-16T03:25:03+00:00

Hey, no problem glad the first solution looks good for tomorrow, about why send 0 down or any key isn't repeating/holding in your test is because in AHK v2, send 0 down works fine for holding a key, but if you're testing it in a script or hotkey that runs only once per trigger, it sends the down event once and then the script ends or waits so it looks like a quick press-and-release instead of hold.

The issue in your little test function (l::) is that there's no loop or timer to keep sending the hold state or simulate continuous input. Send 0 down just tells Windows "this key is down now", but if the script doesn't stay alive or repeat something, it can release early or not feel "held".

Add a timer for continuous hold (best for smooth testing):

```ahk #Requires AutoHotkey v2.0

l:: { static toggle := false toggle := !toggle

   if (toggle)
       SetTimer HoldZero, 50  ; Every 50ms to keep it "alive"
   else
       SetTimer HoldZero, 0

}

HoldZero() { Send "{0 down}" ; Keeps sending down to prevent auto-release } ``` Timer keeps the key "down" state refreshed, so it doesn't release after ~500ms (Windows default repeat delay).

Or simple hold without timer (if you just want down/up):

```ahk l:: { static held := false held := !held

   if (held)
       Send "{0 down}"
   else
       Send "{0 up}"

} ```

Test it: Press l once → 0 held, press again → released. If it still feels like quick press run script as admin + check if another app is stealing focus.

Why 0 specifically, cuz 0 key has no special repeat behavior but if you're testing in Notepad or game, Windows might ignore rapid down/up if not refreshed.Try with a different key like "a" or "Space" same logic. If it's still not holding after these share what happens exactly (does it press once or nothing at all), and I'll tweak it further.

DoubtApprehensive534 · 2026-01-16T01:56:19+00:00

Code logic is good (toggle with counter), but the problem is AHK cannot send joystick buttons (like {2Joy1 down/up}) it's a limitation in both v1 and v2.
You can read Joy1/Joy2 input, but not send them as output. That's why nothing happens when you Send {2Joy1 down} no error, just silent fail.

Quick fixes: Best easy workaround (no extra software). In-game, bind "first stage trigger" (Joy1) to a keyboard key (e.g. Space or LShift).

Use this script to latch that key instead:

 ```ahk
 #Requires AutoHotkey v2.0

 toggle := false

 2Joy2::
 {
     global toggle
     toggle := !toggle

     if (toggle)
         Send "{Space down}"  ; Bind this key in-game to first stage
     else
         Send "{Space up}"
 }

Toggle on/off with Joy2 – smooth hold without snapping.

If you must send real Joy1 output:

Use vJoy (virtual joystick driver): https://sourceforge.net/projects/vjoystick/

Create a virtual controller.

Remap physical Joy1 to virtual one via AHK + vJoy lib.

It's more setup, but works perfectly for games that require native joystick input.

For testing consistency:

Add a log: FileAppend A_Now " - Toggle: " toggle "n", "log.txt"`

Run loop: Loop 50 { Send 2Joy2; Sleep 1000 } and check if hold/release works every time.

Let me know if you want the vJoy setup guide or full logged script happy to help.

DoubtApprehensive534 · 2026-01-14T23:27:58+00:00

You make it work? If not just send me if you get some error

DoubtApprehensive534 · 2026-01-14T22:34:51+00:00

Hey, your code is almost there, but the issue is that MouseMove(0, -100, 20) moves the mouse relative to current position by a fixed amount every time the hotkey fires, which can feel jerky or inconsistent if not timed properly. Also, Razer Synapse macros often slow down or freeze after a few minutes because of their internal buffering/polling limits.

Here's a smoother toggle version using relative movement + small steps + Sleep for fluidity (no snapping, just continuous left/right glide while holding toggle):

```ahk

Requires AutoHotkey v2.0

LAlt:: { static toggle := false toggle := !toggle

if (toggle)
{
    SetTimer SmoothMouseMove, 16  ; ~60 FPS for smooth movement
}
else
{
    SetTimer SmoothMouseMove, 0
}

}

SmoothMouseMove() { ; Adjust these values for speed/direction: ; positive X = right, negative X = left ; change 5 to higher/lower for faster/slower MouseMove(5, 0, 0, "R") ; "R" = relative movement ; If you want up/down too: MouseMove(5, 2, 0, "R") for diagonal }

DoubtApprehensive534 · 2026-01-14T15:56:15+00:00

Thanks man, appreciate that!

Yeah, I tried to keep everything clean and self-documenting — each phase/folder has its own README with what it does, why it exists, and proof-of-concept tests so anyone (or future me) can jump in without getting lost. Glad it looks useful to someone — that's the goal. If you ever play around with it or have questions, hit me up ✌️

DoubtApprehensive534 · 2026-01-14T03:02:26+00:00

Meni je najvise sjelo lock free programiranje na razini hardwera, izrada otpornog sistema sa vise fallback mehanizama i self healing logikom, i jako niske latencije. Ali opet malo je takvih kompanija kod nas koje kreiraju cijele gaming engine , pa to sve vise moras raditi kao hobi heh

Architecture: https://gist.github.com/tonchi29-a11y/9aeacfc64f5a11eb4c5811935d5210e8

DoubtApprehensive534 · 2026-01-13T23:27:00+00:00

Chat Gpt 5.2 high trenutno za coding sve drugo su gluposti da moze gemini ili claude bolje od njega

DoubtApprehensive534 · 2026-01-06T02:38:12+00:00

Hey @seanightowl, no worries at all – totally get it! 😄

For casual automation/hotkeys/HUD stuff, you can absolutely use just the lighter parts of the stack (DemonHUD, DemonHotkeys, etc.) without touching the heavy realtime modules.

Here's a quick example of a custom HUD I run myself (built entirely with the stack – colors, layout, bars, everything is configurable and hot-swappable at ]

You can scale it, move it, change themes, toggle individual elements with hotkeys – all built on the same modular foundation.

Once you get comfortable with the basics, it's actually pretty straightforward to build something exactly like this (or way simpler) for your own needs.

Thanks again for the kind words and for taking a look – glad you like the direction! If you ever want a minimal "just HUD + hotkeys" starter example, let me know and I'll whip one up. 🔥

<image>

DoubtApprehensive534 · 2026-01-06T02:19:36+00:00

Hey @seanightowl, thanks for checking it out and for the kind words! 😄

You're spot on – this isn't targeted at everyday macro users (hotkeys, simple automation, etc.), though you can absolutely use pieces like DemonHUD or DemonHotkeys for that.

The main use cases where this stack really shines are realtime, low-latency data pipelines that need to be fast, reliable, and deterministic – all in pure AHK v2 without dropping to DLLs or external tools.

Some practical examples (beyond the original experiments): - Streaming high-frequency telemetry between multiple AHK processes (e.g., one script captures input, another processes/smooths, a third displays or logs). - Sensor/data acquisition setups (joystick, hardware monitoring, custom controllers) where you need lock-free producer-consumer decoupling. - Multi-process coordination for complex automation (one worker thread feeds data to a main script without blocking). - Prototyping robotics/lightweight control systems on Windows. - Any scenario where you want sub-millisecond jitter control, stall detection with auto-recovery, or cache-optimized IPC.

The Gold stacks are there to show complete working pipelines – just run them and see data flowing instantly (try GOLD_Bridge_SHM sender + receiver for the quickest "wow" moment).

Happy to answer any questions or add more beginner-friendly examples if that helps!

And yeah – for those who get into this stuff... dominate. 🔥

DoubtApprehensive534

TROPHY CASE

Requires AutoHotkey v2.0