AvalonH wrote on 2020-02-12, 17:45:

What sample rate do others use for the following settings in the config file : […]
Show full quote

What sample rate do others use for the following settings in the config file :

dosbox mixer=
mt32.rate=
fluid.samplerate=
oplrate=
gusrate=
pcrate=
tandyrate=

At the moment I have all the above set at 49716.
If I set the correct rates to stop any sample rate conversion, mt32.rate=32000 I get muffled sound. Setting the dosbox mixer to 32000khz to match the mt32 fixes it, but then games that also use the SB16 for digital audio sound muffled. I guess there isn't an optimum setting when using two sound devices without having to use sample rate conversion.

With mt32, you can set that to anything and it's fine unless you do mt32.analog=3, which may playback at the wrong rate. So if it sounds muffled, set MT32.analog to 2 first before changing the frequency. mt32.analog=2 is 48000.

Strange Question here,
I am using genuine midi hardware (Um-One MK2 and a SC-55 MKII, SC-8850 and an MT-32).
When playing a game that uses pure General Midi i get often hanging notes. It's not at the same places in the midi song but sooner or later a note will hang until i reset the midi module.
All my midi modules exhibit the same issue with Dosbox ECE R4301 and newer versions like R4178.

When i duplicate the profile to a normal vanilla dosbox 0.74 the issue is not present.

These are my settings for the midi on all dosbox profiles , 0.74 , ECE_r4301 & r4178.

mpu401 = intelligent
mididevice = win32
midiconfig = 0 delaysysex (0= coolsoft midi mapper that goes to my um-one module, 5 = the um-one module directly but both have the same issue)

Anyone has an idea to fix this ?

Many thanks !

I usually have the output set to openglpp, but when I installed the newest version, it says that openglpp is not a valid value and sets the output to surface.

I know they are having trouble with the pixel perfect patch, maybe the openglpp option is tied to that and it will be missing until they reintroduce it.

7F20 wrote on 2020-02-21, 01:45:

I know they are having trouble with the pixel perfect patch, maybe the openglpp option is tied to that and it will be missing until they reintroduce it.

That's right, I just updated the web site accordingly.

What was the last version with Pixel perfect scaling? r4301?

Srandista wrote on 2020-02-21, 15:05:

What was the last version with Pixel perfect scaling? r4301?

Yup.

Hi. I like the idea of a "pixel perfect" DOSBox build but when I select that option in DOSBox ECE there are small black bars at the top and bottom of my 43" 1920X1080 display. I don't mind the letterboxing on the sides but prefer not to lose any of that nice 1080p screen real estate if I can help it. Selecting the "near pixel perfect" option displays the image with the full height of my screen so I'm wondering if there's any real reason to use "pixel perfect" since np seems pretty decent. But are the black bars on top/bottom normal for pp on a 1080p display? I'm thinking a nice CRT shader is more important to me than PP and I do in fact use a 2014 build of DosBox DAUM that supports shaders and I'm using a good one with it but would prefer an updated patched DOSBox SVN build like the ECE edition.

JackOfOwls wrote on 2020-02-23, 15:34:

Hi. I like the idea of a "pixel perfect" DOSBox build but when I select that option in DOSBox ECE there are small black bars at the top and bottom of my 43" 1920X1080 display. I don't mind the letterboxing on the sides but prefer not to lose any of that nice 1080p screen real estate if I can help it. Selecting the "near pixel perfect" option displays the image with the full height of my screen so I'm wondering if there's any real reason to use "pixel perfect" since np seems pretty decent. But are the black bars on top/bottom normal for pp on a 1080p display? I'm thinking a nice CRT shader is more important to me than PP and I do in fact use a 2014 build of DosBox DAUM that supports shaders and I'm using a good one with it but would prefer an updated patched DOSBox SVN build like the ECE edition.

@JackOfOwls - If I had to guess how the pixel-perfect option works, it's resizing the original resolution (i.e., 320x200 or 320x240, usually) via what is commonly called integer scaling.

So if you take your screen's height of 1080 pixels and divide that by 200, you get 5.4. So, keeping the pixels "perfect" (i.e., square), the 200 pixel resolution is only multiplied by 5 (meaning each original pixel is now a 5x5 pixel on your LCD monitor). However, 5 times 200 is only 1000 pixels, leaving you 40 pixels of blank space on the top and bottom of the screen. If the game is running a resolution 240 pixels tall, that goes into 1080 by 4.5 times, meaning, you'll only get 4 times 240 = 960 pixels tall, leaving 60 pixels on the top and bottom of the screen blank (120+960 = 1080).

However, non-square pixels are a real thing. With most monitors of that era being 4:3, pixels almost always were distorted for games unless the resolution was perfectly 4:3 (i.e., 320x240, 640x480, etc.).

It's just that some people don't like the "blurring" that occurs with non-integer scaling.

However, to mitigate this, you can use a normal3x or something similar where the games resolution is rendered at 3x the # of pixels and then resized rather then being resized from it's original resolution to minimize any blurring due to scaling.

Pr3tty F1y wrote on 2020-02-23, 21:58:

It's just that some people don't like the "blurring" that occurs with non-integer scaling.

Because blurring causes eye strain. The bilinear blur you see when you play a low resolution game on a high resolution monitor is not supposed to exist. That blur is only acceptable when rescaling live-action video, and even then, only because it's lossy to begin with, and that lossiness is disguised as part of the blur.

Some people want their screens to look more like a CRT when they play legacy video games (I'm not one of them) and it's really kind of mind-boggling why you would hurt your eyes on purpose when you certainly don't need to. Likewise there are also some people who think pixelated looks are ugly and apply smoothing shaders, and that's even worse IMO since the result ends up looking like smeared paint.

The ideal result is that square pixel's are integer scaled (nearest neighbor) 1x,2x,3x,4x,5x,6x, etc and a GPU shader does this without extra cost. Non-square (eg 320x200) requires a specific resolution to scale to perfectly (x9) 2880x1800 -> 2880x2160 , which happens to be the native height resolution of a 4K screen. Any other resolution is not "pixel perfect" so to speak. Now, if you scale it back down to 1080p (4.5x) every second line will be 4 or 5 pixels tall, and it creates a wobble when things move vertically, this is why you get a x4 instead ( 1280x800 -> 1280x960 )

Not sure if this is the right place to report this, but Stonekeep crashes with DOSBox ECE while working fine on regular DOSBox. This is with a clean .conf file.

ECE version was r4330 and regular version was 0.74-3.

Joseph_Joestar wrote on 2020-02-25, 09:14:

Not sure if this is the right place to report this, but Stonekeep crashes with DOSBox ECE while working fine on regular DOSBox. This is with a clean .conf file.

ECE version was r4330 and regular version was 0.74-3.

Stonekeep runs fine for me with the latest ECE version.

Pat86 wrote on 2020-02-25, 15:43:

Stonekeep runs fine for me with the latest ECE version.

Do you have Stonekeep patch 1.2 installed? It does something weird to the bat file that starts the game. Maybe that's the cause.

It still works fine in regular DOSBox though.

Can you check if it works with the non-ECE version ?

Qbix wrote on 2020-02-25, 17:04:

Can you check if it works with the non-ECE version ?

It works fine with the current non-ECE version of DOSBox (r4330). No crashes there.

EDIT - now I can no longer reproduce the crash on the ECE version either... weird. Disregard the report, the crash may have been caused by something locally.

Hi and thanks a lot for these excellent emulators. I like to keep copies of the original DosBox, DosBox-X and the ECE edition because they all have their good ways of handling my fav games.

I have some questions involving DosBox-X and DosBox ECE because I'm trying to give Linux Mint a whirl and still learning the ins and outs of it. I can run DosBox-X through WINE just fine, but I can't seem to get Soundfonts to work on it. And I know ECE handles Soundfonts just fine because it works perfectly on a Windows machine, but I can't run it through WINE, and when I download the Linux version, all I find is an extension-less Dosbox file in a BIN folder and have no idea how to open it. So here are my questions:

1. Am I doing something wrong to make DosBox-X and its soundfont support not work? I changed the settings to use "Synth" and I've pointed it towards the SGM.sf2 file in three separate ways by putting the file name by itself, by putting it in the WINE C drive root and directing it to the C drive, and of course, by directing it to /home/me/.wine/drive_c and in each case, MIDI sound doesn't come on. I've also tried setting to 10,000 cycles instead of auto or max because I read on here that could be a problem, but no help.

2. Is there a way to get DosBox ECE working through WINE? It just loads the two windows then sits there. I've tried changing winecfg to point to Windows 10, XP, nothing works.

3. How do I run the Linux version of DosBox ECE with that extention-less file in the BIN folder? Is it something I need to point the file to like some kind of program opener, or is it something I need advanced skills with to compile or something like that? Linux noob here, ya know.

Thanks a lot for the emus and for any and all responses, folks!

RodanLewarx wrote on 2020-02-28, 12:07:

3. How do I run the Linux version of DosBox ECE with that extention-less file in the BIN folder? Is it something I need to point the file to like some kind of program opener, or is it something I need advanced skills with to compile or something like that? Linux noob here, ya know.

You could either drag and drop the file into a terminal window or call it from there. You can also make the file executable with

1sudo chmod +x <path/to/dosbox/file>

However, it might not run as it is, it could also be that you have to compile the source code and its dependecies on your
machine.

You really should be running the Linux version of dosbox on Linux and not the Windows version through wine.

As to running the Linux version, keep in mind that on Linux, unlike on windows, your current directory is NOT in your path. So if you see an executable called dosbox in your current directory, unless your current directory happens to be in your path, just typing the executable name will NOT run it. This is a security thing.
To run an executable anyway you need to give the path to it, even if its in your current directory. As a shortcut you can just put ./ in front of it. So if your directory contains an executable called "dosbox", you can run it by typing ./dosbox and pressing enter.

As to General Midi, you need to set dosbox to output to fluidsynth. And install a SoundFont such as FluidR3.

[midi]
mpu401=intelligent
mididevice=fluidsynth

Or for MT32 (point it to your MT-32 ROMs dir)

[midi]
mpu401=intelligent
mididevice=mt32
mt32.romdir=~/roms/mt32

Or for CM32L (point it to your CM32L ROMs dir)

[midi]
mpu401=intelligent
mididevice=mt32
mt32.romdir=~/roms/cm32l

Thanks for the suggestions and answers. I tried to run the Linux version with the terminal command you suggested and it complained about missing libsdl1.2, so I installed it, but it still didn't seem to work. I'll have to continue checking this out.

Nicely said from Rob too that I should run Linux programs made for Linux while on Mint, definitely the better choice.

Opposite but good news is that sometime between the start of 2020 and the newest update of ECE in the end of February, there was some kind of update to let ECE run through Wine without it hanging (I was using an archived version I saved on New Year's which didn't work, but the new one did). I tried putting in the SGM soundfont in and messing with the config file, and painlessly later, there were my new rockin' electric guitars at the start of Doom. So while it's not ideal that ECE works through Wine now, I can confirm it does work.

I'll keep checking about Linux terminal and dependency issues. Thanks!

RodanLewarx wrote on 2020-02-29, 05:14:

Thanks for the suggestions and answers. I tried to run the Linux version with the terminal command you suggested and it complain […]
Show full quote

Thanks for the suggestions and answers. I tried to run the Linux version with the terminal command you suggested and it complained about missing libsdl1.2, so I installed it, but it still didn't seem to work. I'll have to continue checking this out.

Nicely said from Rob too that I should run Linux programs made for Linux while on Mint, definitely the better choice.

Opposite but good news is that sometime between the start of 2020 and the newest update of ECE in the end of February, there was some kind of update to let ECE run through Wine without it hanging (I was using an archived version I saved on New Year's which didn't work, but the new one did). I tried putting in the SGM soundfont in and messing with the config file, and painlessly later, there were my new rockin' electric guitars at the start of Doom. So while it's not ideal that ECE works through Wine now, I can confirm it does work.

I'll keep checking about Linux terminal and dependency issues. Thanks!

The architecture version of libsdl1.2 needs to match your dosbox binary. So if it is a 32bit version you need a 32bit libsdl1.2. To find out if your dosbox binary is 32 or 64bit run the command

1 file dosbox
2 dosbox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=4488e27b157862b059d5f2600fb85a1010600529, stripped

As you can see, mine is a 64 bit binary.

Also which linux distribution are you using, and how did you install the library?