VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 520 of 1014, by Yesterplay80

User metadata
Rank Member
Rank
Member
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?

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 521 of 1014, by troydm

User metadata
Rank Newbie
Rank
Newbie
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

--- 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);

Reply 522 of 1014, by Yesterplay80

User metadata
Rank Member
Rank
Member

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

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 523 of 1014, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Water flows down the stream
How to ask questions the smart way!

Reply 524 of 1014, by troydm

User metadata
Rank Newbie
Rank
Newbie
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

Reply 525 of 1014, by Samantha Ann Mulder

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 526 of 1014, by troydm

User metadata
Rank Newbie
Rank
Newbie
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

Reply 527 of 1014, by Yesterplay80

User metadata
Rank Member
Rank
Member
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.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 528 of 1014, by Delfino Furioso

User metadata
Rank Newbie
Rank
Newbie

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!

Reply 529 of 1014, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author
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 ?

Water flows down the stream
How to ask questions the smart way!

Reply 531 of 1014, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Water flows down the stream
How to ask questions the smart way!

Reply 532 of 1014, by Delfino Furioso

User metadata
Rank Newbie
Rank
Newbie

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

[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
Last edited by Delfino Furioso on 2018-12-03, 10:48. Edited 1 time in total.

Reply 533 of 1014, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Water flows down the stream
How to ask questions the smart way!

Reply 534 of 1014, by Delfino Furioso

User metadata
Rank Newbie
Rank
Newbie

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

Reply 535 of 1014, by Yesterplay80

User metadata
Rank Member
Rank
Member
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.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 536 of 1014, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Water flows down the stream
How to ask questions the smart way!

Reply 537 of 1014, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Reply 538 of 1014, by troydm

User metadata
Rank Newbie
Rank
Newbie
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

Reply 539 of 1014, by Yesterplay80

User metadata
Rank Member
Rank
Member
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?

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)