is this fps dependent like accelstyle 1?

Basically, its calculations do not depend on the duration of the game frame in milliseconds (I have it hard coded at 8 for compliance with 125 FPS mouse feel), so in this way I tend to think that it is not FPS dependent anymore.

However, if you used to play QL with mouse accel and FPS 60, just change 8 in two divisions to 16, and it will make the trick. So it could be FPS dependent too, if you wish. :)

Edit: and BTW, in QL both accel style 1 and 0 are FPS dependent. :)

Edit: and BTW, in QL both accel style 1 and 0 are FPS dependent. :)

0 shouldn't be but it's the feeling I get sometimes. Any real data to prove this point?

Yes sure, here is the link to ioquake3 code, which I used as a reference:

http://svn.icculus.org/quake3/trunk/code/clie...iew=markup

See CL_MouseMove function. In both cases there are frame_msec present. The longer it is, the less overall accelerated sensitivity will be.

This code is practically the same in Q3 and I can assume it is not changed in QL too.

no. just because you can see "frame_msec" in the source does not imply the *behaviour* is framerate dependent.

you can't tell just by looking at the code.

In fact the presence of frame_msec is the reason the the behaviour is NOT framerate dependent for style 0.

framerate dependence is a mathematical dependence, not a code dependence.

How the behavior of accel in QL and Q3 is not frame rate dependent, if actual mouse movement with both styles of accel will change upon frame_msec change, which is duration of game frame?

frame_msec is fixed at 8 afaik ever since ~q3 1.32?

Actually, I don't know. :) Do you have some source for this info?

"framerate independent behaviour" means the output rate is only dependent on the input rate, and is explicitely independent of the frametime.

the code computes the change in yaw, NOT the yaw rate.

if you calculate the yaw rate produced by style 0, it is independent of the frametime.

if you calculate the yaw rate produced by style 1, it is explicitely dependent on the frametime. hence "framerate dependent".

and dont tell me to "learn some basic math", you little shit, I am doing a PhD in math.

Being PhD in math does not necessarily mean that you can read.

Where in the code of my script you can see dependency on FPS (either game FPS or GlovePIE FPS)?

how old are you?

23

And you have a PhD? What year did you join the program and when did you finish?
*edit: nevermind, i guess, since you edited

no, i havent finished yet. will be another couple of years.

In what area you are working, BTW? :)

I mean, what is your PhD "specialization"?

Bet it all on injx.

this is wrong. the frametime you use should be the time associated with deltaX and deltaY, NOT the game frametime.

e.g. If your script is running at 500Hz, the frametime you use should be 2ms - otherwise the accel will be completely wrong.

For style 0 you will need to set var.CL_MOUSEACCEL to (cl_mouseaccel / sensitivity) to get the correct acceleration. for style 1 you dont need to divide out by the sensitivity.


Also, in QL (and Q3), style 0 accel does not have explcit framerate dependent behaviour. style 1 very much IS framerate dependent.

Man, feel free to experiment with the script and you will see that you theory is proven wrong by real behavior of the code. :)

In short, if you will take time of frame equal to 1000/500=2 ms you will get huge accel, which is not even remotely reminds actual QL accel.

for style 0 you definitely need to use 2ms.

for style 1 you need to use a 2ms frametime to calculate the input rates, then you need to scale the Offset by the QL frametime as described here:

http://www.esreality.com/index.php?a=post&...pid1918670

I tried you suggestion for style 0, and still, you are wrong. For style 0 using 2ms causes accel to be way too big, comparing to actual QL accel.

Considering style 1 - please explain why I should use 2 ms here. Again, with current constant of 8 ms I have mouse accel practically equal to one in QL.

You see, theories and hypothesis are very nice thing, but only practice and experiment can confirm that you are right. So write your own script, post here, and let's see which one is closer to reality - in other words, to actual QL implementation. :)))

it's easier for me to just fix your script than to explain it to you

http://www.funender.com/quake/files/injx/qlaccel.PIE

Interesting, let me try it...

Ok, feels quite similar to what I have now, although slightly different.

The only unclear moment is this division:

var.CL_MOUSEACCEL/var.SENSITIVITY

Why it is needed?

because the game will multiply the input by sensitivity. this line cancels out that multiplication, so you get:

B * (1 + rate * A/B)
= B + A * rate

Sir, your really inspired me for some work, so I decided to make small investigation here.

First, lets see at accel style set to 0.

Parameters in QL:
sensitivity = 2,5
cl_mouseAccel=0,25 or 0 (for accel done with QL and GlovePIE scripts correspondingly)
cl_mouseAccelStyle=0

Parameters in GlovePIE runtime:
sensitivity = 2,5
cl_mouseAccel = 0,25
com_maxFPS = 125

Lets imagine, that mouse was moved with following deltas:

dx = 31 (low speed mouse movement, although not very slow)
dy = 2

So, in QL following results will be produced:
rate = sqrt(mx * mx + my * my) / frame_msec = sqr t( 31 * 31 + 2 * 2 ) / 8 = 3,883056;
accelSensitivity = cl_sensitivity->value + rate * cl_mouseAccel->value = 2,5 + 3,883056*0,25 = 3,470764;

Final mx and my values produced by QL are:

mx *= accelSensitivity=31*3,470764=107,593684;
my *= accelSensitivity=2*3,470764=6,941528;

In my script + QL mouse handling, following results will be produced:

var.magnify = (1 + sqrt(var.Mouse1_deltax*var.Mouse1_deltax + var.Mouse1 _deltay*var.Mouse1_deltay) / 8 * var.CL_MOUSEACCEL) = (1 + sqrt(31*31 + 2*2)/8*0,25 = 1,970764

So final dx and dy values produced in the script will be:

var.magnify*var.Mouse1_deltax = 1,970764 * 31 = 61,093685 = 61
var.magnify*var.Mouse1_deltay = 1,970764 * 2 = 61,093685 = 4

And with final multiplication in QL:

mx *= cl_sensitivity->value=61*2,5=152,5
my *= cl_sensitivity->value=4*2,5 = 10;

As you see, it is way too big so my approach is wrong.

Now, in your script + QL mouse handling, following results will be produced:

var.dt = 1000 / var.framerate = 1000/125=8
var.QLframetime = 1000 / var.COM_MAXFPS = 8
var.m1 = sqrt(var.Mouse1_deltax*var.Mouse1_deltax + var.Mouse1_deltay * var.Mouse1_deltay ) = 31,064449
var.m2 = var.m1 / var.dt = 31,064449/8=3,883056
var.magnify = 1+var.m2 * (var.CL_MOUSEACCEL/var.SENSITIVITY) = 1 + 3,883056 * (0,25/2,5) = 1,388305

So final dx value produced in the script will be:

var.magnify*var.Mouse1_deltax = 31*1,388305=43,037455 = 43 (only integers here)
var.magnify*var.Mouse1_deltay = 2*1,388305=2,77661= 3 (only integers here)

And with final multiplication in QL:

mx *= cl_sensitivity->value = 43*2.5 = 107,5
my *= cl_sensitivity->value = 3*2.5 = 7,5

Conclusion: for cl_mouseAccel style 0 your approach nailed QL mouse accel perfectly, it differs from QL numbers only due to rounding errors (when I skipped rounding it was equal to QL results up to 6th digit after comma), and mine is wrong.

Now let's see at the case with mouse accel style = 1

Parameters in QL:
sensitivity = 2.5
cl_mouseAccel=3.2 or 0 (again, for accel done with QL and GlovePIE scripts correspondingly)
cl_mouseAccelOffset=2
cl_mouseAccelStyle=1

Parameters in GlovePIE
sensitivity = 2.5
cl_mouseAccel=3.2
cl_mouseAccelOffset=2

Lets imagine, that mouse was moved with following delta:

dx = 31 (low speed mouse movement, although not very slow)
dy = 0 (vertical movement is irrelevant here, so we can omit it altogether)

In QL following results will be produced:

rate[0] = fabs(mx) / (float) frame_msec = 31/8 = 3,875;
power[0] = powf(rate[0] / cl_mouseAccelOffset->value, cl_mouseAccel->value) =
powf(3.875 / 2, 3.2) = power (1,9375, 3.2) = 8,301823;

Final mx value produced by QL is:

mx = cl_sensitivity->value * (mx + ((mx < 0) ? -power[0] : power[0]) * cl_mouseAccelOffset->value) = 2.5* (31 + ((31<0)? -8,301823 : 8,301823) * 2) = 2.5*(31+8,301823*2)=119,009115;

In my script + QL mouse handling following results will be produced:

var.rate_x = abs(var.Mouse1_deltax) / 8 / var.CL_MOUSEACCELOFFSET = 31/8/2 = 1,9375;
var.pow_x = exp(3.2 * Ln(1,9375)) = exp(3.2*Ln(1,9375)) = 1 <-- LOL, I'm bad with math

But if we will correct above expression, it will become much better. Instead, we will use:

var.pow_x = var.rate_x ^ var.CL_MOUSEACCEL = 1,9375 ^ 3,2 = 8,301823

So final dx value produced in the script will be:

var.Mouse1_deltax + var.pow_x * var.CL_MOUSEACCELOFFSET = 31 + 8,301823 * 2 = 47,603646 = 48

And final mx value produced in QL will be

mx *= cl_sensitivity->value=48 *2,5=120 <<-- differes from QL results only due to rounding

In your script + QL mouse handling, it will produce following results

var.dt = 1000 / var.framerate = 1000/125 = 8
var.QLframetime = 1000 / var.COM_MAXFPS = 1000 / 125 = 8
var.new_offset = var.CL_MOUSEACCELOFFSET * ( var.QLframetime / var.dt ) ^ (1/(var.CL_MOUSEACCEL - 1)) = 2 * (8/8)^(1/(3,2 - 1)) = 2 ^ (1/2,2) = 1,370351
var.rate_x = (abs(var.Mouse1_deltax) / var.dt) )/ var.new_offset = 31/8/1,370351 = 2,827742
var.pow_x = var.rate_x ^ var.CL_MOUSEACCEL = 2,827742 ^ 3,2 = 27,836051

So final dx value produced in the script will be:
var.Mouse1_deltax + var.pow_x * var.new_offset = 31 + 27,836051 * 1,370351 = 69,145160 = 69

And final mx value produced in QL will be:
mx *= cl_sensitivity->value=69 *2,5 = 172.5

So for accel style 1 both my original approach and yours are wrong. But after doing small correction to my script it starts to work in a correct way. \o/

It would be good to do some analysis of all these 3 functions on the interval from 1 to 1000, comparing values they produce inside given interval. Also, it would be useful to analyze first derivatives of these functions, although this work will require much more effort.

And BTW, how did you managed to get PhD in 23? :)

Edit: what a nice 1000th post \o/

you made a mistake here:

var.new_offset = var.CL_MOUSEACCELOFFSET * ( var.QLframetime / var.dt ) ^ (1/(var.CL_MOUSEACCEL - 1))
= 2 * (8/8)^(1/(3,2 - 1)) = 2 ^ (1/2,2) = 1,370351

the correct:
new_offset = 2 * (8/8)^(1/(3,2 - 1)) = 2 * 1 = 2

which gives the correct answer for style 1.

your code only works if the script/polling is running at 125Hz, as you've hardcoded the 8ms frametime. it also assumes QL is using the same frametime.

my code assumes neither.

if you turn down your framerate in QL (e.g com_maxFPS 30), the style 1 mouse accel will change dramatically (try it). your code doesnt take this into account.

and i've not finished my PhD yet.

Oh snap...

So, almighty injx, can I attach your script to this post?

yes, of course.

Thank you, and sorry for being a douche at the begining (you know what I mean).

Glad I posted it here w/o any serious checks - otherwise I would found my mistakes and it took me to solve them much longer on my own.

no worries, it's great that you are contributing something for mouseaccel users.

scuse me mr PhD sir... would you be so kind to tell me if this is correct?

fov scaling factor = arctan( tan(zoomfov * PI/360) * height/width ) * (360/PI) / 75

also I give [+]es

that's how q3 scales sens/accel with +zoom.

it is also what cg_zoomSensitivity 0 does in ql, but in ql the height/width is always 0.75, as fov and zoomfov specify the central 4:3 fov on your screen, not the total fov.

however, it's obviously broken, as it doesnt take your current fov into account.

the corrected version is cg_zoomSensitivity 1, which gives this factor:

arctan( tan(zoomfov * PI/360) * 0.75 ) / arctan( tan(fov * PI/360) * 0.75 )

thanks.

accel is evil

btw you forgot bout senscap

accel is a blessing. You just need to get handle of it. :)

No, it's pretty evil.

accel is a blessing. You just need to get handle of it. :)

No, it's pretty evil.

No, it's pretty evil.

No, it's pretty evil.



Oh wai...

accel is a blessing. You just need to get handle of it. :)

could you do this kind of script for ql to use sens/accel from q3.Like the one from your client http://esreality.hexus.net/?a=post&id=1565939 <---- this truly was a blessing!!

Cant get that feeling from there, even if theire both "raw" etc.And the cl_mouseacceloffset doesent do the job :|

Please forget about my previous answer, my script contained some errors, which were revealed during communication with injx. Some of them correctable (for accel style 1) some are not (accel style 0)

I think soon I will be able to provide you with correct file for both accel styles. :)

style 1 is flawed so don't try to copy it rather fix it! :)

How it is flawed? For me it works perfectly - pinpoint precision during small movements, blazing fast moves during fast. And I have a PC which can ran demo four at 400 FPS, so I do not care about FPS drops. :)))

c/p from my post in the ql bug report forum

1. The equation uses frames to calculate the acceleration. Downside is, if your fps drop, your mouse input will get VERY inconsistent.

2. For some reason the directionality of crosshair movement is dependent on mouse directionality AND speed, while it should only be dependent on directionality.

3. The feel of accelstyle 1 depends on your sensitivity also, which means a change in sensitivity will also change the accel.


the description might not be very accurate but it adresses als flaws with style 1 I heard of

Basically, you have the tool, you see the way - now you can implement whatever accel you want.

And do not forget to show result to injx. :)))

haha, u guys are nuts. glad i asked :)

Thanks, I guess now I should be able to play Portal with quake3 mouse accel?

I think yes. Just try the script and tell me your experience. :)

1st why is it freaking out when using on the desktop?

2nd do i have to set up my ingame sensitivity into the script for 1:1 scaling or is it a seperate multiplier?

3rd its just working awesome ingame good work, wsw ql and vq3 are now exactly the same and i'll try to use it on games like cs,too.

4th does this script differ from the mouse accel script used to promode and cpma? when not, why its feeling somehow more responsive?

>>>>1st why is it freaking out when using on the desktop?
Huh? What do you mean? :)

>>>2nd do i have to set up my ingame sensitivity into the script for 1:1 scaling or is it a seperate multiplier?
If you are talking about quake games and SENSITIVITY cvar, then yes. For other games, just set their sensitivity in centimeters per 360 equal to what you have in Quake.

>>>3rd its just working awesome ingame good work, wsw ql and vq3 are now exactly the same and i'll try to use it on games like cs,too.
Gooood! In CS:S its worked fine.

>>>4th does this script differ from the mouse accel script used to promode and cpma? when not, why its feeling somehow more responsive?
Dunno. Algorithm is slightly different, but should produce the same numerical results.

dindt get the

/* can be set to any value up to 500*/
/* DONT set higher than your polling rate or you will get incorrect scaling */
/* This is the framerate of the script, not the framerate of the game */

my polling rate is 1000 so i cant set it higher than 500?

Actually, you can set to whatever value you like. :) I use 500 despite the fact that my mouse has 125 refresh rate.

1st the mouse pointer its not moving really and then its just switching sides from the left of the desk to the right and back and so on and on.

2nd wtf ok ill do it as you command but it somehow worked ok when i left it on 1 but maybe thats why its not exacly the same result as in ql itself.

btw somehow its not working in source games, same bug as on the desktop

Attached Misc File: 78368-Desktop.rar (3KB)

Send me your QL config and script modified by you, and I will look at them both. Maybe I will be able to see what is wrong.

And if it doesn't work on desktop, it won't work everywhere else. :)

Ad 1: Loaded your script, got the mouse pointer stuttering in desktop. Had to reload system to cure it. After reboot, your script worked fine. During development of the script, had such problem several times, had to reboot always. Don't know what is the reasons, I'm not an author of GlovePIE, but it is definitely something related to its programming. :)

In you script you have com_maxFPS set to 1000. I think it should be set to FPS you really use in Quake (usually 125).

If you use 1000hz with the mouse you may be screwed, cause GlovePIE author stated that it doesn't work good with PIE.FrameRate set above 500. But on my system it works (maybe because of very fast processor, dunno). So you can try setting PIE.FrameRate to 1000 too, but don't be surprised if it won't work.

BTW, what mouse with what DPI settings are you using?

nerd

thanks for you support dude

but btw just wsw and vq3 are running with this tool for me, i allready tried ql itself, css, l4d2, q4max, mw2, all of them the same bug as on the desk.
when i tried ql i thought ok its maybe locked to the desktop mode because of the browser and they use another input, but as you see it fails at many games :(((
wanna play q4 with it that was my wish.

GlovePIE version is 0.41? What OS are you running? I run it on Win 7 x64 Ultimate.

Did you try to run mouse at 250 hz and PIE.FrameRate set to 500?

I wanted something like this back in the day when I used accel. nice anyway

lollz to the ballz huh? you got me, i was using v0.43! working good on vista64 now, too!

does this work on W7? i tried and it didnt work, it said "running" and all but accel just doesnt exist.

I developed it and run it now on Windows 7 64 bit Ultimate. So yes.

The first thing you should check is version of GlovePIE. It should be 0.41 STRICT.

Also, attach here your modified script, so I can look at it.

got it working to some point, but it said that my variables werent acceptable float numbers... like sensitivity 1.6 and accel 0.075

Please share the script modified by you with me. :)

here you go http://jump.fm/WORYP

var.CL_MOUSEACCELSTYLE = 0

why it cant be 1?

I'm having big problems with this as well. My cursor spazzes out on the desktop, hugging left or right. I tried a reboot and that didn't seem to help matters, apologies if I've failed to notice a fix for this if it's in the thread somewhere, I had to skip over the coding bits as I don't understand that =). Would really like to get this working though, so if there's any information you need from me to discern the problem let me know :E.

The first thing to check is GlovePIE version. 0.41 strict. :)

Ok, I tried running it with .41 and I get a different problem when I run the script. This time, the mouse gets stuck in one spot on the desktop. If I move my mouse in any direction, the cursor jitters but stays in one spot.

I have similar problems when I have several versions of GlovePIE running in the memory. But overall, the tool is far from perfect and looks like author do not support it now... :(

Ah, so are you planning to revise this project at all maybe in another platform? It's an awesome idea, I encourage you to fix everything!!! :D

This program is closed source. So answer is no. :(

Could you try to download 0.41 from here?

http://sites.google.com/site/carlkenner/asdfghjkl

same here, any solution? only workaround is setting var.CL_MOUSEACCELSTYLE to 1, but i want 0

nothing I have figured out, I gave up.. I'm no coder or anything :-E

If you will attach your script here, I will look into it and try at my local PC. Maybe I will find out smth.

How to make time delay in GlovePIE script ?

Could you decribe what effect do you want to achieve?

I want to make that after 10ms (1 of 100 FPS) directinput of mouse is changed, not immediataly, because this script will be for cs 1.6 and what I know (virtual) crosshair (in half life based games) is going back to center after displaying last frame.
And I'm trying write special script because I've read that cs 1.6 has hardcoded limation of mouse DPI which is 800 CPI(DPI).

this is so cute, I have this thread favorited and now I get a reply notification for any post in this thread.

So, how exactly does this Acceleration work compared to the normal 4 segement windows acceleration?

Sorry, but I cannot compare the two. :)

My problem is that I want some mouse acceleration with more than just the 4 segments / 4 infliction points.

So how does this work - if u can compare?

Sorry, I have no time for this now. :)

Cant you just give me a little insight on WHY I shoul change to this?

Personally I think that acceleration is A BLESSING, like you've said. I just don't like the sudden speedshift when having the normal-windows-4-segment acceleration

SO

does this QUAKE-LIVE acceleration have ANY difference compared to that? Does it have smoothing acceleration or "strange linear" curve acceleration?

Any info???

If not, then I will consider trying it or not.

Although, you can read some (probably outdated) info here:

http://msdn.microsoft.com/en-us/windows/hardware/gg463319

Does this also work on the desktop? It didn't seem to do anything, except with cl_mouseaccelstyle 0, which broke the mouse movement.

Frankly speaking, GlovePIE is less then optimal platform for such things. For my personal usage I already coded small mouse filter driver with required accel settings and use it exclusively. It's quite crude though and its installation is a one big PITA...

A driver that gave quake accel on the desktop would be pretty awesome.

why don't you put it up on github or something?

Cause i'm sure that it is not ready for any distribution at all.

what? I'm not sure what you mean by distribution, but github/sourceforge/googlecode are for publishing source code, not for 'distribution' in a normal sense of the word. if it exists, it is ready.

I've been using this for a long time. Mostly when I play tf2. But it really doesn't feel exactly same as ql acceleration. It feels like there's a slight delay and it's not as smooth as ql accel.

If someone knows a better way to get ql-like acceleration on other games (in tf2 for example) feel free to tell me.

As far as I know, Valve updated their mouse acceleration but it's still fps dependant. It also has different cvars compared to ql so I don't have any idea how to calculate stuff to get similar acceleration. If it's even possible.

moudrv

http://www.esreality.com/index.php?a=post&...pid1581774

I just quickly tried this and it feels a lot better.

I used this formula:
MouseAcceleration = cl_mouseaccel / sensitivity(q3)
that you mentioned in that thread, to set my acceleration. But isn't q3 acceleration a bit different compared to ql acceleration?

its the same as long as all the (new) settings are on defaults.

Please HELP!

I installed the "mousedrv" and followed the instructions untill i installed the driver for my mouse... Now it isnt worknig! How do I fix this!

Thank you!

Sorry, I'm not an autor of mousedrv. So I cannot help you there...

Okay, I am trying to download your script - but - I don't really seem to understand how I get the exact/correct version of GLOVEPIE (The glovepie.exe) i suppose, since the link in your post says "account is suspended"

Where to download?

I think this one can be trusted:

http://carl.kenner.googlepages.com/GlovePIE041.zip

I have a problem editing the CL_mouseaccel

It seems to only be editble in increments of 1.

This means when I set it to like 1.5, it starts an error:

"1.5 is not a valid value"

I have GlovePIE 4.1 and it works without any problem, allowing me to set it for any value.

As I said, GlovePIE is less then optimal platform for such things, and recently author stopped its development.

I personally thinking about making my mouse filtering driver public, but I cannot guarantee it will happen any time soon. :(

Works for me to when i reboot the program (lol)

I have another issue - is it possible that the program causes lagspikes ?

Never had any lagspikes because of it. But I have 4-core i7 processor...

Is there any other program that I can run the script with?

Because I really get a lot of annoying spikelags.

No. Because it is written solely for GlovePIE.

Change usb port and reboot.

http://www.esreality.com/index.php?a=post&...pid2068344

Anyone know why when I set CL_MOUSEACCELSTYLE = 0 I get this in paint when drawing diagonal lines?

http://s13.postimage.org/56gm4052f/accel.jpg

Which mouse, mouse rate and resolution do you use?

G400
500hz
1680 x 1050

I mean, like, mouse resolution. :)

400dpi

Ok, will play with the script today trying to reproduce it, but in the meantime, if you have another mouse with similar characteristics (400 DPI 500 hz), can you test script behaviour with it?

Edit: and welcome to ESReality! :)

Thanks.

I was able to reproduce it using a IME3.0

And last, but not least - I need the exact copy of your script with your settings to be posted here. I think I already on to something, but I may be wrong.

http://www.sendspace.com/file/pkj1bu

could you do this for halo pc

Have you tried it there? :)

any chance you can update this and add a senscap var? :)
great work anyway.

I recently attempted to use this script and did not have immediate success. After learning how to fix it on my system, I had learned enough about GlovePIE to modify the script to add all of the current quake live acceleration features. (including senscap, offset and power)

http://drok-radnik.com/junk/glovepie/

From my testing over the last couple of days, it feels accurate to me on the settings I have been using. I would love to see what you guys think of it when replicating your own favourite settings.

Also, if anyone like injx or sk4ut (or anyone technically inclined really) wants to check over the code, it would be appreciated. I did remove/change a lot of things and I hope I didn't break anything important.

The instructions in the first post should be enough to get you up and running, as the process is exactly the same.

This doesn't even look close to correct.

see here for some info on the current accel: http://www.esreality.com/post/2087688/more-in...pid2087765

Edit:

Try this (not tested):

edit: my post got approved after your edit.
see below

Thanks for your input. I tested the script for you and only had to make a couple of fixes

line 25: var.currtime = removeunits(TimeStamp)
line 47: var.accelSens += math.power( var.rate, var.pow )

I'll give it a good playtest tonight. Thanks a lot!

Thanks.

It may be simpler to replace all this:


with this:

// calculate frametime in milliseconds
var.dt = Delta(TimeStamp) * 1000



The documentation says that TimeStamp is in seconds, so I'm not sure that RemoveUnits is needed, or if it even has any effect in this case.

Bla bla bla ....

Nerds, just dont use acceleration :D

Jesus Christ i would pay some good money for a good driver/software that work with every mice to add accel... or at least with mice that dont need driver ei : Zowie mice.

Google QL accel driver, ive been using that when i play reflex.

http://accel.drok-radnik.com/ ?

It is writen it does not work in winXP, i will upgrade to win10 soon but it looks not to work in win10 too. Maybe i will take a temporary key for win7 for 10 bucks but i will need to use win10 for DX12 sooner or later.

What OS are you using ?

Yes that one. I'm using win 8 but the problem is that the driver is not signed and you need to be in test mode in order for it to work. It can take a while before u get it running properly.. Check this https://www.youtube.com/watch?v=KORL144_co8

Kovaak mentions somewhere that they might push to get it signed for windows 10, but it would require some donations to get it done. As far as I know he made the GUI for the driver. The GUI is very useful to get a visual representation of how your accel curve looks like. Even if you don't get the driver to work.

I had this video already checked but thanks. The guy has an amasing voice :D. How much would they need? I mean their work is definitly valuable, i wish i had computer skill to code it myself as a hobby or even make it a software and sell it.