My DosBox fork. OpenGL 3 GLSL shaders, FluidSynth (SDL2)

[dugan]

I wanted to try out some of the patches I saw in the patches forum. One thing led to another, and now I have a DosBox fork. Here are my fork's release notes:

https://github.com/duganchen/dosbox/blo ... CEMENTS.md

The patches I ended up incorporating are xBRZ scaling, FluidSynth (GM soundfont support) and Munt (MT-32 emulation). All three of which, to me, genuinely improve the DosBox experience. As for why only those three, believe me when I say that narrowing down the list was as much a part of this project as adding features.

I worked hard to get all three patches properly integrated DosBox's autotools-based build system. It should be very easy to build this fork on Linux and on any other platform that uses autoconf.

So far I've tested only on my current desktop machine, which is 64-bit Slackware 14.1, with no Pulseaudio (only ALSA). It works well on that platform.

Anyway, I thought I'd share what I ended up with. Enjoy.

UPDATE: I've edited the title to highlight the current features.

[Dominus]

Thanks for letting us know!

I moved it to the patches subforum.

[dugan]

I've just updated it with GLSL shader support. Two xBR shaders (SABR and SABR-XCOMified) and a selection of CRT shaders are included.

[ともよ]

I tried this fork and couldn't hear any midi playback. The soundfont was set and I don't see any errors, I just hear no midi sound. What could be wrong?

[dugan]

What could be wrong? Well, I can imagine some thing...

The first is not having FluidSynth's development packages installed at the time that you build the fork. As mentioned in the release notes, if that is unavailable then the fork will be built without soundfont support. You should be able tell from the ./configure output whether building in FluidSynth support is succcessful.

This fork adds entries to what would go in dosbox.conf, so I recommend removing (or renaming) your ~/.dosbox directory before launching it. That will allow it to write a ~/.dosbox/dosbox-SVN.conf with the appropriate defaults.

At that point, your default, program-written ~/.dosbox/dosbox-SVN.conf should contain many comments about FluidSynth support. If it doesn't, then soundfont support was not compiled in, and you need to build it again.

On my Slackware system (which uses ALSA and not Pulseaudio), the file I use to launch Gabriel Knight: Sins of the Fathers has the following:

Code: Select all

[midi]
mididevice=fluidsynth
fluid.driver=alsa
fluid.soundfont=/storage/Downloads/soundfonts/Scc1t2.sf2

I'd imagine that fluid.soundfont should probably be an absolute path, starting with a slash and containing no tildes or environment variables. I would also imagine that if you're on a system that uses Pulseaudio, then fluid.driver should be set to pulseaudio.

And, of course, the game must be set to use General MIDI. The volume of the game's BGM might need to be turned up in-game, and you can check the volume by switching it to, say, SoundBlaster support. Then, when you've confirmed that it works with SoundBlaster support, can switch back to General MIDI in the game and FluidSynth support in DosBox. I hate to mention this, but it does come under the "what could be wrong" umbrella.

A problem with the soundfont itself is unlikely, but you can check by using FluidSynth to play a MIDI file with that soundfont.

Finally, you should be aware that the patch I used to get soundfont support is this one:

viewtopic.php?f=32&t=27831&start=20#p385413

Soundfont support does work for me, and I was just using it today.

If you still need more, then knowing your Linux distribution, the game you're trying to play and the soundfont you want to use with it would give me a better picture.

[dugan]

I've just pushed a major update to the master branch. It's now powered by SDL 2 and can use custom shaders, which I have a good selection of. I'll leave you to look at ENHANCEMENTS.md

The collection of shaders is a stored in a separate repository, here:

https://github.com/duganchen/dosbox_shaders

I've tested it on Linux and OS X. I have not attempted to support Windows yet.

The previous release has been saved as the "r3911-xbrz" tag.

[emendelson]

Is anyone generous-minded enough to suggest how to build this fork under OS X? I was able to build SDL2 (with MacPorts installed on the system), but I can't figure out how to ./configure this build so that it can find SDL. I know that this is an elementary question, and I'll be grateful for any detailed advice.

What I'd really like to do is build a static-linked version eventually, but building anything at all would be a good start.

Thanks!

[Dominus]

Deactivate sdl 1.x in macports and then let it run?

[dugan]

I can't help with MacPorts because I don't use it. I use Homebrew, and IIRC GLEW, FluidSynth and SDL2 were all found by DosBox's ./configure (just ./configure with no flags) after being installed with Homebrew.

Munt (if you want to try the built-in MT-32 emulation) needs to be built with ./configure; make ; make install to be found by DosBox. I've had much better results just connecting DosBox to a running copy of Munt though.

[emendelson]

Thanks for this - I'm probably bumping up against problems with MacPorts, which puts things in /opt/local. I installed GLEW. libsdl2, and FluidSynth,and I added /opt/local/bin and /opt/local/include to my PATH, but I still bump up against the error message:

sdlmain.cpp:59:10: fatal error: 'GL/glew.h' file not found

The file is in /opt/local/include/GL, but I'm too much of a beginner to know how to tell "make" to find it. I'll keep experimenting - and might try a separate system with HomeBrew...

[dugan]

From what you just wrote, I would definitely recommend installing the dependencies with Homebrew instead of MacPorts. Homebrew actually puts files (and symlinks) where the compiler expects to find them. Then doing a DosBox build for your system is literally just ./configure ; make ; make install.

I can only make suggestions on building this against dependences installed with MacPorts. To continue, you'd also need to also know where MacPorts install its link libraries (I'm going to guess /opt/local/lib). Then I'd suggest trying:

Code: Select all

CXXFLAGS="-I/opt/local/include" LDFLAGS="-L/opt/local/lib" ./configure

Or:

Code: Select all

CXXFLAGS="-I/opt/local/include -L/opt/local/lib" ./configure

[emendelson]

I tried the first of the two alternatives, and it worked perfectly! Thank you. It's very generous of you to take the trouble to help with this kind of beginner's question. I'll look forward to experimenting with this extremely interesting fork.

I've now got two systems going, an old one with MacPorts, a new one with no ports at all (no MacPorts, no HomeBrew). Thanks to Dominus's patient and generous, I've been able to build a transportable build of DOSBox on my MacPorts system, and I don't want to lose the chance to bother Dominus for help. But I may try installing HomeBrew on my new system and see if I can get things working.

Thank you again. This is the first port I've seen that uses SDL2 under OS X, and it would be interesting to try to get it working under Windows someday - though I know that's far beyond my abilities.

[dugan]

Here are two screenshots that I think justify the project. The first is the EGA verison of LOOM as it usually is in ScummVM and DosBox. Note the dithering, which the monitors of the day would have displayed as solid colors:

https://www.dropbox.com/s/8z16s7rxlvnf4 ... .png?raw=1

The second is the EGA version of LOOM with jinc2-sharp shader. Notice that the dithering is gone:

https://www.dropbox.com/s/0qnbuv43b4y6f ... .png?raw=1

These are large images taken on my 13" retina MacBook Pro, so I chose to link to them instead of inlining them.

[Dominus]

Emendelson: I assumed you'd use the same exports you use when building normal Dosbox...

[emendelson]

Dominus: That's what I tried first, but I'm pretty sure I didn't do enough to prepare things for the new fork, so it didn't work. That was my fault - not the fault of the exports. I'll try it again later today and report back.

[emendelson]

Dominus: I wasn't able to use the same exports, etc. - too many changes in SDL2, and too many additional things needed (GLEW, FluidSynth). This is very interesting, but, at least for a while, I'll leave it for people more expert than I am!

[Great Dragon]

I wanted to try out some of the patches I saw in the patches forum. One thing led to another, and now I have a DosBox fork. Here are my fork's release notes:
https://github.com/duganchen/dosbox/blo ... CEMENTS.md

Hello Dugan,

It's awesome what you did. You even have my favorite crt-lottes shader.
But unfortunately I can't build your fork by myself. Could you please provide your build for Windows to the community (ok it's actually just me for now)?

[dugan]

A Windows build isn't something that I can give you a timeframe for, unfortunately. I haven't even attempted one yet!

[emendelson]

I tried to build for Windows (using Visual Studio) the other day, but couldn't figure out all the includes, and kept getting errors in the render routines, so I stopped trying. Will look forward to any advice from anyone who figures it all out!

[dugan]

Dominus: I wasn't able to use the same exports, etc. - too many changes in SDL2, and too many additional things needed (GLEW, FluidSynth). This is very interesting, but, at least for a while, I'll leave it for people more expert than I am!

FluidSynth was never needed. It would be detected and enabled if you had it, but it would build fine without it.

As of today, GLEW is no longer a dependency. It's included right in the source tree now.

I've also dropped the "native" mt32 support. It was never as good as just starting munt and connecting DosBox to it.

EDIT: And xBRZ (which is a CPU-based scaler) I dropped quite a while ago.