search

dosbox-staging / dosbox-staging

DOSBox Staging is a modern continuation of DOSBox with advanced features and current development practices.
https://www.dosbox-staging.org/
Other
1.31k stars 154 forks source link

Sound emulation: Long road to Perfection #278

Closed GranMinigun closed 3 years ago

GranMinigun commented 4 years ago

Follow-up on #171.

Turns out DOSBox has some (serious) problems with sound hardware emulation and/or output. Audio volume with different hardware or output (digital vs. MIDI) is unbalanced, hardware is either not accurately emulated or even outright broken, and while I was gathering edge test-cases, some questions arose. Hope I'll be clear enough and I won't need to rewrite the whole thing. But it will probably be better to break it down to smaller and more focused issues.

Let's start simple: PC speaker in terms of volume sounds just about right. SoundBlaster emulation seems to be too loud, and Gravis UltraSound and MIDI (OPL included) are way too quiet. From my understanding, General MIDI and Sound Canvas devices just send instructions to an external renderer, and so it shouldn't be a problem of DOSBox (user's synth could be configured to output with lower volume, and it also depends on used soundfont), but I'm not sure.

Another thing considering volume problem is that 16-bit output for some reason has lower volume than 8-bit output. Applies both to SB and GUS audio.

Oh, Gravis UltraSound... this one's painful. Seems it's emulated totally incorrect, and because of that we have various problems, namely: incorrect sound, lack of stereo separation, sometimes no output at all, low volume. It's also not clear which model is emulated, and in some cases we might need to emulate at least MAX one.

Speaking of incorrect emulation. SB16 has some sort of low-pass filter, which isn't present in DOSBox. Sure, that's inaccurate and sounds different, but not necessarily worse. SB2 (or was it Pro?) has its own filter in place though.

Now, to be more specific - some test subjects:

Might and Magic III: Isles of Terra. This one is interesting because it's the only known to me game that actually changes audio volume depending on SB type and sbmixer setting: it sounds louder with older soundcard models, and also with mixer turned off. What exactly sbmixer setting does? Why is it needed? When we should switch it? SounBlaster is only used in cut-scenes for voices, everything else (SFX included) is rendered by Roland device (if it's selected, that is; otherwise OPL emulation comes into play, and it's... not good there).

Doom. Both Gravis UltraSound and SoundBlaster can be used for SFX and MIDI. SB digital audio sounds louder than it presumably should (for instance, source ports have comfortable sound level). MIDI on the other hand is quiet. GUS is quiet in both cases, and it seems that General MIDI also has lowered volume (why?!). So, because of constant action SB just "mutes" music by itself, and if we use GUS, then we loose details. Yet another problem is stereo separation with GUS: it works with gusrate set to 11025 or 22050 only. All, or almost all of that should be applicable for most of games that support both SB and GUS - and that's a whole lot.

The Elder Scrolls II: Daggerfall. Notable for using HMI. If GUS is selected for digital audio, then during testing audiosample is "crackling". In-game it gets more interesting: there are periodic "clicks", and right channel outputs sound with strongly lowered tone (turn up da bass!). Stereo separation is kinda working though. All of that could be (and probably are) just HMI or game's bugs, but noting it just in case.

Quake. Uses CD-DA for music, works good. Readme file states that SB and GUS MAX/PnP are supported for audio output (note - not original model; upd: support for original GUS was added with later patch), techinfo.txt - that only SB cards are. Sources have something on GUS. Game detects and initializes with GUS, but - no sound is output, no matter what DOSBox settings or game launch parameters are.

Sound Initialization
Sound Card is UltraSound
Sound Sampling Rate: 19293

Crusader: No Remorse. Supports GUS' hardware mixing. Uses tracker music. Also seems to support both 8- and 16-bit audio mixing/output. First, SB has different volume when selecting either DMA (8-bit) or HDMA (16-bit), with former being louder. Second, GUS seems to work in 16-bit mode, and it is close to being inaudible. No stereo separation either, no matter gusrate setting.

And some misc questions. As was already mentioned, SB cards have different filters, like brickwall/lowpass/whatever in SB16. How about making them optional? Accurate emulation is great, but there are people (myself included) that would prefer "clean" sound, and some may like sound of older SB models more.

Another question is - why 49716Hz is maximum frequency? From where comes that number, and what about people that have audio hardware capable of working at 96/192KHz?

Windows specific: how about adding direct OmniMIDI support? This software synthesizer can work with wrapper (and it doesn't for me, for whatever reason), but it's obviously slower than direct access. It has its own API, which is documented.

Phew... that was long enough. Please don't force me to do that again.

volkertb commented 4 years ago

I'd like to add another (small) issue I noticed in DOSBox a while back, namely the fact that the upstream project makes no distinction between the Covox Speech Thing and the Disney Sound Source, even though these are distinct and mutually incompatible devices. The Former is a dumb DAC directly on the printer port, relatively easy to build as a DIY project in the form of a resistor ladder. The DSS however is a somewhat more complex device, since it has a FIFO buffer, which makes it somewhat easier to program for and less taxing on the CPU, at the price of supporting only a 7kHz fixed audio output frequency.

DOSBox in fact emulates a Covox Speech Thing and confusingly calls it a DSS in its documentation and in the config ini file.

Now, granted, this oversight in upstream DOSBox is not that big a deal in practice, since pretty much every game that supports these parallel port sound devices also supports superior sound cards, the proper emulation of which of course has a much higher priority. But such a mixup is not accurate and confusing, and it results in most games with Disney Sound Source support (such as Wolfenstein 3D and some later SCI-based Sierra adventures, to name a few) not to work with the so-called "DSS support" in DOSBox, when people try to play with that feature.

The PCEm project in contrast, emphasizing on hardware emulation accuracy over game performance, does emulate both the Covox Speech Thing and the Disney Sound Source correctly and accurately. Since both DOSBox and PCEm are GPL2-licensed, it would be no problem to "steal" the proper code from PCEm to fix such inaccuracies, right?

I'm not sure how the emulation quality of more sophisticated audio hardware like Sound Blaster and GUS compares between upstream DOSBox and PCEm.

But in a forked project with a compatible licnese, you get to pick and choose, right? 😉

kcgen commented 4 years ago

@GranMinigun ,

Drew up the audio chain, in part just to get the lay of the land, but also pin-point areas to dig into (sorry, used a pencil.. maybe someone can tweak it and make it look better).

Suggest opening in a new tab then zooming 1:1 so it looks natural.

dosbox audio chain

kcgen commented 4 years ago

why 49716 Hz is maximum frequency? (for OPL devices)

For OPL devices, the following formula is used to determine the frequency number for a given note frequency (in Hertz) and block:

f-num = freq * 2^(20 - block) / 49716

This formula can produce frequency numbers outside of the allowed 0-1023 range if the block number is too low, or the frequency is higher than the hardware can produce.

The sampling frequency of OPL2 and OPL3 chips is approximately 49716 Hz, leading to the constant in the formula. Occasionally this is rounded to 50000 leading to a small pitch variation if the wrong constant is used to play these songs. OPL2 cards like Adlib and early Sound Blasters used the 14.31818 MHz oscillator signal from ISA bus slot and divided it by four on card, thus running the OPL2 chip at 3.579545 MHz, which gets divided internally by 72 to get the sampling rate. OPL3 cards had to be compatible, and mostly the sound cards have separate 14.31818 MHz oscillator on board which the OPL3 uses directly, and this gets divided internally by 288 to get the sampling rate.

Ref: http://www.shikadi.net/moddingwiki/OPL_chip

So we have two scenarios:

  1. Run the OPL at 49716 Hz for the most accurate output from it, but then let dosbox's rudimentary resampler adjust frequencies down to the mixer's rate, which defaults to 44,100 Hz, and then finally have your audio API resample to the audio devices preferred rate, which typically defaults to 48000.

  2. Run the OPL at 48,000 Hz to match both our mixer's output rate and audio device's preferred rate such that we fully avoid both dosbox's and the OS API's resamplers, and instead allow the OPL code to provide us with the slightly-lower-frequency data.

The second option is better if the OPL code gracefully handles different sampling rates. I'd rather use the audio values straight from the OPL code than have them resampled twice-over, each time losing precision.

Given we have compat, fast, and nuked OPL types, it makes sense to see which work fine at 48 kHz versus those that would be better suited to using 49.x kHz and then resampling.

GranMinigun commented 4 years ago

You monster.

By the way, any reasons to replace SDL with OpenAL? Just curious. ioquake3 and Yamagi Quake 2, for example, switched to OAL, and sound quality got better, but DOSBox is a different beast, so..?

kcgen commented 4 years ago

Regarding all the volume issues, it's largely due to centrally mixing all dosbox's emulated device channels in one output (area D in the image where they funnel into the mixer).

The trouble is the mixing: say you've got two 16-bit audio streams both of which can "cap out" at full volume. If you try to combined them, then many added samples will blow-past their 16-bit headroom and be clipped. So the simple "solution" is to cut their volumes by half then add.

DOSBox's mixer has a lot more than two feeds, plus it receives them in 8, 16, and even 32 bit depths. There's a bunch of tricky volume and scaling bit-shifts through the sound code, but the GUS code is especially full of it because it tries moves everything into 32-bit space with some hardcoded shifts (in hopes of retaining dynamic range).

After knocking out some of this hardcoded shifting and simply returning straight 16-bit values to the mixer, the GUS volume all of sudden became right on par with other volumes. So this might be direction to go to address this at a fundamental level.

kcgen commented 4 years ago

any reasons to replace SDL with OpenAL

Very interesting suggestion! The knee-jerk response is that dosbox only produces a single audio stream, therefore doesn't need OpenAL's multi-channel, heterogenous format and rate handling.

But all of dosbox's audio stretching, resampling, and volume shifting is specifically to produce a single output stream. OpenAL would free us from that complexity by allowing each device to have its own audio channel at its native unadulterated bit depth and sample rate directly into OpenAL.

The code would absolutely be simplified and more readable, because all of this bit-shifting and scaling would be eliminated. (Take a skim through src/hardware/gus.cpp, and try figuring out which bit-shifts are dosbox'isms versus GUS'isms.. I haven't sorted it out yet!)

From a hardware perspective, this one-to-one output model matches reality too. The physical PC Speaker is tied to it's own speaker. The Sound Blaster card has it's own dedicated line-out. If you had a GUS or MIDI device - those too had their own separate line-out's.

kcgen commented 4 years ago

@GranMinigun If you want to try the current three audio PR fixes, you can do an octopus merge with:

git checkout -B audio-test

git merge --no-edit kc/suppress-sb-dma-init-1 kc/zero-offset-speaker-1 kc/envelope-channel-on-start-1 kc/instant-launch-1

make distclean

./scripts/build.sh -c gcc -t release

Give it a whirl with something like Eye of the Beholder 3 (configured w/ SB for fx and music) which loves to pop the speaker.. it's a much nicer experience now.

kcgen commented 4 years ago

More thoughts... and why I'm liking OpenAL Soft!

As for cross-compatibility, compiler-compatilibity, ease-of-installation, and so on: I haven't looked into it that much yet.

@dreamer , curious what your thoughts are and if you have experience with it.

kcgen commented 4 years ago

For future reference, attached is the Gravis Ultrasound SDK rev 2.22, released December 1994:

:bookmark_tabs: Gravis_Ultrasound_SDK_rev2.22.pdf

kcgen commented 4 years ago

@GranMinigun, see this post for progress on GUS stereo separation with a Gravis SDK-compliant, constant-power pan-table.

Give any of those test builds a spin with the attached Second Reality Demo using a decent pair of headphones. The builds will show you which GUS voice channel is being panned and the position, so you can possibly see and hear it in tandem.

This is a very small change, but I believe it's what was actually intended versus the more muddy table created by AMD. Curious what you think!

PS- the demo takes a minute or two to really get going.

GranMinigun commented 4 years ago

Unfortunately, decent headphones have passed out, so I'm not sure whether I'll be able to hear all the details. I'm following your progress closely, and will try to check things out anyway.

kcgen commented 4 years ago

@GranMinigun , https://github.com/dosbox-staging/dosbox-staging/tree/feature/gus-improvements-1 attempts to address these issues. Listen to some comparisons here: https://github.com/dosbox-staging/dosbox-staging/wiki/Gravis-UltraSound-Enhancements.

kcgen commented 4 years ago

Comparing the GUS enhancement branch versus SVN and X in Quake at 120000 cycles:

DOSBox-SVN and current dosbox-staging (master and 0.75)

Given Quake performs all stereo and effect mixing in software (and generates a 16-bit stereo stream), there is zero benefit to use the GUS versus SB16, and we agreed with the DOSBox team's position. This comparison is simply academic for the sake of this issue (as Quake was mentioned).

DOSBox-X

Sound effects work as expected. The dynamic range is clipped. Some stuttering, but that's due to the 120,000 cycles. During the transition to a new game, the last sound-effect played hitches for a split second while the map is loading.

dosbox-staging

dreamer commented 4 years ago

Woah, this issue got closed automatically once I merged a PR with GUS improvements. This was unintentional of course, I expect we still have other audio improvements ahead of us!

Reopening (unless @GranMinigun and @kcgen decide, that it's time to close this issue).

GranMinigun commented 4 years ago

Guess the time has come for an intermission. [E2M3 starts playing]

From general problems, it seems that only lowered volume of 8-bit sound on 16-bit output is left. According to this comment, it seems to be an expected behaviour. Though I'd prefer to create a discussion - it would be nice to verify that's indeed what's happening on real hardware and whether there's any way to automagically compensate.

Another related, but probably game-specific concern is Crusader games: according to this list, it renders 16-bit audiostream, but selecting HDMA in sound setup still have lowered volume. Either the list is incorrect or...

Also regarding volume - any plans on increasing volume for OPL by ~150%? (421088a)

What about PC speaker? Should we open an issue for it? It's not really pleasant to my ears, but I don't remember how it should sound.

A gentle reminder: this comment wasn't answered (at least I didn't see an answer).

If there's any interest in adding audio filtering, then we could create an issue for that. I know it won't be a priority, but discussion and tracking won't hurt. I personally only interested in possibility to turn it off (because I prefer bit-exact audio, yeah).

Same goes for theoretical possibility to replace DOSBox mixer with SDL2 one or OpenAL. (I remember whys and why nots.)

[There was some writing on used frequencies and stuff but it was stolen by UFO.]

Now, FluidSynth... we had a discussion on one particular problem. It's pretty serious, and I think I'll open an issue for that with all details currently gathered. Hope we could resolve it for 0.76 release.

Might and Magic III - it just needs MT-32 emulation. Discussion is in #257.

Crusader: No Remorse / No Regret - I wonder if it outputs audio on GUS in mono on real hardware too.

TES: Daggerfall - oof. HMI. I wasn't able to befriend it with GUS, even with the hint from Vogons.

Think I didn't miss anything? If you feel like it, I have nothing against closing this issue. Or editing first post. Back to testing GUS...

kcgen commented 4 years ago

Thanks for all the testing and careful listening @GranMinigun, and for raising all the lose ends not explicitly addressed. Suggest we try to close out what we can, and those remaining get spun off into new issues.

8-bit vs 16-bit output levels

it seems that only lowered volume of 8-bit sound on 16-bit output is left.

If there are output level differences, then they are caused by the game either programmatically (ie: software-mixing) or in the PCM samples themselves given to dosbox by the game.

We can prove it to ourselves if we hold the source constant and vary the bit-depth (and by extension the audio card) being driven in dosbox.

If dosbox's 16-bit emulation handling (in both SB16 and GUS) is the culprit, then such a test will produce lower output levels when driving dosbox with 16-bit samples versus higher levels when driving dosbox with 8-bit samples.

To do this test, I used MPXPlay which has hardware drivers for SB16, SBPro(*), and GUS.

Three scenarios were tested:

  1. 16-bit output using SB16

    • dosbox-staging config: sbtype = sb16
    • MPXPlay's INI: SoundcardName=SB16.

  2. 16-bit output using GUS

    • dosbox-staging config: gus = true
    • MPXPlay's INI: SoundcardName=GUS.

  3. 8-bit output using SBPro2

    • dosbox-staging config: sbtype = sbpro2
    • MPXPlay's INI: SoundcardName=SBP.

Also double check that the following neutral MPXPlay settings are configured for all three tests:

SoundcardFreq=0         ;manual setting of output freq (0:outfreq is controlled by freq of song(s))
SoundcardChan=0         ;manual setting of output channels (WDS,SBP or wav-output)
SoundcardBits=0         ;manual setting of output bits (at Audigy 2/4/LS,Live24,ICH4,IHD,wav-output,WIN\
,WDS)
SoundcardVol =100        ;-scv (0-100)(-1:get value from the card)
SoundcardTrbl=100       ;-sctr (1-100-200)(100:original tone, 0:get value from the card)
SoundcardBass=100       ;-scbs (hardware tone at SB16/AWE cards, else soft-tone by au-mixer)
MixerControl =0        ;+1:enable limiter, +2 allways use soft-tone (disable hw-tone), +4: 0.1% speed c\
ontrol (500-1000-9999)
SoundVolume  =100       ;-sv
AutoVolume   =0         ;-sva (slow volume correction (up and down too))
Surround     =100       ;-sr
Speed        =100       ;-sp
Balance      =0         ;(-99...0...+99)
Swapchan     =0         ;swap channels (reverse stereo)
LoudnessVol  =100       ;expand/loudness value of volume

Perform the test:

  1. play the same source audio file (suggest a ~1 minute FLAC audio track).
  2. Start WAV capture in dosbox for the entire playback duration.
  3. Open all three recordings in audacity, press ctrl + A to select the entire audio region, then Effect > Amplify, and see if dB gain needed to normalize the sequences differs. These should be very close to indentical for all three recordings, meaning that output levels are the same across 8 and 16 bit (for all supported sound devices).

With the new GUS code in dosbox-staging, I get equal output levels across all three sound cards and bit-depths.

Perhaps we should mention it in the Wiki so other users understand. (I was certainly just as concerned until I was able to inspect and print the actual sample amplitude levels provided by the games).

Suggest confirming and (assuming reproduced on your side) we conclude this issue.

Automatic audio normalization

whether there's any way to automagically compensate.

This can be done.. basically you keep track of the peak level over a rolling window of seconds, say 10 seconds. If the level is below the max by some threshold (say, below 80%) then you take max / peak and then you incrementally step the scaling up (by a very low dB amount) every ~1ms until the current target is achieved.

This can be done very accuracy on a per-sample basis, but the dilemma lies in the rolling window. Image you have a 2 minute intro sequence that's deliberately recorded at very low levels with subtle background noises and spooky creaks. The algorithm doesn't know the difference if this is deliberately at a low volume or if it's a game problem and shold be "pulled up". So the auto-volume would soon have this operating at full dynamic range - which is /not/ what the game authors intended.

So then we might say, Ok - let's use longer time windows. That does work - but then you drag out the periods before the pull-up occurs.

In the end, for GUS, I opted to track the streams total peak output and report back to the user the exact "pull up" percent and mixer command line if they want to normalize the game's audio. I also prefer "sample exact" output and as little modification along the line, so I liked this as a compromise.

Also, this mixer-scaling value will be constant for a given game. So I imagine we can croud-source such a list of values that users can "set-once-and-forget".

However - this feature right now only exists for GUS. We could certainly add it for all the audio devices.

Suggest a separate ticket requesting audio diagnostics be reported for all devices.

Crusader games: low audio levels

Another related, but probably game-specific concern is Crusader games: according to this list, it renders 16-bit audiostream, but selecting HDMA in sound setup still have lowered volume. Either the list is incorrect or...

The game's samples that it writes into the GUS's memory have extremely low levels; the only known solution is to pull it up via the mixer. From the GUS diagnostic output, a value of mixer gus 550 works well.

Also note that the Crusader games only use a single output voice to the GUS and don't touch the pan register. This indicates that these games are performing their mixing entirely software-side. So they are not the fabled "excellent GUS examples" as many tend to tout them as.

Contrast this with another game that writes 16-bit PCM samples into the GUS's memory: Quake. Those 16-bit samples have zero-issues with hitting the entire 16-bit dynamic range. (the GUS code doesn't know the difference between a Crusader sample versus a Quake sample).

Separate issue not needed; suggest we conclude this (through more discussion as needed).

OPL audio 1.5x scaling

Also regarding volume - any plans on increasing volume for OPL by ~150%? (421088a)

It's in the queue, but I haven't looked into this yet (or the justification leading to the 1.5 multiplier).

Separate issue not needed; already in the backlog.

PC Speaker improvements

What about PC speaker? Should we open an issue for it? It's not really pleasant to my ears, but I don't remember how it should sound.

It should sound just like SVN (in a wave-form sense), but the output levels (and perceived volume) of square waves versus approximated sine-waves (ie: RealSound) should now be very close to on-par with each other. Also, DC offset is zeroed rapidly (under 1/10th of a second).

Contrast this with SVN where the sine-waves will be perceived to have much lower relative volume versus square wave sequences. If you're playing a pure realsound game, you might want to turn up the volume; but then you better watch out if you switch to a square-wave game - those sounds will come thundering through with significantly more power.

We still have work to do to incorporate the PC Speaker patch used in ECE. Separate issue not needed; already in the backlog.

Covox support

A gentle reminder: this comment wasn't answered (at least I didn't see an answer).

Covox Speech Thing vs Disney Sound Source.

We should add it to the backlog; we will certainly consider and incorporate any patches that sort these two out.

I'm being passive here because I unfortunately have zero personal desire or interest in this area. Between PC Speaker, tandy, Adlib, Sound Blaster(s) + OPL2/3, GUS, Roland, and MIDI - I feel that this suite of hardware emulation covers the range of "uniquely distinct sounds" offered by games. There are other hardware devices too (the PAS Spectrum, etc.. but I also don't feel they bring enough distinction to the table to warrant the effort).

Suggest opening a separate issue requesting Covox support.

Audio filtering

If there's any interest in adding audio filtering, then we could create an issue for that. I know it won't be a priority, but discussion and tracking won't hurt. I personally only interested in possibility to turn it off (because I prefer bit-exact audio, yeah).

Given dosbox itself doesn't have a "hardware noise floor" or hiss like the original hardware, there is little value in adding filtering from a noise perspective, which was the original intent from the hardware designer's perspective.

I guess some value exists if someone wants to experience lower frequency output simply for the sake of nostalgia. However, unless this is a sought-after feature, I personally put it in the same camp as Disney and Covox: the payoff isn't work the effort or extra maintenance burden.

However unlike Covox support (which I agree we should have if someone would write it), I would be more critical toward audio-filtering and would want to see a straw-poll showing a decent percent of people actually want this.

Suggest creating a straw-poll and posting on Discord, GitHub, and Reddit to test user interest.

External Audio Mixers

Same goes for theoretical possibility to replace DOSBox mixer with SDL2 one or OpenAL. (I remember whys and why nots.)

Currently there are still easy improvements to be made in the mixer and little to gain while adding complexity and dependencies by switching. The SDL Mixer is poorly described.. it's actually an audio player that can mix one music stream while being able to play N other audio samples. So it's more used by game developers who want to offload the audio work and just tell SDL to play "sound effect 1.ogg for 0.2 s" while playing "music-track-5.flac".

Separate issue not needed. Suggest that we conclude with further discussions if needed.

Frequencies (TBD)

[There was some writing on used frequencies and stuff but it was stolen by UFO.]

Please elaborate when the UFO occupants implant it back into your memories :-)

FluidSynth per-instrument level changes

Now, FluidSynth... we had a discussion on one particular problem. It's pretty serious, and I think I'll open an issue for that with all details currently gathered. Hope we could resolve it for 0.76 release.

We will fix the out levels and wrapping by switching to float output and using the soft limiter. However you've mentioned per-voice level differences, which we have no way of programmatically influencing unless we started tampering with the actual MIDI commands handed to us from the game before we pass them onto FluidSynth for rendering.

Although I'm not able to hear this or see it, maybe we can pull in the QSynth and/or FluidSynth developers and you can explain what you're experiencing to them and see if there's anything we can do regarding settings or API calls into FluidSynth (if this is a bug/defect).

Suggest opening a separate issue.

Munt integration

Might and Magic III - it just needs MT-32 emulation. Discussion is in #257.

Separate issue is not needed, integrating Munt is in the backlog.

Crusader games: mono output on GUS

Crusader: No Remorse / No Regret - I wonder if it outputs audio on GUS in mono on real hardware too.

Need someone objective to test this - ideally capturing the output and giving us the audio recording.

Suggest a game-specific issue with "Help Wanted" label.

TES Daggerfall GUS configuration

TES: Daggerfall - oof. HMI. I wasn't able to befriend it with GUS, even with the hint from Vogons.

Suggest a game-specific issue.

kcgen commented 3 years ago

Closing this. Lots of goods stuff was brought up and it resulted in hundreds of commits spanning roughly 7 months of work. All generally-addressable issues have been resolved - ie: fixed, can't fix, or are game-side. As recommended above, new tickets should be opened to address game-specific issues, one at a time. Thanks for the thorough critique @GranMinigun!