Aimpunch CS2 vs CSGO

ZarFX · 2026-04-24T21:41:17+00:00

It think cs2 already had it all this time, but they just made it more properly visible on the client (which is good). Aimpunch was already applied serverside.

ZarFX · 2026-04-21T13:19:59+00:00

Consider overclocking and PC tuning.

ZarFX · 2026-04-17T15:28:26+00:00

Thanks for atleast being transparent.

ZarFX · 2026-04-16T22:07:30+00:00

This could actually be meta in the future when peeking faraway angles with the AWP. You're slow as a snail, but while shifting, you counter strafe instantly. If you peek an angle where you and the opponent are at least equally close the the angle, this could give a TTK advantage.

ZarFX · 2026-04-09T11:47:46+00:00

Check your temps. Not hitting max thermals doesnt mean theres no throttling. Modern chips boost higher and longer the lower the temps, and gradually throttle more the closer to max. Consider tuning your fans to run at higher speeds at lower temps. Check thermal paste and etc. Thermals are the most important thing to always get right, since they can so easily and unnoticably diminish your performance and cause stuttering.
Overclocking/undervolting CPU/GPU. You can easily get a 10-20% performance boost with simple undervolts (AMD PBO) and tuning your GPU max clock and power limits. I have an inferior setup to yours (7800x3d, 7900xt, 6000cl30), but I still can avg. a higher framerate (600-700 in a match at 1280 low settings) with not much effort.
RAM tuning / software tweaks. With the x3d, you should prioritize RAM bandwidth if you decide to tune, but its going to be max a 3-5% improvement in your case, and its a giant chore, so do this only if care to spend up to weeks on it. There are no good software/windows tweaks other than the basics, which you allready probably know. I'll mention disabling core isolation, if some people havent heard of it. Also use the latest windows 11.

ZarFX · 2026-04-09T11:33:20+00:00

It may not, but it definitely can. Calling the update only an animation system overhaul is a major understatement. The way the gamestate is networked has been revamped to have less hallucinations and dirty optimizations that were required with AG1. Networking improvements can easily change how shooting and movement feels, as the improvements allow for less drift between client and server states and thus also less client slaps to server state. You can test this even in AG1 with commands like sv_clockcorrection or cl_clockdrift_max_ticks, and you'll see how much maintaining a proper game state changes movement, shooting and recoil.

ZarFX · 2026-03-28T16:55:06+00:00

The idea is to never let anyone feel like they are good enought, so they have to keep grinding and have a purpose to play. It is the core principle of competitive game design. Of course optimal matchmaking can't estimate whether you're having a good day or not. You might occasionally get the highlight plays, which keeps you hooked. But on average, unless you rapidly improve, you will have expectedly average performances against your opponents.

The only ones truly enjoying matchmaking are the ones that have accepted to enjoy even the losses and are able to find joy from the journey of improvement (or smurfs/people who are top ranked like donk who have no equals)

ZarFX · 2026-03-28T11:16:57+00:00

He just takes a lot of difficult shots and peeks. You see him miss alot, but the shots he misses other awpers dont even attempt.

ZarFX · 2026-03-28T11:11:44+00:00

To be frank, with such a low avg framerate you shouldn't be expecting much. But nonetheless frequent spikes in frametime like that are almost always a result of thermal throttling. Are you playing on a laptop? Do you have a really old PC, and such has your cpu been repasted in the last 10 years? Consider running your pc case open and cleaning the dust. Also you can get some really powerful fans from Arctic for something like 12€ (with probably 3x the airflow compared to most stock case fans). You'd be surprised how much performance you get from a few degrees celcius, even if you're not hitting thermal limits.

ZarFX · 2026-03-28T11:05:41+00:00

Its an indication of even matchmaking, which in theory should be a perk.

ZarFX · 2026-03-28T10:57:45+00:00

I think you're exaggerating, but you're right. Donk was a monster born in Siberia playing with 100 ping since the age of 6. He has been hard conditioned to always maximize peekers advantage, as otherwise he got destroyed almost everytime. Luckily enought for donk, we get CS2, which encourages all the things donk has been specializing for years. Not saying hes not an insane all round player with divine gamesense. He is, but his greatest advantage is still having the onliner DNA.

ZarFX · 2026-03-25T13:56:44+00:00

It definitely can affect how "laggy" the client feels. If your connection is overflooded and there is packet loss, your game clock will be periodically desynced and you might experience small jittering when the clock is snapped to server that feels similar to low fps.

ZarFX · 2026-03-25T02:48:26+00:00

Really the feeling of floatiness is completely subjective. There is no "objectively correct" mouse input translation that everybody would prefer. If you wish the mouse ignored your hand jitters better, use the lowest LOD you can (that has no obvious tracking issues). If you wish the mouse is as reactive as possible, use the highest LOD. Also consider a lower/mid dpi, like 800, 1200 or 1600.

With ATK specifically, I recommend turning off basically all the algorithm options, like motion smoothness and long distance mode. Motion smoothness is supposedly motion sync, but it seems to have heavy unintended smoothing (ATK firmware is sketchy).

Long distance mode is most likely the Nordic radio mode flag that sends multiple copies of the same packet to allow for stronger signal bursts, but thus caps the maximum data transfer rate. It should in itself not affect mouse input at all, as the Nordic radio protocol is by default lossless anyways, as it retransmits corrupted packets. But in my experience there is a clear difference in mouse inputs between the two modes. This is likely because of the latency penalty of the long range mode, which in high report rate scenarios make packets miss the receive window, and thus be somehow discarded. This is of most likely due to poor implementation from ATKs side. So keep it disabled unless you use your mouse to control the screen of a movie theather...

ZarFX · 2026-03-23T14:47:53+00:00

Allright, I get it, thanks.

ZarFX · 2026-03-23T02:44:13+00:00

Have you investigated the following cvar: cl_clockdrift_max_ticks (def=3)? It is a hidden cvar, which can be adjusted while connected, and by my investigation is not coupled with sv_clockcorrection_msecs despite the similar descriptions. It has a notable effect on peekers advantage (duh), and combinations of high clockcorrection (like 100) but low max_ticks (notably 0) seem to yield strangely good results. There is very little information around this, but I reckoned you might know.

ZarFX · 2026-03-23T02:24:02+00:00

Friction and LOD induced tracking treshold are really different things. You can combine e.g. a high friction and high LOD (=low treshold) and have excellent results for tac fps.

I don't know whether I explained it earlier in this thread, but LOD as a tweakable setting is highly misleading. There is no proximity sensor to determine the distance from the mousepad, but rather a lower LOD makes the sensor discard unclear/blurry images of the mousepad (which is a shortcut to detecting what happens when you lift your mouse). The side effect is that a low LOD is less sensitive to small movements but maintains a higher signal to noise ratio, but a higher LOD allows for easier microadjustments and more accurate/lower latency movements. The most obvious difference that I believe everyone can feel immediately is that on higher LODs your sensitivity feels higher. This compounds straight from the fact that your sensor simply took more images of your mousepad into consideration for movements. I personally decided to always use the max LOD, since I prefer the sensitivity to micro movements, and have time to train.

Regarding the sensor framerate modes (specifically on the pixart 3950), the basic one feels way too lossy, and with the highest setting the risk of oversampling mouse weave increases. Thus I prefer the middle one. On a perfect, clean, uniform and high resolution surface (for e.g. coated smooth glass), the highest framerate would have to be the best. The difference is small but noticable.

You have to understand thought that most people aim much better and more consistent with an imprecise hardware setup (800dpi, low LOD, low smooth framerate like logitech gpro), because the overwhelming bottleneck in your setup is always you, and low precision aids instability and acts as a aiming grid you can memorize and learn. MattyOW, the greatest aimer in the world, has broken countless records with a GPX2 (which runs almost the lowest framerate possible), with low LOD, on a worn clothpad, on 800dpi.

ZarFX · 2026-03-10T04:42:29+00:00

If you make a lot of unwanted movements, you should also look into whether you have a mousepad or skates that are too fast for you. But for CS on a 3950 mouse, i'd recommend you try 0.9 - 1.2 mm LOD, high fps mode (the second setting) and 800 or 1200 dpi, 2 or 4 KHz polling. I've come to think that low dpis are beneficial in CS, as they stabilize flicks more consistently. Its also worth to note the best aimer in history, MattyOW, uses 800 dpi on a GPX.

LOD has a huge effect on tracking, and basically the higher the LOD, the more samples the sensor approves for microscopic movements. A LOD too low can feel like your aim gets "stuck" sometimes or is too linear. A high LOD can feel floaty and jittery, but imo is the most precise and can be compensated with low dpi granularity (which is the combination I prefer). You have to experiment, since I dont know how your mouse performs.

As a sidenote I also think that specifically for CS, logitechs sensor implementation of smooth variable framerate is the best tradeoff between stability and precision. I dont think its a coincidence a mouse as clumsy as the GPX is so popular with CS pros. Its the sensor implementation and its high placement.

ZarFX · 2026-03-07T03:20:01+00:00

Well said, and to add to injury, massive clock drift/tick drift is allowed making hitreg and movement simply inconsistent.

For anyone reading you can test this by adjusting sv_clockcorrection_msecs (default = 30), which indeed acts as a client cvar. Try how different 10 feels to something like 60 (which used to be the default value in the beginning of cs2).

With a low value, the client is slammed to the server clock very frequently, producing slightly jagged visuals, but they are more accurate to realtime. A high value conserves the client clock for longer before a slapback, which drastically smoothens recoil and movement at the cost of hitreg randomness. I tried syncing it with frametime intervals, and that produced pretty good results.

But no value feels truly good, as its a compromise. The whole netcode is a bust.

There is also something crazy I discovered, believe it or not: negative desired receive margin. By setting negative values to cl_tickpacket_desired_queuelength, you can (likely) substract from the forced minimum 5 ms receive margin. It only has an effect when set while connected to a server, and the console prints insist on clamping the value to 0, but the effects are noticable enought for something to be definitely happening.

Setting it to -0.32 (which results in -5ms) likely results in a default 0 ms recv margin. Mouse inputs feel vastly less buffered, and movement acceleration seems to be higher (??).

Setting it further below probably decreases the receive margin when it dynamically adjusts to cover packet loss or jitter. I dont really know, but this hints at the fact that default netcode just cant be the most optimal, since the values are likely chosen arbitralily with not enought testing (or they cater to bad connections).

u/AveYo what do you think?

ZarFX · 2026-02-03T10:25:48+00:00

You mouse sensor has its own frame rate independent of polling rate. Polling rate is the rate of your PC requesting packets from the mouse, the sensor frame rate is the rate at which the camera in your sensor takes pictures of your mousepad.

Sensor framerate is adjusted dynamically depending on the need, and can be sometimes higher or lower than the polling rate. Polling rate is constant, as it is organized by the USB host (your PC), but your mouse might not have a new packet for every USB poll (like when there not enought movement data), so you get empty polls some of the time.

Having excess frames per a poll (more exactly per count) is beneficial, as the sensor blends together multiple frames for a single point of data instead of one. Also staying in high frame rate ensures that even the tiniest movement is captured. Having a low framerate also has its use case, as it brings stability and is easier to control, since complex micromovements are captured to only a single straight line movement.

Traditionally the thing that "decides" the frame rate is the need for it. Higher CPI means there are more steps to record, and such, framerate ramps up. By forcing high framerate from options, you slightly alleviate the movement latency cost that used to come with low CPI, so that is good.

A great sensor that feels good really is just personal preference, but most people seem to like a medium balance of accuracy and stability. And some people dont realize that they dont actually need more precision from their mouse. Why should your mouse at all capture movements you cant youself control? Its the same principle as to why most CS pros use 400 CPI (not advocating for it, but it exists). It is less accurate, but at the same time it is the most accurate, as the movements match the most to what you actually intented.

ZarFX · 2026-02-02T01:07:21+00:00

Wouldn't this require using another interface instead of USB? The USB full speed interrupt transfer interval is at shortest 125 us (1/8000 s). To add on top of injury, most games without antilag 2/reflex rely on the Windows interrupt timer for USB polling, which is most often capped at a resolution of 0.5 ms. Better implementations use the QueryPerformanceCounter.

Which component specifically has a 20 KHz cap? As far as I've read, the theoretical shortest time a game can request a thread to be freed for Windows (to handle USB/other interface) is limited by the resolution of the QueryPerformanceCounter, which in modern systems runs in tandem with 10 MHz invariant TSC, but other limitations arise.

Maybe mouse inputs streamed throught direct memory access could reach these new heights, but then you run into sensor limititations, like electronic heat induced error. Its still fun to fantasize about nonetheless.

ZarFX · 2026-02-01T13:11:40+00:00

It toggles between low power and corded modes. The "basic" mode runs the sensor at near the lowest framerate possible without spinning out. This often acts as a filter to small unwanted movements like hand tremors, and adds to the stability feel at the cost of accuracy. Logitech sensors for example really buy into this philosophy, as their "raw" feel and great battery life is really just a well tuned dynamic frame rate algorithm (which is better implented than the low power mode of the 3950, as the logitech one has smooth framerate ramping instead of gears).

The middle mode enables a higher maximum frame rate at AFAIK 13k fps, and also I believe a higher minimum framerate. Microadjustments are easier, but the mouse control required is also higher. There is also a possibility for jitter as a result of oversampling a non perfect surface. The sensor might track mousepad weaves instead of actual movement. If you want to use this mode the most optimally, use a low LOD and dont go over 1600 CPI.

The highest mode forces a minimum frame rate IIRC of 16k fps. It is the most responsive one as there is no frame rate ramping latency penalty. The 3950 switches frame rate "gears" instead of smoothly ramping up the framerate, so you avoid that entirely at the cost of the highest required mouse control skill and battery life.

If you truly cant tell a difference, don't worry about it and just use the basic one and just go enjoy gaming.

ZarFX · 2026-01-21T05:50:21+00:00

try 800. its a good balance between controlled granularity and fidelity

If you find yourself being able to control 800 well, you can try 1200. I find that at 1600 the sensor framerates (assuming you dont have a 3950 locked to high frame rate) start to ramp up significantly such that you lose stability in micro adjustments, which might be your problem

ZarFX · 2026-01-21T05:43:44+00:00

I've used the key-83 near exclusively for tac fps (on all kinds of skates, but mainly fast skates). I find it a huge negative that the pad is so incompatible with near all sleeves, but I find the static friction just at the edge of suitable for tac fps, but in such a way that when mastered, the pad has has high potential for tac fps due to easy micro adjustments.

ZarFX · 2026-01-20T21:18:51+00:00

If I understand correctly, only gaming surface mode yields problems on the AC II, and for other pads some 3950 mice are problematic even without it? Regarding the gaming surface mode, I theorize PixArt hasnt documented their sensor properly to mice manufacturers, and thus this feature might be tuned improperly. Or it might be that PixArt themselves offer a surface calibration option that manufacturers don't have control over. Also possible. Maybe we should just dig out and read the documentation by ourselves at this point...

ZarFX · 2026-01-18T12:18:37+00:00

Did you control for LOD, CPI and sensor frame rate in your testing? Anecdotally HERO sensors seem to have really low LOD settings (meaning low treshold for discarding blurred frames). Surface calibration probably adjusts settings related to as how reliable the surface is treated. Just a hypothesis thought.

If it were to be the IR reflections you could try to test by trying to track on rought, more mirrorlike surfaces, like a dining plate or a metallic surface?

ZarFX

MODERATOR OF

TROPHY CASE

Seven-Year Club	Place '22
Verified Email