[p5yc0runn3r]

Mitsu, about the negative acceleration thing...I think I have an idea that you could try.
You are calling your modified SDL with raw mouse capture (WM_INPUT) from the ioq3-urt executable.

This could lead to buffer underflow where more data is read than given to the application. I suggest you have 2 variables for x and y and when you receive WM_INPUT and ioq3-urt did not call you yet from a previous WM_INPUT, you add the values to the x and y variables. Then, when ioq3-urt calls SDL, the x and y variables are given and then set to 0 again.

This will 'interpolate' the values in case the application is slower than the WM_INPUT messages.

[mitsubishi]

That's what it does. WM_INPUT is about 1000Hz here [while game 125] so the vars are "+=" till read and 0'ed. Well, they should be "+=" anyway since the client isn't in sync. I was even worried in case the whole process is not thread safe (needing some kind of 'trigger' var to protect it) but it seems to be ok with just "+= and then zero".

(At first there wasn't even "+=", just "send to queue", but it was a hell to protect it from queue floods:P) [queue floods due to loading screens, not the normal process itself.]

(the keys are similarly added in arrays)


--

Quote

Even if it's about mouse acceleration change between modes don't cl_mouseAccelOffset and cl_mouseAccelStyle can be used to fine tune ?

Negative acceleration here is not a feature, it's a quirk. It's not an easily quantifiable acceleration (to just be able to counter it with a number or just a calculation). The cursor (internally) just hits a wall and it loses information. The programmer can not know easily what exactly was lost so they can't easily counter it. If it was the case, there wouldn't be negative acceleration to begin with.

Well, that's the theory at least, I haven't looked at it first hand.

versus666, on 26 July 2010 - 03:01 PM, said:

won't get any advantage from RAW

You missed the basic paragraph about the feature: It avoids cases of negative acceleration but also is higher resolution/lower latency in cases. This is according to Microsoft.

This post has been edited by mitsubishi: 26 July 2010 - 04:07 PM

[versus666]

mitsubishi, on 26 July 2010 - 03:41 PM, said:

That's what it does. WM_INPUT is about 1000Hz here [while game 125] so the vars are "+=" till read and 0'ed. Well, they should be "+=" anyway since the client isn't in sync. I was even worried in case the whole process is not thread safe (needing some kind of 'trigger' var to protect it) but it seems to be ok with just "+= and then zero".

(At first there wasn't even "+=", just "send to queue", but it was a hell to protect it from queue floods:P) [queue floods due to loading screens, not the normal process itself.]

(the keys are similarly added in arrays)


--

Negative acceleration here is not a feature, it's a quirk. It's not an easily quantifiable acceleration (to just be able to counter it with a number or just a calculation). The cursor (internally) just hits a wall and it loses information. The programmer can not know easily what exactly was lost so they can't easily counter it. If it was the case, there wouldn't be negative acceleration to begin with.

Well, that's the theory at least, I haven't looked at it first hand.


You missed the basic paragraph about the feature: It avoids cases of negative acceleration but also is higher resolution/lower latency in cases. This is according to Microsoft.

I understand very well the problem with 'negative acceleration'.

What's the point of trying to use RAW with a low quality mouse like a DELL, 125Mhz USB polling rate, 800 DPI at best ?
Whatever the possible improvement in the processing of mouse input, *IF* the mouse allow the RAW method, it would be negligible given the specs of the mouse, don't you think ? And it doesn't produce 'negative acceleration' whatever the method used.

High DPI mouse have problem with some weird sensitivity settings on classic method ? Use RAW !
Use RAW and want accel ? Fine tune with cl_mouseAccelOffset and cl_mouseAccelStyle !
Have a low DPI mouse and can't use RAW ? Use classic method and don't bother !

I really don't see the problem.
Ok, having a method that sometimes don't works on competition mouse is a but frustrating but sometimes perfection is not possible, maybe it's just the method which is flawed and does not fit to extreme hardware input.

This post has been edited by versus666: 26 July 2010 - 04:39 PM

[p5yc0runn3r]

versus666, on 26 July 2010 - 04:38 PM, said:

I understand very well the problem with 'negative acceleration'.

What's the point of trying to use RAW with a low quality mouse like a DELL, 125Mhz USB polling rate, 800 DPI at best ?
Whatever the possible improvement in the processing of mouse input, *IF* the mouse allow the RAW method, it would be negligible given the specs of the mouse, don't you think ? And it doesn't produce 'negative acceleration' whatever the method used.

High DPI mouse have problem with some weird sensitivity settings on classic method ? Use RAW !
Use RAW and want accel ? Fine tune with cl_mouseAccelOffset and cl_mouseAccelStyle !
Have a low DPI mouse and can't use RAW ? Use classic method and don't bother !

I really don't see the problem.
Ok, having a method that sometimes don't works on competition mouse is a but frustrating but sometimes perfection is not possible, maybe it's just the method which is flawed and does not fit to extreme hardware input.

I really think the actual SDL implementation is flawed (not Mitsu's fault BTW). If the input is more coupled in the main module, it should be a different story. I have implemented this in the vanilla non SDL version (with VBO) of Twentyseven and I really do not have any problems and also I can aim more precisely.

[mitsubishi]

versus666, come again when you have read this isn't only about negative acceleration.

This post has been edited by mitsubishi: 26 July 2010 - 07:52 PM

[versus666]

mitsubishi, on 26 July 2010 - 05:29 PM, said:

versus666, come again when you have read this isn't only about negative acceleration.

Don't get it wrong, I try to help, sorry if I upset you.

[mitsubishi]

Did you read this isn't only about negative acceleration?

:P

[p5yc0runn3r]

mitsubishi, on 27 July 2010 - 09:04 AM, said:

Did you read this isn't only about negative acceleration?

:P

I think the RAW mouse feature needs its own thread...

[mitsubishi]

it has.

[mitsubishi]

Now included: In-Game Voice (VoIP) support for servers that support it (/cl_voip 1; ioq3 server: /sv_voip 1). Full instructions are here. Bind a key to +voiprecord to talk, '/voip muteall' to mute all. It requires OpenAL and a high /rate.

cl_voip is 0 by default and if it's enabled the console will be slightly spammy about its requirements, i.e. "I need OpenAL" and "I need high /rate" (in bright yellow) if they're not available. If it's initialized reasonably, i.e. it got a recording device on OpenAL, it will print '* VoIP is initialized'.

Packages now include OpenAL-soft libraries for all windows builds because a) they sound good and they offer basic binaural audio b) An OpenAL library is required for VoIP. [They are also compiled for sse2 and mmx separately; overkill ftw.]


The reason it's not enabled by default is that it would be spammy in console by default about OpenAL and /rate requirements. This may change if they become the default..

--

ut4_iran3 crash on 'bumpy' is workarounded (similarly to one related to harbortown).

This post has been edited by mitsubishi: 29 July 2010 - 02:41 PM