[mitsubishi]

^ i think that's the audio cutting a bit; check the number on the bullets, it may still go fast. (it may not occur on ikalizer)

(easy to notice on G36 without silencer on auto)

I'll investigate further. (and i should ask dmaEX' author)

If it fixes on lower optimization options on gcc it may need it.

--

I investigated further and details is in dmaEX's thread; it doesn't occur in ikalizer or openal, the actual bullets always go fast (only audio cutting off) and dmaEX settings don't fix it or lower optimization options.

--

vanilla base sound issue, also occurring without dmaEX. It doesn't occur on ikalizer or openal.

--

wow, I went back to 2 March 10 and it still occurs.

--

bingo; it also occurs on binary from ioquake3.org (not iourt)

--

Off topic to this reply: I just upgraded all windows files with a cleaner version of raw input code. It does not spam 'queue event overflow' after loading screens this time if you move the mouse during the loading screen. I'd better not bump the thread about it (it's spammed enough already about this feature).

--

I timed it and it definitely is an audio issue; actual bullets definitely go down in iourt and ioq3 at the same time.

--

I'll be investigating audio sample-number etc. vars.

--

on raw mouse motion again: i'll update them later to not move the game screen when unfocused (that was silly). -- done.

--

important memory leak fixed. 190710 files are now good.

--

ok mouse motion on raw doesn't ninja some moves after returning from an unfocused game.

now with that base ioq3 sound issue ..

This post has been edited by mitsubishi: 19 July 2010 - 12:22 AM

[mitsubishi]

major, major, major, major fix, involving dmaEX and base audio

audio is not lost anymore e.g. when spamming an auto. It gave the impression that rate of fire was slow but it was only audio that that was slow or lost, actual rate was fine.

the setting that fixed it is still experimental but I was able to see the problem reproduced and fixed on an old and a new computer with different hardware.

and i believe it's also confirmed on linux. -- yes, done and confirmed there too. the issue was universal and comes from ioq3 vanilla.

--

zomg, it also appears on iourt though it's harder to reproduce there; though put g36 on timescale 2 and auto and it's easily there.

This post has been edited by mitsubishi: 19 July 2010 - 04:16 AM

[versus666]

mitsubishi : Jeez ! When do you sleep ? You are at least as productive as a small mid-east country !
Confess you're trying to take over the world ! ^^

Thanks for the hard work, you're amazing, really.

EDIT : So far no more variable rate weapons sounds, that's nice ^^

This post has been edited by versus666: 19 July 2010 - 04:10 AM

[GlaD-Solitary]

The weapon firing is fixed for me, gj.

[mitsubishi]

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

The weapon firing is fixed for me, gj.

Nice to hear.

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

So far no more variable rate weapons sounds, that's nice ^^

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

[~SG~Juno]

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

[mitsubishi]

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

[~SG~Juno]

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. :)

[blizakster]

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 ?

[mitsubishi]

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:

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 ?

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.