Nevertheless, they’ve tweaked a lot of the DOSBOX settings for CPU cycles and such on their end already, so that should save me some heavy lifting and fine-tuning… hopefully.

Here are some of the software / utilities I used when bringing in some GOG games:

GOG install and personal tweaks to GOG’s DOSBOX

So, I installed GOG Galaxy, linked my account, and found the myriad of games I’ve purchased over the years. First stop, a personal favorite – Heroes Of Might and Magic. I’m going to focus on the first of the series, which uses DOSBOX.

Now, my personal flavors on DOSBOX gaming are that I’d like full screen (I’d prefer borderless window but that’s not something I’m sure I can do with DOSBOX) at the host machine’s resolution, so I don’t encounter a crap ton of resolution switching on my monitor if I want to look at manuals or reference cards.

In the past, I would manually tweak a GOG games unique DOSBOX config to my liking, with generally these settings:

[sdl]
fullscreen=true
fullresolution=desktop
output=opengl

[render]
aspect=true

GOG stores the main dosbox config for each game in the game’s dosbox<abbreviation>.conf file. So for Heroes of Might and Magic 1, that ends up being dosboxHOMM1.conf. I may automate some of these changes, but for now I’m manually doing these to see how things play out first. In fact, each GOG game gets its own DOSBOX copy stored underneath the game’s main directory:

The game loads up fine, though I do find it annoying that if I alt-tab out to look up a page in the manual and go back, DOSBOX reverts to the window, I have to hit alt-enter to go back to full screen. At least I don’t have the monitor itself changing resolutions on top of it. DOSBOX-X, thankfully, doesn’t do that, but we’ve not converted our GOG HOMM to DOSBOX-X yet.

DOSBOX-X install and initital configuration

Now, I’ve installed my generic DOSBOX-X copy in a single directory under my D:\Emulators path:

Now, as far as DOSBOX-X goes, I’ve edited the dosbox-x.conf that comes with the download and tweaked to my liking.

[sdl]
output=opengl
fullscreen=true
autolock=true
autolock_feedback = none

[render]
aspect         = true
aspect_ratio   = 4:3
glshader       = crt-lottes-krystof.glsl

You may notice the glshader entry in there. That’s a custom one I was tweaking – you can make your own or point to one of the built in defaults under the glshaders directory. Definitely something to play around with.

Swapping HOMM’s DOSBOX for my DOSBOX-X

If I run dosbox-x.exe, it works, and everything is happy. Now, the question I have… Can I somehow swap out the DOSBox that my GOG Heroes of Might and Magic usses to use my global DOSBox-X directly? It leads me to other questions:

• How do we point a GOG game to use my dosbox-X under D:\emulators\dosbox-x? What about configs?
• If we can swap a GOG’s dosbox to dosbox-x, can one dosbox-x config handle all the GOG games? Probably not
• How do we have a common config and allow overrides as needed with dosbox-x?
• How can we take a GOG’s customized DOSBOX-.74 config and overlay them on top of my global DOSBOX-X config?

First off, the manual approaches. Even if this works for one game, that doesn’t mean it will work for all, so I anticipate having to come back and make changes. Perhaps I can automate some of them.

HOMM GOG’s DOSBox has multiple configuration files:

The launcher link also calls this, and starts with the current directory set to inside it’s local DOSBOX folder:

"D:\GOG Galaxy\Games\HoMM\DOSBOX\DOSBox.exe" -conf "..\dosboxHOMM1.conf" -conf "..\dosboxHOMM1_single.conf" -noconsole -c "exit"

So we can see they’re already using overrides – the ‘single’ conf file overrides their HOMM global config file. We also have some relative paths in there, going to the parent directory (which is the HOMM install). The ‘single’ file seems to be more of the autoexec related work, and doesn’t try to override much in the way of rendering, though it does shut ipx off.

Brute Force – Duplicate DOSBOX-X and use it against the GOG HOMM’s DOSBOX 0.74 configs

How can I swap out the EXE? I could just copy all of dosbox-x and duplicate a game-unique DOSBOX install inside HOMM’s dosbox directory, which is effectively what they do. Let’s try that, and rename dosbox-x.exe to just dosbox. This means we won’t have to change the shortcut. I did that and to be sure, deleted any dosbox-x.config files in my HOMM dosbox copy. So now we have the DOSBOX-X binary being executed, but using the dosboxHOMM config files, which we know target the original DOSBOX-0.74 version. Just because we’re using DOSBOX-X binaries doesn’t mean we can assume DOSBOX 0.74 configs will just work 100% without flaw. At least I wouldn’t think so. Perhaps I have trust issues.

Result? Successful proof of concept. It worked – with a side note. I had to click into the program and heard an audible ‘click’ when I activated the window. I don’t recall that being a thing. But we aren’t taking advantage of any spiffy DOSBOX-X configs, and if there are any defaults in our global dosbox-x we set, we’re not picking them up, since we made a complete duplicate dosbox-x. It’s not what I want long term.

Next step – Overwrite dosboxHOMM1.conf with our dosbox-x global config contents.

I tried this just to see if it would still load. Now what this also means is that we would lose ANY HOMM specific dosbox configurations since we’re going to replace it with dosbox-x. So things like CPU cycle settings, sound card configs, xms,ems settings, etc. that GOG curators put in there would be lost. This probably won’t fly long term, just wanted to see how well it would work. So, I wiped did a copy and paste of the file contents of my global dosbox-x.conf into the file dosboxHOMM1.conf.

Result? Mixed but doable. We did get the shader working, but a couple of oddities. The mouse only worked in full screen mode. In window mode (for dosbox x you toggle full screen with F11-F) I couldn’t get a mouse cursor anymore. Switching back to fullscreen fixed that. To solve this, I needed to change my dosbox-x.config:

[sdl]
autolock=true
autolock_feedback = none

autolock_feedback set to none removes the ‘click’ when dosbox locks the mouse (that same audible click I heard the first attempt). Your call. You can hit CTRL-F10 to unlock the mouse again.

Dont’t forget, we copied our dosbox-x.conf contents into dosboxHOMM1.conf. That’s not a good long term solution, we’re just doing proof of concept.

So, that worked, but it worked this time... I totally expect some games to not tolerate this, because something in the game specific DOSBOX config would be lost if we did this for each game. You can see with the autolock we already had a deviation from the dosbox-x default, but in this case, I’m fine with changing it. However, it won’t always be the case – what if a DOS game wants EMS memory setup but another DOS game crashes because of it? I suspect I’ll have to handle those cases.

What would be useful is a program that parses dos box config files, looks for values that don’t match default or ignorable patterns, and reports just meaningful differences. Then we can take those differences, put them in the override dosbox config (e.g. dosboxHOMM1_single.conf), and still use our generic dosbox-x.conf as the primary for all of our games. That’d be great, because if we want a different shader, they automatically apply to all the games. We can still use the override file if we want to change it for a specific game, too.

What about those .lnk (Windows Shortcut) files? GOG is using those to launch from it’s launcher. If I import GOG games into LaunchBox, it’s going to use those .lnk files as well. I’d like to leave the link intact, but I may need to modify them if I want to try to make some global dosbox.config usable. But say I could do that, what does that look like?

Attempting to use a single DOSBOX-X install and base config for multiple GOG games

Let’s see if this even works before I worry about modifying Windows Shortcut links.

Resetting our GOG HOMM from scratch again…(Backups backups backups)

Recall our initial .lnk shortcut pointed this way and starts with the current directory set to inside it’s local DOSBOX folder:

"D:\GOG Galaxy\Games\HoMM\DOSBOX\DOSBox.exe" -conf "..\dosboxHOMM1.conf" -conf "..\dosboxHOMM1_single.conf" -noconsole -c "exit"

That means dosboxHOMM1_single.conf is referencing paths from the standpoint of our GOG HOMM’s DOSBox directory. So we must start our command there just like the link does. But if we want to use a global DOSBOX config in our D:\Emulators\dosbox-x, we’re at a bit of an impasse.

So, in a command line prompt, I switched to the GOG HOMM DOSBOX directory and ran this command line instead from the GOG HOMM DOSBOX dir:

D:\GOG Galaxy\Games\HoMM\DOSBOX> d:\Emulators\dosbox-x\dosbox-x.exe -conf "d:\Emulators\dosbox-x\dosbox-x.conf" -conf "../dosboxHOMM1_single.conf"

This actually worked. I was surprised, since I half expected it to not find my custom shader, but it looks like dosbox-x is looking in it’s folders appropriately. But what about any DOSBOX junk in the GOG HOMM folder left over? We’re not actually using that DOSBOX anymore, we’re just starting in that directory so the relative paths in our dosboxHOMM1_single.conf work.

My current plan is as follows for each GOG game, and summarizes the plan based on our results above:

• Modify the .lnk to point to our DOSBox-X base config, but still utilize the game-specific override config
  • I”ll look at this GitHub repo and maven artifact: https://github.com/DmitriiShamrikov/mslinks which seems to allow me to edit windows shortcuts programmatically.
  • Using that, I now have some throwaway-ish Java code that does the following:
    • Spin through GOG games via network share to my retro machine
    • Look for a shortcut in each game root folder
    • If shortcut has dosbox in its target, make backups of the GOG DOSBOX config files.
    • Point the first config in the shortcut to our dosbox-x global config under D:\Emulators\dosbox-x instead of the GOG game specific primary dosbox.config
    • Change the shortcut target to point to our dosbox-x.exe in D:\Emulators\dosbox-x
• If a game doesn’t ‘just work’ with DOSBox-X: Look at the now abandoned ‘GOG-specific’ dosbox config and determine if anything unique to that GOG game needs to be put in the override config. See if we can automate this looking for the most common reasons a DOSBox game would have issues (e.g. cpu cycles)
  • I’ll have to find a DOSBox properties parser or roll my own. We need to support [bracket] sections and retain linefeeds and comments. I searched around a bit and though I found some INI file parsers, they didn’t handle the DOSBOX autoexec section very well (since they’re not key-value pairs). Ended up rolling my own simple parsing mechanism that gets the job done.

Progressing through my GOG installs

After figuring out how to do this for Heroes of Might and Magic 1 and 2 (the rest in the series are native windows apps from GOG), I continued on with my other GOG installs. Anything of interest noted below:

DOSBOX Settings I take from the GOG install and put into the override file before pointing a GOG game at DOSBOX-X

My thought is that I only want to take certain settings out of GOG’s DOSBOX-0.74 config and put them into the override file. If I take everything, it would overwrite full screen and shader settings that I want to utilize with the DOSBOX-X binaries and my global config.

I thought it’d be an interesting exercise to look at ALL GOG DOSBOX configs at once and count occurrences of unique key value pairs. Here’s the raw dump:

Occurences of keys/values across all dosbox GOG configs:
83	 cpu.core.auto
4	 cpu.core.dynamic
3	 cpu.core.normal
9	 cpu.core.simple
1	 cpu.coretype.auto
5	 cpu.cputype.386_slow
5	 cpu.cputype.486_slow
86	 cpu.cputype.auto
1	 cpu.cputype.pentium_slow
3	 cpu.cycledown.100
88	 cpu.cycledown.1000
1	 cpu.cycledown.10000
2	 cpu.cycledown.20
1	 cpu.cycledown.50
2	 cpu.cycledown.500
2	 cpu.cycledown.5000
1	 cpu.cycles.10000
1	 cpu.cycles.100000
1	 cpu.cycles.11000
1	 cpu.cycles.15000
2	 cpu.cycles.19000
2	 cpu.cycles.20000
1	 cpu.cycles.300
1	 cpu.cycles.3000
1	 cpu.cycles.35000
1	 cpu.cycles.4000
3	 cpu.cycles.500
2	 cpu.cycles.5000
1	 cpu.cycles.50000
1	 cpu.cycles.7500
2	 cpu.cycles.8000
1	 cpu.cycles.80000
1	 cpu.cycles.9000
29	 cpu.cycles.auto
2	 cpu.cycles.auto limit 16000
1	 cpu.cycles.fixed 10000
1	 cpu.cycles.fixed 12500
2	 cpu.cycles.fixed 14000
1	 cpu.cycles.fixed 15000
2	 cpu.cycles.fixed 30000
1	 cpu.cycles.fixed 35000
1	 cpu.cycles.fixed 6000
1	 cpu.cycles.fixed 60000
1	 cpu.cycles.fixed 7000
1	 cpu.cycles.fixed 8000
33	 cpu.cycles.max
2	 cpu.cycleup.10
3	 cpu.cycleup.100
88	 cpu.cycleup.1000
1	 cpu.cycleup.10000
1	 cpu.cycleup.50
2	 cpu.cycleup.500
2	 cpu.cycleup.5000
1	 dos.automount.true
2	 dos.ems.false
97	 dos.ems.true
1	 dos.files.127
93	 dos.keyboardlayout.auto
6	 dos.keyboardlayout.none
99	 dos.umb.true
99	 dos.xms.true
98	 dosbox.captures.capture
98	 dosbox.language.
98	 dosbox.machine.svga_s3
1	 dosbox.machine.vesa_nolfb
83	 dosbox.memsize.16
9	 dosbox.memsize.30
3	 dosbox.memsize.32
3	 dosbox.memsize.63
1	 dosbox.memsize.8
1	 dosbox.vmemsize.4
1	 glide.glide.true
1	 glide.grport.600
1	 glide.lfb.full
3	 gus.dma1.3
3	 gus.dma2.3
96	 gus.gus.false
2	 gus.gus.true
96	 gus.gusbase.240
93	 gus.gusdma.3
93	 gus.gusirq.5
7	 gus.gusrate.22050
89	 gus.gusrate.44100
3	 gus.irq1.5
3	 gus.irq2.5
96	 gus.ultradir.C:\ULTRASND
1	 innova.innova.false
1	 innova.quality.0
1	 innova.samplerate.22050
1	 innova.sidbase.280
2	 ipx.Connection.0
2	 ipx.Enable.0
7	 ipx.ipx.false
98	 joystick.autofire.false
64	 joystick.buttonwrap.false
34	 joystick.buttonwrap.true
1	 joystick.joysticktype.2axis
97	 joystick.joysticktype.auto
95	 joystick.swap34.false
3	 joystick.swap34.true
6	 joystick.timed.false
92	 joystick.timed.true
1	 log.bios.true
1	 log.cpu.true
1	 log.dma_control.true
1	 log.dosmisc.true
1	 log.exec.true
1	 log.fcb.true
1	 log.files.true
1	 log.fpu.true
1	 log.gui.true
1	 log.int10.true
1	 log.io.true
1	 log.ioctl.true
1	 log.keyboard.true
1	 log.logfile.
1	 log.misc.true
1	 log.mouse.true
1	 log.paging.true
1	 log.pci.true
1	 log.pic.true
1	 log.pit.true
1	 log.sblaster.true
1	 log.vga.true
1	 log.vgagfx.true
1	 log.vgamisc.true
4	 midi.config.
4	 midi.device.default
94	 midi.midiconfig.
94	 midi.mididevice.default
98	 midi.mpu401.intelligent
1	 midi.mt32rate.auto
87	 mixer.blocksize.1024
10	 mixer.blocksize.2048
2	 mixer.blocksize.4096
98	 mixer.nosound.false
6	 mixer.prebuffer.20
3	 mixer.prebuffer.240
68	 mixer.prebuffer.25
1	 mixer.prebuffer.30
4	 mixer.prebuffer.40
1	 mixer.prebuffer.512
16	 mixer.prebuffer.80
5	 mixer.rate.22050
93	 mixer.rate.44100
1	 mixer.swapstereo.false
1	 ne2000.macaddr.AC:DE:48:88:99:AA
1	 ne2000.ne2000.true
1	 ne2000.nicbase.300
1	 ne2000.nicirq.3
1	 ne2000.realnic.list
1	 parallel.parallel1.disabled
1	 parallel.parallel2.disabled
1	 parallel.parallel3.disabled
1	 printer.docpath..
1	 printer.dpi.360
1	 printer.height.110
1	 printer.multipage.false
1	 printer.printer.true
1	 printer.printoutput.png
1	 printer.timeout.0
1	 printer.width.85
73	 render.aspect.false
26	 render.aspect.true
1	 render.char9.false
99	 render.frameskip.0
1	 render.linewise.false
1	 render.multiscan.false
1	 render.scaler.hardware2x
2	 render.scaler.none
96	 render.scaler.normal2x
1	 sblaster.dma.0
98	 sblaster.dma.1
1	 sblaster.hardwarebase.220
99	 sblaster.hdma.5
1	 sblaster.irq.10
33	 sblaster.irq.5
65	 sblaster.irq.7
4	 sblaster.mixer.true
4	 sblaster.oplemu.compat
89	 sblaster.oplemu.default
1	 sblaster.oplemu.old
96	 sblaster.oplmode.auto
2	 sblaster.oplmode.opl3
7	 sblaster.oplrate.22050
91	 sblaster.oplrate.44100
99	 sblaster.sbbase.220
94	 sblaster.sbmixer.true
93	 sblaster.sbtype.sb16
6	 sblaster.sbtype.sbpro1
98	 sdl.autolock.true
99	 sdl.fulldouble.false
5	 sdl.fullresolution.
74	 sdl.fullresolution.desktop
20	 sdl.fullresolution.original
99	 sdl.fullscreen.true
70	 sdl.mapperfile.mapper-0.74-2.map
16	 sdl.mapperfile.mapper-0.74.map
1	 sdl.mapperfile.mapper-SVN.map
2	 sdl.mapperfile.mapper.map
10	 sdl.mapperfile.mapper.txt
1	 sdl.output.OpenGL
5	 sdl.output.ddraw
1	 sdl.output.direct3d
5	 sdl.output.opengl
84	 sdl.output.overlay
3	 sdl.output.surface
1	 sdl.overscan.0
1	 sdl.pixelshader.none
98	 sdl.priority.higher,normal
95	 sdl.sensitivity.100
3	 sdl.sensitivity.500
98	 sdl.usescancodes.true
98	 sdl.waitonerror.true
99	 sdl.windowresolution.original
1	 serial.serial1.disabled
97	 serial.serial1.dummy
97	 serial.serial2.dummy
1	 serial.serial2.nullmodem port:23
98	 serial.serial3.disabled
98	 serial.serial4.disabled
1	 speaker.disney.false
97	 speaker.disney.true
9	 speaker.pcrate.22050
89	 speaker.pcrate.44100
98	 speaker.pcspeaker.true
98	 speaker.tandy.auto
9	 speaker.tandyrate.22050
89	 speaker.tandyrate.44100
1	 vsync.vsyncmode.off
1	 vsync.vsyncrate.75

I did this just to get a quick look at how many configs really change between all the GOG Games. As I suspected, we find a wide variety of cpu section settings. We had 2 that turned off EMS memory, and a few that changed the memsize. Quite a few twists in the joystick section, and a few other oddities here and there. So just by looking at this, I changed my program to take some additional overrides.

So, the little local snippet of code I wrote looks at my DOSBOX-X main config and each GOG’s DOSBOX config and compares the following, taking the GOG config and overriding just for that game.

While HOMM worked just fine without taking [cpu] settings, the next game I tried was Alone in the Dark, and with default DOSBox-X settings, it slowed to a crawl. Turns out GOG had tweaked their primary Alone in the Dark DOSBOX-0.74 config:

core -> simple
cputype -> pentium_slow
cycles -> 11000
cycleup -> 1000
cycledown -> 1000

This is why [cpu] is one of the sections I take from GOG’s curated game-specific configuration.

Game specific tweaks I had to make

Here’s the log of games I installed and any interesting tweaks I had to make to convert them to use my DOSBox-X install.

The post Retro Gaming PC Build Log Part 3 : PC Games with GOG appeared first on Krystof.IO.

The basic version of DOSBox does not contain support for ‘shaders’. Those little bits of code and configuration that can make a modern retro gaming screen look cell shaded, dotted like an old school CRT monitor, or even curved and blurred like an old TV tube. So how do I get shaders? We have to utilize a fork or variant of DOSBox. Let’s run a comparison of these shaders in a MSDOS Retro Gaming screenshot session of DOOM.

I have plans for three dioramas. One is complete – the C64 years. I still have an Atari 2600 and IBM PC diorama to do, and the latter is a bit more technically challenging when it comes to actually playing the games. Not only do I have to worry about DOS games, but Windows 3.1, Windows 95, and even some Windows 98 gaming, and attempting to make all of those games work on one small PC that will host the actual gameplay.

Why DosBox at all?

Between the old copies of games I have on CD and floppy images (I saved a lot of crap digitally if not physically), the actual CDs themselves, and sites like GOG.com, I’ll be able to relive a lot of my old gaming days. This is, of course, thanks in no small part to a little program called DOSBox.

From their site to explain it best: DOSBox is an emulator that recreates a MS-DOS compatible environment (complete with Sound, Input, Graphics and even basic networking). This environment is complete enough to run many classic MS-DOS games completely unmodified.

It’s the de facto standard for running DOS games on modern hardware.

I am 32 flavors and then some

To that end, there’s almost always a variant of DOSBox that gains popularity for a while because DOSBox ‘proper’ doesn’t support every single feature a DOS gamer might want to utilize when playing a game (e.g. Voodoo 3Dfx support). There are a decent number of variants that fall under the label of ‘SVN Builds’, you can check em all out here: https://www.dosbox.com/wiki/SVN_Builds.

One of the most popular variants today is called DOSBox ECE, standing for Enhanced Community Edition. It emulates 3Dfx hardware and supports up to 384 MB of ram, two things that the standard DOSBox build doesn’t cover.

Remember that you don’t have to use one version of DOSBox for every single game you play, although if you could, that would be ideal from a configuration management standpoint, as each variant may have different config file options available.

Now we have variants like DOSBox X, SVN Daum, ECE, and even CRT, which first caught my eye because, while I don’t always play with shaders (I dislike them on VICE), I wanted to see what the DOSBox world had to offer me. However, I wanted a relatively recent version of DOSBox with shaders. The hunt begins.

DOSBox CRT is close but no cigar

DOSBox CRT fit the bill at first – it’s essentially DOSBox 0.74 with a custom shader to give that real CRT look and feel. As much as I liked the inner screen rendering of it, this version essentially paints a CRT border around the screen that becomes part of your DOSBox window… I did not find this palatable:

Good job and a nod to Mattias Gustavsson for compiling his custom shader work into DOSBox. It just wasn’t for me. So our hunt continues. I didn’t want to use Retroarch for this, and I wanted something a little more recently maintained…

An Optionals requirement is found

I stumbled across another DOSBox variant called DOSBox Optionals, created by Marty Shepard with near latest enhancements of DOSBox ECE, standard DOSBox, and other patches people have released that aren’t incorporated into the ‘standard DOSBox’ build. Marty has done a fantastic job of grouping all of these enhancements into a single DOSBox build that also supported the shader patch by duganchen. VOGONS thread about that support here.

I downloaded and extracted DOSBox Optionals and opened up the dosbox.conf. Yikes! The sheer number of options and documentation to each option compared to the normal DOSBox install was amazing. I recommend trying it out – I’ve tried a handful of titles with it thus far and they’ve worked, though I did discover a speech pitch issue. I’ll cover that later in this post.

Throwing Shade…rs.

So without any ‘shaders’… What does DOSBox Optionals look like? Let’s compare shader to non shader. Given that I’m scaling my screen up, my no-shader view will have a slight blurring to it – but that’s not the shader.

Using DOSBox Optionals I took a ‘before and after’ screen shot of ‘no shader‘ and the ‘crt-lottes_mod‘ shader. You can drag the vertical slider below with your mouse and immediately see a difference.

Please note that the new defaults (scaler=none, aspect=on) are needed for the shaders to work as designed.

The results? Immediate shift to a more ‘dot-based’ look, a little darker and very much closer to a curved CRT. Compare yourself – the left side is without any shader and the right side is with ‘crt-lottes_mod’ selected. Drag the line to move your comparison from left to right.

Let’s zoom in and see what it looks like:

I’m impressed. You really get a sense of the dots and CRT nature of the view, and the phrase ‘dot pitch’, which I haven’t thought about in probably a decade, comes right back like it was yesterday. This isn’t just any simple scan-line filter.

Quick rundown of 13 shaders in DOSBox and DOOM

What about some of the other shaders? Let’s take a look – you can use the compare slider to look at the same screen shot of DOS and the same screen shot area of DOOM and compare shaders. I imagine one shader might be good for one game and one for another – or if you’re playing CGA, EGA, VGA, or ANSI text games, you very well might want a specific kind of shader for those resolutions and colors.

For me, I’ve really got my eye on crt-lottes_mod and crt-easymode. GTU looks like a contender as well. Some of these other shaders are just nuts – FixingPixelArt gives one hell of a blur for example, and the xbr (#4,#5) shaders give it a ‘behind stained-glass’ feel to me.

Modifying shaders for testing

As much as I like crt-lottes_mod, I have some tweaks I’d like to make:

• I don’t like curvature shaders. I know it’s trying to be more realistic, it’s just so damn off-putting to me, I’d like to disable it.
• It’s a little too dark – I’d like to increase the brightness a little bit.

I started to wonder – if I do this, does it end up looking like crt-easymode? Let’s tweak it a bit and find out.

I’m going to head over to the SHADERS/crt-lottes_mod.frag file and tweak a few values:

#define warpX 0.000 //0.021, 0.007
#define warpY 0.000 //0.045, 0.021 
#define brightboost 1.0

Let’s compare crt-easymode to my custom-mod-v1:

Granted, you could spend all day playing around with parameters, and while I feel the lottes_mod definitely has a lot more in the way of customization options, I’m leaning towards crt-easymode even with the modifications I made to flatten lottes and brighten the screen. This is just to get something going to see if I like it enough. It’s also a little lighter on the GPU than lottes will be from what I gather, which is good since I won’t be playing my DOSBox titles on a super high end modern machine.

DOSBox Optionals comes with free Chipmunks

Once I found a shader setting I wanted to try out for a bit, I needed to test a few titles on DOSBox Optionals to make sure it worked for my gaming tastes. Optionals comes packaged with a demo for DUNE2, one of the first Real Time Strategy games, and a Westwood classic.

I fired up the demo and as soon as the voice synthesis came on, I could tell something was just a bit… chipmunky. This was with default settings that come with the DOSBox Optionals install. Listen to this:

This did *not* happen running the same DUNE 2 demo on regular DOSBox, so I knew it was something specific to Optionals. But what? What patch is inserting Alvin into my games? I found this VOGONS thread referencing elevated pitch in DOSBox, calling out this code in particular:

I found a reference to Goldplay while searching the DOSBox Optionals repository:

Snippet pulled from https://github.com/MartyShepard/DOSBox-Optionals/blob/master/dosbox/tOptionals/src/hardware/sblaster.cpp at the time of this writing.

So, Goldplay. We’re now just a bit above my pay grade – it’s DMA transfers, sample rates, and IRQ programming. Nevertheless, I set goldplay = true in the dosbox.conf and voila:

I’ll have to keep that configuration option in mind in the future if something seems off in Speech. But between DUNE2, the demo and the game, along with Ultima Underworld, I needed to have this setting set to true for speech to sound proper.

Conclusion

Got some shader settings you like? I’d love to know if there’s a favorite preset or game/app you use a particular shader for. I’ll probably stick with crt-easymode for now, though I might look at the shader configuration and tweak a few things and see what happens. That’s what shader configs are all about – experimentation – because if a shader just isn’t doing anything for you, and it’s not reminding you of the monitor model you played that game on – tweak it!

References

• https://github.com/MartyShepard/DOSBox-Optionals – DOSBox Optionals Repo
• https://github.com/duganchen/dosbox_shaders – Duganchen’s shaders included in DOSBox Optionals
• https://mattiasgustavsson.itch.io/dosbox-crt – DOSBox CRT Build
• https://www.vogons.org/viewtopic.php?t=33896 – VOGONs thread regarding sample rate and DMA for SoundBlaster devices
• http://filthypants.blogspot.com/2015/04/more-crt-shaders.html – A good article referencing example shots of these shaders utlized in other emulators like RetroArch.
• https://emulation.gametechwiki.com/index.php/CRT_Shaders – General Shaders article – references a lot of shaders converted over to DOSBox (Duganchen’s build) and included in DOSBox Optionals.
• https://scalibq.wordpress.com/2017/03/12/dma-activation/ lots of technical information but references SoundBlaster GoldPlay

The post DOSBox Shaders Comparison For Modern DOS Retro Gaming appeared first on Krystof.IO.