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