After updating to DOSBox Pure 1.0 Preview 1, none of my games work

[SiriusVI87]

After updating to DOSBox Pure 1.0 Preview 1, none of my games work anymore. They worked perfectly with the previous version. My shader preset intro movie plays and then the screen stays black afterwards. I notice that I get a strange scanline / moire effect that I didn't get before either, so I'm guessing something is up with the graphics settings?

I'm launching my games via .conf file, such as this from 1st Person Pinball:

[sdl]
fullscreen=false
fulldouble=false
fullresolution=0x0
windowresolution=1280x960
output=openglnb
mapperfile=mapper.map
[dosbox]
machine=svga_s3
memsize=16
[render]
aspect=true
scaler=normal2x
[cpu]
core=auto
cputype=auto
cycles=800
[mixer]
[midi]
[sblaster]
[gus]
[speaker]
[joystick]
[serial]
[dos]
[ipx]
[autoexec]
mount c .\eXoDOS\1stPerso
c:
@cd 1stPerso
@cls
@GAMe
exit

[schellingb]

Can you toggle through the 5 settings under Core Options -> Video -> Aspect Ratio Correction and see if that affects anything while the screen has a weird pattern or is black? Then next can you try to run the same .conf file just without the line aspect=true and see if that changes things? Last, can you enable the RetroArch setting User Interface -> On-Screen Notifications -> Notification Visibility -> Display Statistics and take a screenshot of the statistics while the screen has a weird pattern or is black?

[SiriusVI87]

Can you toggle through the 5 settings under Core Options -> Video -> Aspect Ratio Correction and see if that affects anything while the screen has a weird pattern or is black? Then next can you try to run the same .conf file just without the line aspect=true and see if that changes things? Last, can you enable the RetroArch setting User Interface -> On-Screen Notifications -> Notification Visibility -> Display Statistics and take a screenshot of the statistics while the screen has a weird pattern or is black?

Hey, thx for writing back!

The first 2 suggestions did nothing unfortunately. This is the screenshot you asked for. Can you help me?

EDIT:

I deleted everything in the .conf except for this, bt it still does not work:

[autoexec]
mount c .\eXoDOS\1stPerso
c:
@cd 1stPerso
@cls
@GAMe
exit

[schellingb]

Certainly weird how it ends up with the resolution 0x0... Can you send a logfile? You might need to enable logging in RetroArch.

[SiriusVI87]

Certainly weird how it ends up with the resolution 0x0... Can you send a logfile? You might need to enable logging in RetroArch.

Sure, I will. In the meantime here is the screenshot with the working version:

[SiriusVI87]

Certainly weird how it ends up with the resolution 0x0... Can you send a logfile? You might need to enable logging in RetroArch.

This is my log file:

retroarch.log

[schellingb]

Ah, the issue is that the line mount line is likely incorrect. In the old version the core incorrectly mounted relative paths (like ./something) relative to a random directory, which can be the frontends directory but it can be something else depending on platform or previously launched cores. As mentioned in the release notes:

• Command-line mounting with relative paths were made relative to the loaded content (mount/imgmount) (59a20b1)

So your autoexec fails to mount anything, so all the following lines are failing with errors except then exit which gives you the black screen because DOS has been exited.

[SiriusVI87]

Ah, the issue is that the line mount line is likely incorrect. In the old version the core incorrectly mounted relative paths (like ./something) relative to a random directory, which can be the frontends directory but it can be something else depending on platform or previously launched cores. As mentioned in the release notes:

• Command-line mounting with relative paths were made relative to the loaded content (mount/imgmount) (59a20b1)

So your autoexec fails to mount anything, so all the following lines are failing with errors except then exit which gives you the black screen because DOS has been exited.

Hey, thx for clearing that up, although I don't believe I know how to fix this. For my setup I rely on the relative paths to work without changing the .conf files.

Currently my setup is as follows:
The actual files are on an external HDD, so e.g.:

O:\LaunchBox\eXo\eXoDOS\1stPerso\1st Person Pinball (1989).conf

The .conf file is in the same directory as the actual game files.

For this to work, with the previous version of DosBox Pure, I had to create a symlink to the eXoDOS directory from my retroarch directory, so:

M:\Launchbox\Emulators\RetroArch\eXoDOS --> (the eXoDOS folder is the symlink to the O:\ Drive)

So in the example below, where should I move the corresponding .conf file to, in order for the relative paths to work? Or, from where should I create the symlink to O:\LaunchBox\eXo\eXoDOS?

.\eXoDOS\1stPerso

[SiriusVI87]

Update:

I have kind of gotten it to work, but it requires a VERY extensive restructuring of my setup and I also don't like the results very much.

1. I have to create an extra folder in "M:\Launchbox\Emulators\RetroArch" --> "M:\Launchbox\Emulators\RetroArch\eXoConfigs".
2. Then I have to copy all the .conf files in this folder (which means win3x and ms dos will be mixed up together, making it hard to conveniently import them into Launchbox).
3. Then I have to create 2 symlinks to eXoDOS and eXoWin3x in the eXoConfigs folder, so "M:\Launchbox\Emulators\RetroArch\eXoConfigs\eXoDOS" and "M:\Launchbox\Emulators\RetroArch\eXoConfigs\eXoWin3x"

Is there a simpler solution? This is a bit frustrating for me, because I spent quite a lot of time gettig this setup to work (I'm also not very savvy when it comes to these things, so it took a lot of trial and error), and now that I have finally gotten it to work, I have to change it all, ending up with a worse setup =/.

I very much preferred how the older version handled the relative paths. That way I could just leave each .conf file in the same folder of the game files. The biggest downside is that the .conf files cannot be in their individual folders anymore. At the very least I would like to be able to separate the eXoDOS from eXoWin3x, so they can be imported into launchbox more easily.

But I also don't want to downgrade dosbox pure, because I want the new features and updates that come with newer releases.

May I ask what the benefit is of the new way relative paths are handled and if there is a chance of this change being reverted?

Thx!

[schellingb]

Can you explain how relative paths were handled before? It was random, so it might work on one device but not on another. Also if you run a certain core before DOSBox Pure, relative paths would not work anymore, etc. Now it always works, the paths in a .conf are relative to the .conf, how is that not much clearer?

[SiriusVI87]

Can you explain how relative paths were handled before? It was random, so it might work on one device but not on another. Also if you run a certain core before DOSBox Pure, relative paths would not work anymore, etc. Now it always works, the paths in a .conf are relative to the .conf, how is that not much clearer?

No I cannot really explain. I guess it worked for me, because I had the symlinks setup in M:\Launchbox\Emulators\RetroArch

That was actually the hardest part to figure out, but once I did, it never failed me, no matter if another core was opened before or whatnot. This setup was bullet proof.

The only thing that didn't work was the audio config, which you helped me with in my other issue thread (thx so much again!!!)

With the new way the dosbox pure core works, I have to do extensive reordering of the .conf files, as explained above. It might be more logical, but it unfortunately completely breaks my setup.

My last resort might be mass editing the .conf files and turing all the relative paths into absolute paths, but if I ever change my HDD volume letter / move the games to a new drive, I have to repeat the mass edit.

Long story short: With the new way the relative paths are handled, no solution is as elegant as it was with the previous version =/

EDIT:

Maybe this explanation here explains it better? That's where I got the initial idea to make this work:

https://www.rlauncher.com/forum/index.php?threads/100-bounty-exodos-sets-working-via-retroarch-module-dosbox-core.5076/

Here it says:

"Alright so if you look at any dosbox.conf in the exodos set for a game you will notice that the mount path is always relative so .\games\insertgamename. When you load dosbox in or out of retroarch, the root folder dosbox looks at by default, from my testing anyway, is whatever path dosbox is run from. Running from windows and running from cli will give you different results. Running from windows will set the root folder to where dosbox.exe lives, where running from cli will set the root folder to whatever folder you are currently in. So for example if you bring up a command prompt and go to cd c:\ and then run retroarch with the dosbox core using an absolute path to your retorarch.exe, then once dosbox comes up you do "mount c ." you will be mounting c:\ in dosbox. As for running retroarch through windows, if you ran "mount c ." it would mount the directory where retroarch.exe is. When RL runs retroarch you will get the same mounting results that you do running retroarch through windows.

So now that I have explained that, you can see that in order to run the exodos set as is we would have to place the Games directory from the exodos set in our retroarch directory. Now although you could do that, the better way is setting up a symbolic link to the games folder within your exodos set where it lives now, in my case on a network drive from my NAS. For those who dont know what a symbolic link is, its basically a shortcut to the folder but windows will treat it and its contents like it actually exists there. I use this nice little shell utility to setup symbolic links http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html."

[schellingb]

So, I can explain how it worked before, but it's a bit complicated :-)

First, some necessary info. A running process (like RetroArch) on an operating system like Windows or Linux has what is called a "working directory". If a program opens a file like "hello.txt" without specifying a full path, the file will be opened relative to the working directory of the process.

So in previous versions of the core, relative paths used for example in a mount or imgmount command was just that, it was opened as is and thus the files and directories were opened relative to the working directory of the RetroArch process. If you launch RetroArch on Windows by double clicking retroarch.exe or a default shortcut, Windows will use RetroArch's directory as the working directory. A shortcut can override the working directory though. If running from the command line, the current directory in the command line will be the working directory. How does it work on Android? I have no idea. How on PS Vita? Switch? OpenDingux? It's impossible to factor in every platform RetroArch runs on, so it needs to be avoided.

Now, a program can freely change its working directory. With libretro, that means both the frontend itself and any core can freely change the working directory. For example, DOSBox-SVN is a core that changes the working directory to the directory of the loaded content. So if you were to run DOSBox-SVN before the old version of DOSBox Pure, your setup would also be broken. It's hard to say which other cores also do this.

Anyway, relying on the working directory is not a good idea and as described above should be avoided. Because we don't know when it changes. If the core were to set it at startup, what if the frontend decides to change it later?

In the end, if D:\DOSGAMES\MyGame.conf in the [autoexec] section says MOUNT C MyGameDir, it makes the most sense to have that MyGameDir refer to D:\DOSGAMES\MyGameDir. That is the only intuitive answer.

Keep in mind that this core originally didn't even have support for .conf files. It was just added because the other DOSBox based cores also have it so people kept asking for it. The other cores also seem to use relative paths in a .conf be relative to the .conf file itself, so with the current behavior it matches them, which feels like a good consistency.

It sucks that this change breaks setups like yours, but I hope you can understand why this change was necessary. It's better to have a defined behavior that is consistent across all platforms. So when someone sets up their games to work on Windows, they can just copy a game over onto another device and be sure that it still works.

[SiriusVI87]

I see, thx for the explanation. The only part I don't get is this one:

"Keep in mind that this core originally didn't even have support for .conf files. It was just added because the other DOSBox based cores also have it so people kept asking for it. The other cores also seem to use relative paths in a .conf be relative to the .conf file itself, so with the current behavior it matches them, which feels like a good consistency."

This does not seem to be the case, because my (broken) setup still works with the regular DOS BOX core (I haven't tried DOSBox-SVN).

So if DOSXBox Pure's behavior now matches the one in the other DOSBOX cores, how come my setup still works with these cores, but not with pure?

[schellingb]

I just tried a new installation of RetroArch with these 3 cores freshly downloaded:

• DOSBox-core
• DOSBox-Pure
• DOSBox-SVN

I have a directory set up like this

• test\
• test\test.conf
• test\MYGAME\
• test\MYGAME\TEST.TXT

The content of test\test.conf is this:

[autoexec]
MOUNT C .\MYGAME
dir C:\
type C:\TEST.TXT

I freshly started RetroArch and ran that test.conf on each of the 3 cores and they all worked the same way. They ended up mounting test\MYGAME\ as the C: drive and successfully wrote the content of TEST.TXT on the screen. I then reverted back DOSBox Pure to the previous version 0.9.9 and it didn't work.

[SiriusVI87]

Curious, maybe the other cores were updated recently, too? I don't know. All I know is that last I tried my setup with the "incorrect" relative paths still worked with the regular dosbox core.

Anyway I will try some stuff, I have an idea on how to set up my, ehm ... setup so that it's not more complicated than before. I will report back once I get everything working and then we can close this issue.

Thx for your support! You have been a great help!

[SiriusVI87]

Hey, so I just changed my setup to something I thought worked, but apparently it only works with some games and I don't know why =(.

So with your explanation above, I found that I don't even need to have the .conf files in my Retroarch Directory, I can have them wherever if I create symlinks in such a way that the relative paths within the .conf files work.

So my new Setup is:

The game files are here in O:\LaunchBox\eXo\eXoWin3x

The conf files are in O:\LaunchBox\Games\eXoConfigs!win3x (that way I can have the conf files on the same drive as the game files all in one folder). In this folder I created a symlink to O:\LaunchBox\eXo\eXoWin3x and O:\LaunchBox\eXo\mt32 for the sound files.

now this conf works:
[autoexec]
mount c .\eXoWin3x\AAiW
imgmount d ".\eXoWin3x\AAiW\cd\ALICE.cue" -t cdrom
d:
path=C:;z:;c:\windows\
@cls
@win runexit alice
exit

This does not work:
[autoexec]
mount c .\eXoWin3x\3DUPCN
imgmount d .\eXoWin3x\3DUPCN\cd\cd.cue -t iso
c:
path=C:;z:;c:\windows;c:\sierra\upball2
@cd sierra\upball2
@cls
@win runexit pinball2.exe
exit

Can you tell me why?

[schellingb]

What does not work? Try to remove the line "exit" so you can see what happens in the console, which of the commands fail etc.

[SiriusVI87]

What does not work? Try to remove the line "exit" so you can see what happens in the console, which of the commands fail etc.

Same as before, black screen.

without the exit I get this:

It works with the regular DosBox core:

[schellingb]

Also remove the cls, we're trying to see the error message

[SiriusVI87]

Also remove the cls, we're trying to see the error message

This is what I got:

[schellingb]

Now try reading the error message, doesn't this help you?

[SiriusVI87]

Now try reading the error message, doesn't this help you?

No, I'm sorry. I don't get why it's not working for one game but it does for the other. And I don't get why it works with the regular dosbox core (seen my edited message above?)

I really don't get it. I told you was not super savvy. I just trial and error my way through here. =(

[SiriusVI87]

So I just tried my last resort option and made the path absolute:

[autoexec]
mount c O:\LaunchBox\eXo\eXoWin3x\3DUPCN
imgmount d O:\LaunchBox\eXo\eXoWin3x\3DUPCN\cd\cd.cue -t iso
c:
path=C:;z:;c:\windows;c:\sierra\upball2
@cd sierra\upball2

@win runexit pinball2.exe

But I still get the same weird error that somehow the path does not exist?

But it's right there:

[schellingb]

So the absolute path doesn't even use the symbolic link anymore, right?

It certainly is weird that mount fails saying the directory doesn't exist but then imgmount succeeds mounting something that is INSIDE that directory. I will try to reproduce your setup with some dummy files using the exact same names on O: drive to see if I can get it happening.

[SiriusVI87]

So the absolute path doesn't even use the symbolic link anymore, right?

It certainly is weird that mount fails saying the directory doesn't exist but then imgmount succeeds mounting something that is INSIDE that directory. I will try to reproduce your setup with some dummy files using the exact same names on O: drive to see if I can get it happening.

OMG, I got it:

This does not work:

[autoexec]
mount c .\eXoWin3x\3DUPCN\

This does:

[autoexec]
mount c .\eXoWin3x\3DUPCN

However, to fix this, I would have to edit thousands of files manually, removing the last "". I cannot think of any way to automate this.

Was this a desired change with the latest update or is this a bug? I SWEAR this worked in the last dosbox pure version and it also works with the regular dosbox core.

[schellingb]

Haha, I just realized that, too, it does not like a trailing \ in the mount path. GitHub is certainly not helping with it hiding the \ from your messages. I'd classify that as a bug, a path with a trailing \ should still be a valid directory path. I'll fix this.

Because I copied your messages which have the \ hidden in the mount command and it worked for me...

Edit: In future messages, try to encapsulate your file contents into code blocks with three uptick characters ``` in a line above and below the content. It will look like

this. Happy backslash \

[SiriusVI87]

Haha, I just realized that, too, it does not like a trailing \ in the mount path. GitHub is certainly not helping with it hiding the \ from your messages. I'd classify that as a bug, a path with a trailing \ should still be a valid directory path. I'll fix this.

Because I copied your messages which have the \ hidden in the mount command and it worked for me...

You can't imagine how happy I am that it's an actual bug and that it's an easy fix for you. THANK YOU for sticking with me. With this bug fixed I believe I can get a working setup that is probably even superior to my previous one. =)

Uff, I think I need a beer now.

[schellingb]

Thanks for sticking around and helping find this bug. I'll push this probably as an update to this version in a day or two if nothing else comes up. Here's a build of the core with the fix for 64-Bit Windows, if you can give it a go and check if the fix works, that would be great. dosbox_pure_libretro_win64_dll_git_8e608c2.zip

[SiriusVI87]

Thanks for sticking around and helping find this bug. I'll push this probably as an update to this version in a day or two if nothing else comes up. Here's a build of the core with the fix for 64-Bit Windows, if you can give it a go and check if the fix works, that would be great. dosbox_pure_libretro_win64_dll_git_8e608c2.zip

Thx so much for giving me a preview version to try out. I just restructured my setup and it finally works in a way I am very happy with. =)

Thanks again for all your hard work and for guiding a noob through this process.