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.
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.
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.
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?
Someone will laugh if the FMOD timer is used in a 4k intro anyway.
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.
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.
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?)
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.
Should it be though? I mean how often does an app that's NOT a demo need that extra accuracy?
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?)
(anyone got an old Win7 machine lying around for testing perhaps?)
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.
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.
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.
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 :)
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)
(or get whatever Blueberry used for testing, and check what it outputs)
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 :)
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
upd: as expected, under Windows XP fr-08 doesn't stutter at all, so it's definitely a DSound regression from Vista and later
Use Compofiller Studio and skip all the Windows programming bullshit.
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.
* 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.
Option 1 = WHDLoad for Windows.
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
on the other hand you have to be sure it wouldn't end up in another Wine :D