pouët.net

Go to bottom

Getting into 4k demo making

category: code [glöplog]
Quote:
in recent Win10 versions it's not sample accurate anymore

By "accurate" do you mean in resolution or do you mean in drift? The latter is bad, the former I don't mind.
added on the 2021-09-06 10:06:57 by Gargaj Gargaj
I mean resolution. It's definitely not enough anymore to get smooth 60fps out of it if you're using it as clock source directly.
added on the 2021-09-06 10:28:17 by kb_ kb_
Quote:
I discovered that WASAPI (in shared mode at least) requires that you use the device's sample rate

There's a flag starting from Windows 7 to use an internal resampler. AUDCLNT_STREAMOPTIONS_MATCH_FORMAT, I think.
Quote:
There's a flag starting from Windows 7 to use an internal resampler. AUDCLNT_STREAMOPTIONS_MATCH_FORMAT, I think.


No, it's (AUDCLNT_STREAMFLAGS_AUTOCONVERTPCM | AUDCLNT_STREAMFLAGS_SRC_DEFAULT_QUALITY), and you do not set AUDCLNT_STREAMOPTIONS_MATCH_FORMAT.
added on the 2021-09-06 14:19:58 by manx manx
Quote:
I mean resolution. It's definitely not enough anymore to get smooth 60fps out of it if you're using it as clock source directly.

So the people using the FMOD timer get the last laugh after all?
added on the 2021-09-06 15:32:49 by Sesse Sesse
Someone will laugh if the FMOD timer is used in a 4k intro anyway.
added on the 2021-09-06 16:32:54 by absence absence
Quote:
It gets worse: If you're using DirectSound, do not use GetCurrentPosition() for timing. DirectSound has been just a wrapper API for some time now, and in recent Win10 versions it's not sample accurate anymore (no idea when that started but I get a 100% repro rate here over all machines I tried - old FR intros/demos decidedly stutter a bit now).

I did an experiment with different timers, looking at differences from one frame to the next:

waveOut position: Very accurate, rarely off by more than 0.5 ms.
DirectSound position: jumps 10 ms at a time.
DirectSound position with DSBCAPS_TRUEPLAYPOSITION: As waveOut.
timeGetTime after timebeginPeriod(1): 1 ms precision.
GetTickCount: Jumps 15 or 16 ms at a time.

So I guess the conclusion is: Use waveOut, or set the DSBCAPS_TRUEPLAYPOSITION flag (available since Vista).

The result was the same regardless of framerate (tried 60, 100, 120 and 144) and samplerate (tried 44100, 48000 and 123456).

Running Windows 10 20H2.
added on the 2021-09-06 22:45:48 by Blueberry Blueberry
This actually makes a lot of sense then. DirectSound is wrapped around WASAPI which has a default buffer size of 10ms, and they probably added the flag to minimize GetCurrentPosition() overhead (kernel mode transitions probably) and made everything suck in the process, hooray.
added on the 2021-09-07 00:50:15 by kb_ kb_
It would have been nice if DSBCAPS_TRUEPLAYPOSITION were the default for pre-Vista binaries, yes. (There's stuff in the PE header and manifests for version numbers, right?)
added on the 2021-09-07 00:54:23 by Sesse Sesse
Quote:
I did an experiment with different timers

Thanks a lot for the research! <3

Quote:
There's stuff in the PE header and manifests for version numbers, right?

The fact that Windows ignores these is happily exploited in demoscene packers (and god knows what other software too), though...

Then again, you're completely right that DSBCAPS_TRUEPLAYPOSITION should be the default.
added on the 2021-09-07 12:13:14 by KeyJ KeyJ
Should it be though? I mean how often does an app that's NOT a demo need that extra accuracy?
added on the 2021-09-07 12:32:24 by Gargaj Gargaj
I still think that until recently the full accuracy was the default - at least I can't remember that our demos were stuttering with Windows 7/8, and it's pretty obvious now :/

(anyone got an old Win7 machine lying around for testing perhaps?)
added on the 2021-09-07 12:40:51 by kb_ kb_
Quote:
I mean how often does an app that's NOT a demo need that extra accuracy?

That's not the point. Microsoft used to be one of the few companies that really care about app compatibility, and this is clearly a regression.
added on the 2021-09-07 13:43:49 by KeyJ KeyJ
Quote:
this is clearly a regression

It may not be. Here's a post from 2009 by Ian of BASS fame about low playback position resolution in Vista. Is it possible that the stuttering was always there, but is only being noticed now due to faster computers?

Quote:
anyone got an old Win7 machine lying around for testing perhaps?

Wouldn't a Windows 98 or XP machine be more suitable if you want to verify how the "real" DirectSound worked? Preferably with a few different sound cards in case it's driver/hardware dependent.
added on the 2021-09-07 14:36:13 by absence absence
Ah, Ian's post is indeed enlightening: Not only is it the exact same issue we're talking about here (which would then mean that is has been around for 15 years, yet nobody noticed?); he also mentions that you have to pay for DSBCAPS_TRUEPLAYPOSITION with additional latency. In that case, I can understand Microsoft's decision to not make that a default, as there was no way to make everybody happy.
added on the 2021-09-07 14:48:45 by KeyJ KeyJ
Quote:
(anyone got an old Win7 machine lying around for testing perhaps?)

I still have a win7 installation on my older SSD in my main pc, along with different builds of win10 :D as well as 98/xp on my PIII box
(in any case, feel free to contact me @ discord if you need help with testing :)
added on the 2021-09-07 16:00:56 by wbcbz7 wbcbz7
My test would be simple - just download fr-08: .the .product, and check if it's running perfectly smooth (here's a YT capture in which it does) or not. :)

(or get whatever Blueberry used for testing, and check what it outputs)
added on the 2021-09-07 16:44:19 by kb_ kb_
Quote:
(which would then mean that is has been around for 15 years, yet nobody noticed?)


This is exactly why I'm so confused about this :)
added on the 2021-09-07 17:06:23 by kb_ kb_
but but but youtube has been around for 15 years too! ;D
did a quick fr-08 run at Win7 SP1, and it seems to stutter for 1-2 frames every 0.8-1 second, subjectively even worse that on Win10 (1809 and 21H1), where it also stutters but it is less disturbing
added on the 2021-09-08 10:30:20 by wbcbz7 wbcbz7
upd: as expected, under Windows XP fr-08 doesn't stutter at all, so it's definitely a DSound regression from Vista and later
added on the 2021-09-08 10:43:38 by wbcbz7 wbcbz7
Use Compofiller Studio and skip all the Windows programming bullshit.
added on the 2021-09-08 13:07:13 by yzi yzi
I know this is not how we want it to be, but I can only think of these 2 solutions:

* Create a demo launcher that takes an .exe, hooks the most common DSound/waveOut/whatever functions similar to how .kkapture did and implements correct timing etc, and then launches our demos normally.

* Recompile as many of the old demos/intros as we can with the new audio APIs.

The first adds layers of complexity to launching demos and makes it even more tedious than it already is (compared to a click on a youtube link). But it somehow scales, assuming we find one charitable programmer who does this for the rest of us.

The second options puts the burden on the individual programmers, will leave many productions unpatched behind, and might just break again in 10 years.

But the good news is that the two are orthogonal and both can happen at the same time.
added on the 2021-09-08 20:34:05 by iq iq
Option 1 = WHDLoad for Windows.
added on the 2021-09-08 21:03:34 by yzi yzi
option 1 imo is definitely needed, not only because of audio sync issues but mostly for fixing numerous bugs and regressions in legacy graphics API (mostly DDraw/D3D7 and older, which are horribly broken under Win10). while DX wrappers like dgVoodoo2 work for most of those prods, compatibility issues are still prevalent

on the other hand you have to be sure it wouldn't end up in another Wine :D
added on the 2021-09-08 21:31:53 by wbcbz7 wbcbz7

login

Go to top