troydm wrote:

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?

Yesterplay80 wrote:

troydm wrote:

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

1--- a/src/gui/midi_mt32.cpp
2+++ b/src/gui/midi_mt32.cpp
3@@ -91,6 +91,8 @@ bool MidiHandler_mt32::Open(const char *conf) {
4                service->setReverbOverridden(true);
5        }
6
7+       service->setOutputGain(0.01f * section->Get_int("mt32.output.gain"));
8+       service->setReverbOutputGain(0.01f * section->Get_int("mt32.reverb.output.gain"));
9        service->setDACInputMode((MT32Emu::DACInputMode)section->Get_int("mt32.dac"));
10
11        service->setReversedStereoEnabled(section->Get_bool("mt32.reverse.stereo"));
12
13--- a/src/mt32options.h
14+++ b/src/mt32options.h
15@@ -82,6 +82,12 @@ Pint->Set_help("MT-32 analogue output emulation mode\n"
16        "Same as the default mode 2 but the output signal is 2x oversampled, i.e. the output sample rate is 96 kHz.\n"
17        "Even slower than all the other modes but better retains highest frequencies while further resampled in DOSBox mixer.");
18
19+const char *mt32gainValues[] = {"0", "25", "50", "100", "125", "150", "175", "200",0};
20+Pint = secprop->Add_int("mt32.output.gain", Property::Changeable::WhenIdle, 100);
21+Pint->Set_values(mt32gainValues);
22+Pint->SetMinMax(0,65535);
23+Pint->Set_help("Output gain of MT-32 emulation.");
24+
25 const char *mt32reverbModes[] = {"0", "1", "2", "3", "auto",0};
26 Pstring = secprop->Add_string("mt32.reverb.mode",Property::Changeable::WhenIdle,"auto");
27 Pstring->Set_values(mt32reverbModes);
28@@ -92,6 +98,11 @@ Pint = secprop->Add_int("mt32.reverb.time",Property::Changeable::WhenIdle,5);
29 Pint->Set_values(mt32reverbTimes);
30 Pint->Set_help("MT-32 reverb decaying time");
31
32+Pint = secprop->Add_int("mt32.reverb.output.gain", Property::Changeable::WhenIdle, 100);
33+Pint->Set_values(mt32gainValues);
34+Pint->SetMinMax(0,65535);
35+Pint->Set_help("Reverb output gain of MT-32 emulation.");
36+
37 const char *mt32reverbLevels[] = {"0", "1", "2", "3", "4", "5", "6", "7",0};
38 Pint = secprop->Add_int("mt32.reverb.level",Property::Changeable::WhenIdle,3);
39 Pint->Set_values(mt32reverbLevels);

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

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

Qbix wrote:

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

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.

Yesterplay80 wrote:

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

troydm wrote:

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.

troydm wrote:

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.

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!

Delfino Furioso wrote:

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 ?

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.

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

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

1[sdl]
2fullscreen           = false
3fulldouble           = false
4fullresolution       = desktop
5windowresolution     = desktop
6output               = ddraw
7surfacenp-sharpness  = 50
8surface-collapse-dbl = false
9autolock             = true
10xsensitivity         = 100
11ysensitivity         = 100
12waitonerror          = true
13priority             = higher,normal
14mapperfile           = mapper-ECE.map
15usescancodes         = true
16
17
18
19[dosbox]
20language = 
21machine  = svga_s3
22captures = capture
23memsize  = 30
24
25
26
27[render]
28frameskip = 0
29aspect    = true
30scaler    = tv2x forced

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.

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

Qbix wrote:

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.

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.

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. 😉

Yesterplay80 wrote:

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

troydm wrote:

Could you please remove Pint->Set_values(mt32gainValues) calls from mt32options.h and related const char *mt32gainValues[] = {" […]
Show full quote

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?