VOGONS

Common searches


First post, by dugan

User metadata
Rank Newbie
Rank
Newbie

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/blob/mast … ENHANCEMENTS.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.

Last edited by dugan on 2016-02-23, 18:52. Edited 5 times in total.

Reply 1 of 72, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Thanks for letting us know! 😀

I moved it to the patches subforum.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 4 of 72, by dugan

User metadata
Rank Newbie
Rank
Newbie

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:

[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:

Fluidsynth soundfont patch

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.

Reply 5 of 72, by dugan

User metadata
Rank Newbie
Rank
Newbie

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.

Last edited by dugan on 2016-02-23, 01:08. Edited 3 times in total.

Reply 6 of 72, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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!

Reply 7 of 72, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 8 of 72, by dugan

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 9 of 72, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 10 of 72, by dugan

User metadata
Rank Newbie
Rank
Newbie

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:

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

Or:

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

Reply 11 of 72, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 12 of 72, by dugan

User metadata
Rank Newbie
Rank
Newbie

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/8z16s7rxlvnf4cq/loo … tered.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/0qnbuv43b4y6fi5/loo … arper.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.

Reply 13 of 72, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 14 of 72, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 15 of 72, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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!

Reply 16 of 72, by Great Dragon

User metadata
Rank Newbie
Rank
Newbie
dugan wrote:

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/blob/mast … ENHANCEMENTS.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)?

Reply 18 of 72, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

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!

Reply 19 of 72, by dugan

User metadata
Rank Newbie
Rank
Newbie
emendelson wrote:

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.

Last edited by dugan on 2017-03-06, 06:30. Edited 3 times in total.