wrote:

I have tested out that mouse lag caused in raw input program, and guess what? of course 1000Hz causing more lag than 500Hz but comparing two mices working on 500Hz both, gives a result where on every mice aside AK-47 the lag is couple of times stronger

And this have huge influence on my rig where mx300 gives so much lag that moving in QL with a prior /HIGH is unplayable, since both mices are plugged in, I can test out AK-47 in the fly, and damn no issues with AK-47, why?

every mice i used had a problem with in_mouse 1, on AK-47 this bug doesn't appears, the bug appears more often when fps are low or unstable

checked out real hz? some mice tend to poll on max values.
http://www.esreality.com/?a=longpost&id=1265679&page=18

wrote:

wrote:

um hmm, yes it seems this time I am wrong

but I don't get Yours arrogance

simply pissed, nothing more, i do belive in expirience rather in new products and honestly, considering the optimal mouse i gotta quote TorZelan:
"as long as it doesnt limit you, fine, go ahead and game"
there is no such thing as a mouse making u hit better, especially if the differences are rather small.
there is no problem with the negative accel either if u just hit it on a rather low amount of moves, such as a 180, where it definitly helps u doing a way more precise turn.

i basically cant make the deathadder skip by moving the mouse at any speed, rather by having sensor problems in 1-2 parts of my mousepad which i dont consider optimal but im to lazy to actually change mouse.

if somebody asks for a particular problem, there is no need to go all like, different mice are creap, rather take what ur expirienced with.

ps: i think thin cables break less.

edit: considering in_mouse 1, i think we know both what odds it has.
its windows input using 1.32b/c having up to 1 frame delay, having overflow when not all the data can be handled because cpu is to slow/lowfps.
this fa sho occurs on a mouse just running 125hz and if u feel funny u can of course run it on 125 hz.
1000 hz greatly makes overflows since data needs to be checked nearly real time.

if u just play public, u might consider using the defrag engine or something for having raw input without pb on normal q3.

the fact aint the thing u want, the cause is the thing u want to understand.
find the cause and u know why ur aim is higher or lower accurun.

btw I did plugged diamondback 3g and tested out with a4shit software

results speaks for themselves

tried many times result is always the same =]

--- e_d_i_t ---

some more scores:

97 Crative Fatality 1010
96 a4tech AK-47
93 Microsoft WMO
91 Logitech MX510
0 Razer Diamondback 3G

pls someone can pass me that utility?
googlin' i found only dead links

or... does exist a similar program?
tnx in advance

wrote:

and u probably meant that the in_mouse 1 bug doesnt appears on 125Hz but u did wrote it occurs

it occurs, thats what i ment, as soon as there is a overflow on whatever setting it fucking occurs, it just occurs less on 125hz since its less data.

wrote:

and yes Im talking about the real Hz because mx300, WMO, DA can easily hit 500Hz, ak-47 works on 500Hz super stable

my deathadder works 99 percent stable around 500 hz, no problem here.
btw, to stable hz might be the opposite of what the diamondback g3 does. (diamondback interpolates mousemovement to straight lines)
i roughly have the keep shooting overflow bug eventhough my fps aint that stable at all (or maybe i should shut down all background programs like msn and opera )

gotta send my deathadder through that testprogram though.

edit: will do a longer post about that program. gotta take my time.