Urban Terror Forums: Optimized .exe; builds of ioq3 engine - Urban Terror Forums

The weapon firing is fixed for me, gj.

Solitary, on 19 July 2010 - 11:01 AM, said:

Nice to hear.

versus666, on 19 July 2010 - 03:34 AM, said:

nice.


-------------------------------------------------



After also consulting the author of dmaEX p5yc0runn3r:

To allow fine tuning for players the following var is added:

/s_smpRepeat default: 16 //Sample Repeat allowed; this number is doubled for Listener originating sounds (e.g. own automatic weapon firing).

The vanilla equivalent of 4 was tripled to 12 on the initial fix binaries. Since it appears to be a relatively safe process it's been increased a bit.

It is forced to a minimum of 8 since the vanilla default was effectively buggy for UrT; /timescale 1 weapon firing of g36 and m4 for example were partly dropped in all clients on all OSes.

It can go as high as MAX_CHANNELS (96) which is effectively like not having the check at all.

It is forced to a minimum also because it's theoretically exploitable otherwise.

Example case: on the minimum setting of 8 now LR300 spamming (on a quiet environment at least) needs timescale of at least 2 or 3 to lose sounds. On the default or higher settings it's virtually impossible to drop sounds.

--

It doesn't affect CPU load; the assumption is such a process existed to begin with for avoiding spamming of sounds that fill up all channels due to map or gameplay quirks.

This post has been edited by mitsubishi: 19 July 2010 - 02:14 PM

So, after all 190710 (not MMX yet) seems to be ok for me.
Even if i feel like whole game is a bit slower but it can be only feeling.
Now no problemos with sound, firing rate or stop firing. :)
So good job.
Im not sure if i can recognize dmaEX now.. may be later.
openal and ikalizer is to 0
Thx fate. :)

EDIT.
There is info on startup in console:
using dmaEX or basic audio

This post has been edited by Juno: 19 July 2010 - 06:13 PM

ty Juno, nice to see it's working fine on dmaEX / base audio (the default).

--

the full 'documentation' on the new var/solution:

"A base audio (and by inheritance dmaEX) issue involving dropped sounds when attempting to play them simultaneously, is tackled with tuning it with the /s_smpRepeat client var. It effectively allows a higher limit for simultaneous playback of the same sample. This solves the issue of having dropped sounds e.g. when auto firing a G36 or M4 which was giving the illusion that rate of fire was lowered (while only the audio that was heard was erratic). The issue was apparent on all clients and systems though it is less pronounced on older versions of ioquake3 (such as the one on iourt). The new var's default limit of 16 is 4 times higher than the hardcoded vanilla one. There is a minimum limit of 8 since the previous one (4) was effectively buggy. Examples: in a quiet environment, auto firing a LR300 now can lose sounds only on timescale 3 or 4 when using the minimum allowable of 8. On the default of 16 or higher it's virtually impossible. Notice the limit is internally doubled for sounds originating from the Listener (like the aforementioned firing examples). It doesn't affect CPU load; such a process existed to begin with possibly for avoiding spamming of sounds that fill up all channels due to map or gameplay quirks."

--

The quirk tackled is probably more pronounced for sounds made by others (since their audio limit is not doubled).

This post has been edited by mitsubishi: 20 July 2010 - 10:54 AM

Well... seems like i can play this ioq3_urt on public servers.
But its absolutely impossible to play CW/PCW. :/
Games is warping/lagging especially during recording demo.
It looks like fps drops. But ingame fps counter doesnt show any fps drops.
Ill try again today at home to exclude any other influances like internet or PC issues.
May be yesterday was bad day for testing anything. :)

I am having a problem with in_rawmouse 1 it worked at first then later it just randomly STOPPED my mouse quit responding at all when i have rawmouse on or when i even change in_mouse variables any ideas ?

ioq3-urt updated with a more "live" version of in_rawmouse. One can now do /in_rawmouse 0 and 1 during a run with no in_restart etc. needed. It's also a bit smarter internally, disabling windows' raw device when not needed which might have minimal advantages.

Notice the functionality is generally "live", i.e. in the middle of the game it does take effect (to go from raw to non-raw and back) immediately.

blizakster, on 20 July 2010 - 01:15 PM, said:

ok, this might be important. Can you give more details? Windows version, mouse, when did it stop, did it stop for Windows in general or just game, did it fix after you restarted game etc. Did it happen fast or after hours? etc.

Also, check the version now available. It slightly changes the way /in_rawmouse works (it is able to 'live' do /in_rawmouse 0 and 1 without needing restart or /in_restart), though I don't expect it to be much different in that case.

on that old version i told you i was going back to for the /disconnect and bumpy issue, i'm still getting the occasional reload glitch.

n4n3rz, on 21 July 2010 - 06:24 AM, said:

On what weapon does it happen? Can you reproduce it easily or does it happen extremely rarely? Do you do 'lots of stuff' when it happens? etc.

I noticed there is a new message in console, it says:
WARNING: NET_IP6Socket: bind: WSAEADDRINUSE

I restarted the game and the error didn't happen again. Maybe it was a false-positive.

Edit: Also, would it be possible to apply mouse sensitivity to the menu screens? My mouse is running at 5600DPI and with the new HD mouse support it's hard to click things in the menu; the slightest movement makes the cursor fly

This post has been edited by SubJunk: 21 July 2010 - 07:04 AM