[p5yc0runn3r]

versus666, on 26 July 2010 - 05: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 - 10: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: Yesterday, 02:41 PM

[QA RS| SubJunk]

Awesome, Mitsu.
Do you have any information on how it compares with Ventrilo, TeamSpeak, Mumble, ImpTalk, etc.? Have tests been done?