I have the Steam release of X-Wing and am attempting to use DOSBox-X with it instead of the included DOSBox 0.74 release for among other things, MT-32 support. The problem is that for some reason only the X axis of my joystick/controller works ingame.

I've tried every 'joysticktype', turning 'timed' on and off and all sorts of messing around with the axis bindings but I just can't seem to get the game to recognize the Y axis. The weirdest part is that if I check the mapper tool or the joystick testing utilities from this thread the Y axis appears to be recognized just fine. It also works without issue ingame with DOSBox classic.

Edit: I learned about the existence of DOSBox Staging from this thread and was able to get the game running with MT-32 music and working joystick support, so that solves my problem. It's still weird that DOSBox-X has this issue though.

I recently downloaded and installed the May 2023 release of DOSBox-X (Windows SDL1) and have a question about the PC speaker settings.

I am wondering why it defaults to the rate of 65536 in the conf file that is generated when I performed a fresh install of DOSBox-X? In the wiki it says the default value is recommended to be 44100, and I cannot find any commentary on why the 65536 rate is now offered? Is it going to make any difference at all if I set it back to 44100 or leave the new default value in place?

almeath wrote on 2023-09-03, 17:40:

I recently downloaded and installed the May 2023 release of DOSBox-X (Windows SDL1) and have a question about the PC speaker settings.

I am wondering why it defaults to the rate of 65536 in the conf file that is generated when I performed a fresh install of DOSBox-X? In the wiki it says the default value is recommended to be 44100, and I cannot find any commentary on why the 65536 rate is now offered? Is it going to make any difference at all if I set it back to 44100 or leave the new default value in place?

65536Hz provides some better rendition but there's no reason you couldn't set it back to 44.1KHz.

There is also a new September 2023 release.

TheGreatCodeholio wrote on 2023-09-04, 05:59:

There is also a new September 2023 release.

Thanks. I just downloaded it. I will try out the 65536 rate and see how I go. Generally, I go with the highest rate available because while not always authentic, I like having the best sound quality.

K.A.R.R. wrote on 2023-05-10, 20:51:

just tested dosbox-x-mingw-win64-20230509035144 […]
Show full quote

just tested dosbox-x-mingw-win64-20230509035144

its working again with cycles=max
cycles are more or less constant at around 250.000
and playback is smoothly

compared to old 20221226190454
cycles are higher around 230.000 - 260.000 compared to 140.000 - 145.000

thx for the fast fix 😀

just tested latest dosbox-x version and the bug from version 2023.05.01 is there again 🙁
it was fixed with svn version
but with latest dosbox-x and max cycles playback with libopenmpt is broken again
(cycles fluctuate again from 250k down to 80k causing audio slow downs)

Rincewind42 wrote on 2023-07-15, 04:21:

Hi K.A.R.R. […]
Show full quote

K.A.R.R. wrote on 2023-05-18, 17:54:

hi may be you can take a look at a small problem with gus and midi playback […]
Show full quote

hi
may be you can take a look at a small problem with gus and midi playback

with standard patches (from latest driver 4.11) midi playback
for e.g. with playmidi.exe
is fine.
but when i use ppl 1.61 (pro patches lite 1.61)
some instruments are incorrectly looped.

dosbox, x, staging and pcem all have this problem
(x, staging and pcem have even more looping problems than normal dosbox with ppl1.61)

BUT with a real gus and the pro patches lite there is no looping error
means the patches are not the problem.

seems there is a bug in midi playback when using the ppl 1.61 patches with dosbox.
would be great if this could be fixed

here some test midis and a recording of the problem
https://www.mediafire.com/file/kfrhzm8720anw2 … ditest.zip/file

Hi K.A.R.R.

I would love to fix this. I suspected this was an emulation problem...

Can you please raise a ticket in our issue tracker on GitHub for this with all relevant info? I don't have a GUS anymore, so every bit of info helps.

DOSBox Staging issue tracker
https://github.com/dosbox-staging/dosbox-staging/issues

Thanks!

done

hope it can be fixed 😀

Attached is code to implement a gamma level modifier for cases where the input color depth is 8 bpp. It was only tested against 32-bit color output and in VGA, but may work in other cases. It is for testing only and based on the assumption that the modified red/green/blue values are 6-bit values, even though they are stored in 8-bit variables. Also, the background code is expected to differ from -X and SVN, so manual application of the patch is likely required (dependent on SVN method of 6-bit RGB values). The patch is self-documenting.

The patch is modified from the previous version based on a recollection of a post by ripsaw about rgb palette changes. In this case, if dosbox is running, then changing the gamma level will not affect the gamma level on screen until the next palette update in the game.