[mitsubishi]

After great help by p5yc0runn3r (I've no much idea about s_ stuff), files are updated with better defaults for dmaEX: com_soundmegs defaults to 32, if it's below 16 (in many old configs) it sets it to 16.

Additionally, an internal dmaEX sanity check involving mixahead and prestep is adjusted.

--

potential glitch on mouse keys detected; keys may be repeating wrongly in certain conditions, investigating.

--

potential glitch identified. testing and uploading incoming. apparently keypresses must be remembered if they come too fast for the game


--

repetition glitch persists; investigating. closer now; it appears to occur when 2 keys are pressed simultaneously. their 'up' event may be lost. hm..

--

aha! solution.

This post has been edited by mitsubishi: 17 July 2010 - 08:21 PM

[mitsubishi]

ok, Mouse Buttons on Raw Mode are fixed again.

Now using a more direct method; it should be lower latency and it avoids quirks I had noticed.

--

The "Com_QueueEvent overflow" spam sometimes is a normal nuisance due to the simplistic implementation that I will avoid in a later update.

This post has been edited by mitsubishi: 17 July 2010 - 09:05 PM

[Mod ObScUrE]

Original ioUrT can handle s_mixprestep 0 so it's better optimized currently?
Before the 'go back to MainMenu' issue was fixed it worked flawless on s_mixprestep 0
so is there a way to get the performance back or improve it on another way on my system it's a huge difference.

-
newest build has an issue with Mouse4 and Mouse5 button.

Mouse4 works
but mouse5 executes the action from mouse4 and not that what was bound to mouse5.

This post has been edited by ObScUrE: 17 July 2010 - 09:19 PM

[mitsubishi]

^fixed.

only the 170710-6 files may work properly now, and that if, i'll fix later.

This post has been edited by mitsubishi: 17 July 2010 - 09:30 PM

[Mod ObScUrE]

There is a difference from MainMenu to game sound.
The MainMenu seems to run with 44100Hz I get the distortion there but ingame it works without distortion on s_mixprestep 0

Oh you changed the default value on s_sdlspeed 0 [from 22050 to 44100].
I was thinking you had set a default value for s_sdlspeed to 44100 :-)
-
It works all perfect now and raw mouse input does a well job.

This post has been edited by ObScUrE: 18 July 2010 - 02:32 AM

[mitsubishi]

Yes, it does appear ok (on the "170710-6" builds). Now to avoid a flooding of event queue..

This post has been edited by mitsubishi: 18 July 2010 - 09:03 AM

[~SG~Juno]

So i used both 170710 .exes
Its much better.
But there is still random stop shooting. Its better cause its not so often. Now i can play on public servers... definitely not CW/PCW.
And steel i feel something like lower firing rate which is almost on edge of perception. Im not sure if ita exists, but feel like it is.

[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