ESP explained: what a wallhack actually reads, and why it barely costs any frames
A technical walkthrough of how ESP is implemented — actor lists, view matrices, world-to-screen projection and overlay compositing — written for people who want to know what they are actually buying.
"Wallhack" is a misleading name. Nothing is being hacked and no wall is involved. What is actually happening is a lot more mundane, and understanding it tells you a great deal about which providers know what they are doing.
The core insight: your client already knows
In any multiplayer shooter, the server sends your client the state of the world so your client can render it. That includes the positions of other players — including players you cannot currently see.
This is not a bug. It is a consequence of latency. If the server only told you about a player at the moment they became visible, they would pop into existence a hundred milliseconds late, already shooting. So the server sends state ahead of visibility, and the client decides what to draw.
Some games mitigate this with network relevancy culling — the server tries to omit players who are definitely not relevant. Valorant is the well-known example. Most games, including every title we build for, do not cull aggressively, because doing it well is expensive and doing it badly causes visible pop-in.
So the information is sitting in your RAM. ESP is the process of finding it and drawing it.
Step 1: finding the actor list
Unreal Engine keeps a UWorld object with a persistent level containing an actor array. Getting to it means:
- Locate the
GWorldpointer — a global whose offset from the module base is stable within a build. - Dereference to
UWorld, then toPersistentLevel, then to theAActor**array and its count. - Iterate.
The offsets change every time the game is recompiled, which is most patches. Keeping them current is the bulk of patch-day work, and it is why "the update took four hours" is a real answer rather than an excuse.
Step 2: filtering to what matters
For each actor you read its class pointer and compare against the pawn class you care about. Then read the fields you need:
struct PlayerSnapshot {
Vector3 rootPosition;
Vector3 velocity;
float health;
int32 teamId;
Bone bones[24];
bool isDormant;
};The dormancy flag matters. Unreal marks actors dormant when they are outside relevancy — reading a dormant actor gives you a stale position from whenever it last replicated. Providers who do not check this produce ESP boxes that sit motionless in a doorway long after the player left, which looks broken and gets people killed pushing an empty room.
Step 3: world to screen
You now have a 3D position and you need a 2D screen coordinate. The camera's view-projection matrix does this:
clip = viewProjection * vec4(world, 1.0)
if (clip.w < 0.1) return OFF_SCREEN // behind the camera
ndc = clip.xyz / clip.w
screen = ((ndc.xy * vec2(1, -1)) + 1) * 0.5 * screenSizeThe clip.w check is the one everyone gets wrong first. Without it, targets behind you project to mirrored positions in front of you, and you get ESP boxes for players who are not there.
For a box, project the actor's bounding-box corners and take the screen-space extents. For a skeleton, project each bone position and connect them.
Step 4: drawing it
Two approaches, and the choice is the main technical differentiator between providers.
Hooking the present chain. Intercept the game's DirectX or Vulkan present call and draw your geometry before the frame is submitted. Easy, well documented, and it runs your code inside the game process — directly under the anti-cheat's nose. It also adds to the game's own frame time.
External overlay compositing. Create a separate layered window, draw to it independently, and let the desktop compositor combine it with the game. Your rendering never touches the game's render loop.
splatvik uses the second. The consequences:
- No hook in the render chain to detect
- No added work inside the game's frame budget
- Overlay can run at a different refresh rate to the game
- Stream-proof exclusion becomes possible at the window layer
The cost is that you must handle window ordering, DPI scaling and fullscreen-exclusive mode carefully. That is engineering work, which is presumably why most providers take the easy path.
Why the frame cost is so low
| Work | Frequency | Cost |
|---|---|---|
| Actor list walk | 60Hz | ~0.15ms |
| Per-actor reads (40 actors) | 60Hz | ~0.30ms |
| World-to-screen projection | Overlay rate | ~0.05ms |
| Overlay draw | Overlay rate | Off the game's thread |
Total game-thread impact: well under half a millisecond, and none of it in the render path. At 90 FPS your frame budget is 11.1ms. Half a millisecond of throttled worker time on a different thread does not register.
The measured numbers back this up — across our three shipping products the difference is one to two FPS, which is inside run-to-run variance.
The providers who cost you 15-20% are hooking the present chain and doing an unthrottled actor walk every single frame. Both are avoidable.
Distance scaling, and why it is not just cosmetic
Drawing 40 full skeletons with health bars and text labels is visual noise that makes you play worse. Good ESP is aggressive about what it draws:
| Range | Draw |
|---|---|
| 0–120m | Box, skeleton, health, name, distance |
| 120–400m | Box, health, distance |
| 400–800m | Box outline, distance |
| 800m+ | Dot |
This costs nothing to implement and improves both readability and, incidentally, how your gameplay footage looks if it is ever reviewed.
The visibility check
Knowing whether a target is actually visible — not just present — requires a trace from your camera to their position against the world geometry.
This matters for two reasons. Cosmetically, it lets you colour visible targets differently from occluded ones. Functionally, it is what stops an aimbot firing through a wall, which is the single most reportable thing a cheat can do.
The trace is the most expensive operation in the whole system, which is why it is throttled per target and cached for a few frames. It is also why some providers just... do not do it. If a product does not mention a visibility check, it does not have one.
What ESP cannot do
- It cannot show you players the server has not replicated. Against aggressive relevancy culling, ESP is genuinely limited.
- It cannot show you future positions — velocity extrapolation is a guess, and a guess over about 200ms is worthless.
- It cannot see through the fog of war in games that implement it server-side.
- It cannot read information the client was never sent. If loadout data is server-only, no ESP will show it.
Anyone advertising features that require information the client does not receive is describing something that does not work.
Want to see the implementation in practice? Every product page has real screenshots of the ESP output — Squad, Dead by Daylight and Hell Let Loose.
Reverse engineering — part of the splatvik team since 2023.
Related articles.
The complete Squad cheat guide: ESP, aimbot and staying invisible in 100-player servers
How the splatvik Squad build actually works — from the memory reads behind ESP to the smoothing curve that keeps your aim looking human on a 100-player server.
Dead by Daylight cheats explained: aura ESP, auto skill checks and how not to get reported
Dead by Daylight is an information game, and information is exactly what a cheat provides. Here is every module in the splatvik DBD build, how each one works, and the settings that keep you off the report radar.
Hell Let Loose cheats: ballistic aimbot, armour ESP and reading a 100-player battlefield
Hell Let Loose has real bullet drop, 800-metre engagements and armour that dies to one shot in the right place. Here is how the splatvik build handles all three.
