# Architecture (/docs/concepts/architecture)

How CHUDCS2 moves live game state through ingestion, rendering and input.

CHUDCS2 reads the live CS2 process with `process_vm_readv`. `GameReader` publishes an internal `ShmPacket` snapshot under a mutex. The frame loop derives `FrameInput` and `FrameState` for rendering and feature logic. The current executable has no shared-memory simulation backend.

## Runtime flow [#runtime-flow]

```text
CS2 process -> process_vm_readv -> GameReader -> FrameInput -> App
                                                            |-> OverlayClient
                                                            |-> render passes
                                                            |-> feature modules
                                                            |-> VirtualInput
```

The main frame stages are:

1. `GameReader` publishes the newest packet under a mutex.
2. `App::prepare_frame_input` copies the current packet and derives frame-level values.
3. Visibility workers, map data, grenade tracking, and feature modules update state outside the draw calls where possible.
4. `App::render_frame` runs the depth prepass, player chams, ESP, grenade and world overlays.
5. Input modules use `VirtualInput` when a feature is enabled and its keybind is active.
6. `FrameScheduler` applies pacing and the overlay swaps its buffers.

## Major components [#major-components]

| Component         | Location                       | Responsibility                                                                |
| ----------------- | ------------------------------ | ----------------------------------------------------------------------------- |
| Application loop  | `src/app/App.*`                | Owns initialization, frame preparation, feature lifetime and render ordering. |
| Game reader       | `src/overlay/game_reader.*`    | Resolves offsets, reads live state and publishes frame packets.               |
| Overlay window    | `src/overlay/overlay_client.*` | Creates the transparent X11 or Wayland surface and OpenGL context.            |
| Visibility worker | `src/app/VisibilityWorker.*`   | Runs asynchronous line-of-sight and occlusion queries.                        |
| Model cache       | `src/model_cache.*`            | Parses VPK and VMDL data and caches player meshes and bone data.              |
| Depth prepass     | `src/renderer/depth_prepass.*` | Builds depth data from map and dynamic geometry for occlusion.                |
| Chams renderer    | `src/renderer/gpu_chams.*`     | Uploads bone palettes and draws skinned player models.                        |
| ESP renderer      | `src/renderer/esp_renderer.*`  | Draws screen-space boxes, skeletons, bars and labels.                         |
| Menu              | `src/menu/*`                   | Renders ImGui settings, profiles, diagnostics and previews.                   |

## Occlusion and visibility [#occlusion-and-visibility]

The renderer prefers a GPU depth prepass for map geometry. When GPU geometry is not available, the CPU BVH parser and visibility worker provide a ray-tracing fallback. Smoke and dynamic geometry are represented in the frame packet and can contribute to visibility decisions.

## Input boundary [#input-boundary]

`LegitAim`, `TriggerBot`, `EdgeJump`, `GrenadeHelper`, `AutoAccept`, and the walkbot input path are feature modules. They do not write input directly. They call `VirtualInput`, which owns the Linux `/dev/uinput` device and exposes the input enable gate used by focus checks and shutdown.

## Render order [#render-order]

The render path keeps geometry and screen-space work separate. Depth data is prepared first, player models are drawn with GPU skinning, and 2D ESP and status elements are drawn after projection. Overlay text and lines use native pixel sizing and rounded coordinates to avoid subpixel blur.