DOSBox ECE (for Windows & Linux)

[Yesterplay80]

Forgot to mention, it would be nice to add output gain and reverb output gain settings as I had to manually set them in midi_mt32.cpp using setOutputGain and setReverbOutputGain methods on Synth object and recompile dosbox ece.

Could you provide a diff of the changes you made? And maybe propose those changes to sergm, who provides the patch for DOSBox in the first place?

[troydm]

Forgot to mention, it would be nice to add output gain and reverb output gain settings as I had to manually set them in midi_mt32.cpp using setOutputGain and setReverbOutputGain methods on Synth object and recompile dosbox ece.

Could you provide a diff of the changes you made? And maybe propose those changes to sergm, who provides the patch for DOSBox in the first place?

Sure here you go

Code: Select all

--- a/src/gui/midi_mt32.cpp
+++ b/src/gui/midi_mt32.cpp
@@ -91,6 +91,8 @@ bool MidiHandler_mt32::Open(const char *conf) {
                service->setReverbOverridden(true);
        }

+       service->setOutputGain(0.01f * section->Get_int("mt32.output.gain"));
+       service->setReverbOutputGain(0.01f * section->Get_int("mt32.reverb.output.gain"));
        service->setDACInputMode((MT32Emu::DACInputMode)section->Get_int("mt32.dac"));

        service->setReversedStereoEnabled(section->Get_bool("mt32.reverse.stereo"));

--- a/src/mt32options.h
+++ b/src/mt32options.h
@@ -82,6 +82,12 @@ Pint->Set_help("MT-32 analogue output emulation mode\n"
        "Same as the default mode 2 but the output signal is 2x oversampled, i.e. the output sample rate is 96 kHz.\n"
        "Even slower than all the other modes but better retains highest frequencies while further resampled in DOSBox mixer.");

+const char *mt32gainValues[] = {"0", "25", "50", "100", "125", "150", "175", "200",0};
+Pint = secprop->Add_int("mt32.output.gain", Property::Changeable::WhenIdle, 100);
+Pint->Set_values(mt32gainValues);
+Pint->SetMinMax(0,65535);
+Pint->Set_help("Output gain of MT-32 emulation.");
+
 const char *mt32reverbModes[] = {"0", "1", "2", "3", "auto",0};
 Pstring = secprop->Add_string("mt32.reverb.mode",Property::Changeable::WhenIdle,"auto");
 Pstring->Set_values(mt32reverbModes);
@@ -92,6 +98,11 @@ Pint = secprop->Add_int("mt32.reverb.time",Property::Changeable::WhenIdle,5);
 Pint->Set_values(mt32reverbTimes);
 Pint->Set_help("MT-32 reverb decaying time");

+Pint = secprop->Add_int("mt32.reverb.output.gain", Property::Changeable::WhenIdle, 100);
+Pint->Set_values(mt32gainValues);
+Pint->SetMinMax(0,65535);
+Pint->Set_help("Reverb output gain of MT-32 emulation.");
+
 const char *mt32reverbLevels[] = {"0", "1", "2", "3", "4", "5", "6", "7",0};
 Pint = secprop->Add_int("mt32.reverb.level",Property::Changeable::WhenIdle,3);
 Pint->Set_values(mt32reverbLevels);


[Yesterplay80]

Thank you, troydm, I will integrate those changes in the next build.

[Qbix]

I noticed a mixture of set_values with setminmax
Codewise, minmax isn't used if the property has set_values called.

[troydm]

I noticed a mixture of set_values with setminmax
Codewise, minmax isn't used if the property has set_values called.

ah, I didn't knew that, so we need to remove Set_values calls and related mt32gainValues variable and just leave only SetMinMax calls

[Samantha Ann Mulder]

This will maybe be helpful to someone:
https://www.youtube.com/watch?v=eaIXszCgth4

Yesterplay80, do you know AppImage?
https://appimage.org/

You had trouble building linux version statically, maybe AppImage is the workaround to solve this.

[troydm]

Thank you, troydm, I will integrate those changes in the next build.

I've noticed you've added changes only to windows build, also why do you keep Linux and Windows sources separately?
Also are you planning to create github repo for PR's? If you'll have a repo I could help you out with keeping single source code for building
Windows and Linux version from one place

[Yesterplay80]

I've noticed you've added changes only to windows build, also why do you keep Linux and Windows sources separately?

Because the code actually is different, e. g. the patch for Voodoo emulation differs between Windows and Linux, so the resulting source code differs as well.

Also are you planning to create github repo for PR's? If you'll have a repo I could help you out with keeping single source code for building
Windows and Linux version from one place

TBH, I didn't think about that until now, because it didn't seem necessary. The patches I integrate don't change very often, so basically most changes are just the one in the official vanilla source code.

Btw.: I updated the linux build in the meantime, too.

[Delfino Furioso]

I've noticed that you reverted the svga_s3 memory amount to 4MB in today's new 4176 build
this resolves the win311 black cursor problem that was there since 4095

cheers, thanks!

[Qbix]

I've noticed that you reverted the svga_s3 memory amount to 4MB in today's new 4176 build
this resolves the win311 black cursor problem that was there since 4095

cheers, thanks!

Mmm that was a change related to opengl.
Do you run win311 in opengl mode then ?

[ripsaw8080]

I think r4095 is mentioned only because it was coincident with the change that actually caused the Win3 problem; namely, the increase in video memory.

[Qbix]

ah, wasn't the video memory increased (or kept increased) to "fix" the windows cursor ?

[Delfino Furioso]

that's correct

back then we were able to determine that vanilla svn 4098 and later were not affected, only the ECE builds were
it was related to an (ECE-exclusive) increase (4MB => 8MB) to the video memory available for the svga_s3 machine type that happened in the same timeframe

ECE 4716 (the latest re-release made today) has reverted that change within the vga_s3.cpp file


btw, these are the machine/display related params that I usually set in ECE

Code: Select all

[sdl]
fullscreen           = false
fulldouble           = false
fullresolution       = desktop
windowresolution     = desktop
output               = ddraw
surfacenp-sharpness  = 50
surface-collapse-dbl = false
autolock             = true
xsensitivity         = 100
ysensitivity         = 100
waitonerror          = true
priority             = higher,normal
mapperfile           = mapper-ECE.map
usescancodes         = true



[dosbox]
language =
machine  = svga_s3
captures = capture
memsize  = 30



[render]
frameskip = 0
aspect    = true
scaler    = tv2x forced


[Qbix]

Okay, so the whole video memory increase, is not really needed.

As the build engine can be worked around and the black cursor is caused by the increase itself.

[Delfino Furioso]

actually I've made some mistakes in explaining the whole story, so let's amend them


1) afaik, vanilla SVN builds always used 2MB of video memory for S3 Trio cards (vga_s3.cpp, line 534 as of commit 4176)

2) with ECE build 4098, the vmem size was brought up to 8MB
this fixed the build engine games flickering issue
this caused the windows 3.11 black mouse cursor issue

3) since today's re-release of ECE build 4176, the vmem size has been set to 4MB (so still bigger than vanilla svn)
this should still be enough to avoid the flickering issue in blood
this fixed the black cursor issue in win 3.11

[Yesterplay80]

Okay, so the whole video memory increase, is not really needed.

As the build engine can be worked around and the black cursor is caused by the increase itself.

Exactly, that's why I set the memory back to the 4MB that the S3 Trio64 officially supported, to fix the issue with WIN3.1.

[Qbix]

I think, that blood can flicker with 4 mb as well (depending on how fast your pc is)... It doesn't flicker if you use the recommended machine setting.

[ripsaw8080]

Yep, adding video memory does not "fix" the flickering in the Build Engine games, although it might reduce flicker under certain circumstances, depending on the speed of the host system and the complexity of the scene being rendered in the game. However, when going from pervasive flicker to only a little bit here and there, some might consider that good enough.

[troydm]

Btw.: I updated the linux build in the meantime, too.

Could you please remove Pint->Set_values(mt32gainValues) calls from mt32options.h and related
const char *mt32gainValues[] = {"0", "25", "50", "100", "125", "150", "175", "200",0};
line from source code as Qbix suggested, because this limits the range of values which could be set to a really
limited set of values specified instea of just using SetMinMax, this was my mistake for not checking this beforehand

[Yesterplay80]

Could you please remove Pint->Set_values(mt32gainValues) calls from mt32options.h and related
const char *mt32gainValues[] = {"0", "25", "50", "100", "125", "150", "175", "200",0};
line from source code as Qbix suggested, because this limits the range of values which could be set to a really
limited set of values specified instea of just using SetMinMax, this was my mistake for not checking this beforehand

Just a question: You defined values up to 200, which, if I get this right, amplifies the gain by the given value. So the default value, 100, results in a gain of 1.
If that's so, isn't a maximum value of 65535 (655 times the normal gain) a bit much? And wouldn't 0 mute the gain entirely?