There has been a bug in the OutputPlayingSounds function for a week or so
that hits this assert:
I figured it would be hit eventually, but when the 1.9f dSample multiplier was
removed, it masked the bug.
It is reproducible by setting the dSample multiplier back to 1.9f and letting
the game run for a few minutes with day150.
My best guess is a floating point precision/rounding/casting error is causing
ChunksRemainingInSound to be one chunk too small, also making ChunksToMix
one chunk too small.
Changing this line prevents the crash, but is super janky :):
There was no doubt in my mind this wasn't in the platform code, but I set up
a windows build anyway to be make sure I wasn't going crazy.
By the way, how can you make visual studio remember the work directory,
currently I have to set it every time.
that hits this assert:
1 | Assert(PlayingSound->SamplesPlayed >= LoadedSound->SampleCount) |
I figured it would be hit eventually, but when the 1.9f dSample multiplier was
removed, it masked the bug.
It is reproducible by setting the dSample multiplier back to 1.9f and letting
the game run for a few minutes with day150.
My best guess is a floating point precision/rounding/casting error is causing
ChunksRemainingInSound to be one chunk too small, also making ChunksToMix
one chunk too small.
Changing this line prevents the crash, but is super janky :):
1 2 | - ChunksToMix = ChunksRemainingInSound; + ChunksToMix = ChunksRemainingInSound + 1; |
There was no doubt in my mind this wasn't in the platform code, but I set up
a windows build anyway to be make sure I wasn't going crazy.
By the way, how can you make visual studio remember the work directory,
currently I have to set it every time.
To make VS remember working directory you need to save solution file. VS generates one automatically if you launch it with exe as argument.
Are you sure this isn't the one that we just fixed (see https://youtu.be/UNXHK8O-B_g?t=141)?
- Casey
- Casey
I see now, the ".sln" file has to be saved in the same directory as the exe. I was
saving it in a different directory then loading it, which doesn't work for some
reason.
The bug is still in day151, I thought you were going to get it at the time you mentioned, but it's a slippery sucker :P
saving it in a different directory then loading it, which doesn't work for some
reason.
The bug is still in day151, I thought you were going to get it at the time you mentioned, but it's a slippery sucker :P
Do you have any good way of reproducing it?
- Casey
- Casey
Yeah - I meant is there some reliable way of making it happen. We can leave it running in the background for a minute at some point and see if it will happen with 1.9x...
- Casey
- Casey
Yeah, the rule is that there is no programming of any kind allowed if I'm not streaming.
- Casey
- Casey
I'm a couple of episodes behind so I don't know if this bug has already been resolved but the problem present itself when the rounding of the samples to mix produces the floor value (decimal part < 0.5) and the last chunk of the sound is being played. This causes the assert to fire (the sample played will be always less than the sample count in this case).
Maybe is only necessary to use a ceiling instead of a round for the samples to mix but I don't know if that introduces other bugs. Hope this helps.
Maybe is only necessary to use a ceiling instead of a round for the samples to mix but I don't know if that introduces other bugs. Hope this helps.