steam-dos - does it count as DOSBox frontend?

General information and assistance with DOSBox.

steam-dos - does it count as DOSBox frontend?

Postby dreamer_ » 2019-5-17 @ 21:14

Yes? No? I don't know... :blush:

https://github.com/dreamer/steam-dos

I created this small tool to make it possible to force native Linux version of DOSBox for DOS games distributed through Steam. It is independent of Proton/SteamPlay, but uses the same mechanism to hook into the Steam client. Without this tool, Proton starts DOSBox using Wine, introducing additional input lag and some bugs.

Comes with several QoL and other features:

  • Defaults to OpenGL - too many games are pre-configured to render to surface.
  • Automatically starts/stops software MIDI synthesiser in the background (TiMidity++ or FluidSynth)
  • Autoconfigures midi section to connect to proper ALSA sequencer
  • Provides whitelist to fix games, when publisher totally f@#$%^ up when putting game on Steam.
  • Translates case-insensitive paths in .conf files to case-sensitive variants (this fixes most of Windows-only .conf files out there - why DOSBox does not do it by default?!)
  • Reinterprets DOSBox arguments to make it Linux-compatible (again - mostly paths)

And after an advertisement, I have a few questions:

  • Where is bugtracker for DOSBox project? Is this forum a de-facto bugtracker?
  • Do you need help with moving DOSBox to Git? I would gladly help with DOSBox development, send some patches - but Subversion makes it really inconvenient.

I have more questions, but maybe they should go into proper sub-forums after all…
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 4
Joined: 2019-5-17 @ 20:19

Re: steam-dos - does it count as DOSBox frontend?

Postby Qbix » 2019-5-18 @ 07:38

[*] Autoconfigures midi section to connect to proper ALSA sequencer

DOSBox had that at one point, but timidity used a full cpu core when connecting to it, even when not using it. Maybe they fixed it or ubuntu/debian changed their configuration. So that is why dosbox doesn't probe the timidity port.
Translates case-insensitive paths in .conf files to case-sensitive variants (this fixes most of Windows-only .conf files out there - why DOSBox does not do it by default?!)

Not 100% our problem to try and fix and it's not 100% reliable. (there can be more than one case-sensitive name for each case-insensitive name). I thought DOS paths were allowed in critical locations. Maybe I never committed that or it has bugged out ? I agree that it might be nice to do for the user, but only if it is 100% reliable.


[*] Where is bugtracker for DOSBox project? Is this forum a de-facto bugtracker?

sf.net
[*] Do you need help with moving DOSBox to Git? I would gladly help with DOSBox development, send some patches - but Subversion makes it really inconvenient.

No, as there are no plans to move to Git at this point.
Water flows down the stream
How to ask questions the smart way!
User avatar
Qbix
DOSBox Author
 
Posts: 10838
Joined: 2002-11-27 @ 14:50
Location: Fryslan

Re: steam-dos - does it count as DOSBox frontend?

Postby dreamer_ » 2019-5-18 @ 14:23

Qbix wrote:DOSBox had that at one point, but timidity used a full cpu core when connecting to it, even when not using it. Maybe they fixed it or ubuntu/debian changed their configuration. So that is why dosbox doesn't probe the timidity port.

Ah, that makes sense :) When testing on my old laptop running Fedora 29, timidity (2.14) uses <1% when idling, ~7% when connected, ~14% when actually playing + some pulseaudio tax.

Qbix wrote:Not 100% our problem to try and fix and it's not 100% reliable. (there can be more than one case-sensitive name for each case-insensitive name).

Of course, but it's rather unlikely when running a DOS game. Basically, user would need to manually create a conflicting file in a directory that was originally created on DOS or Windows. For my tool it's not a problem, because files in Steam depot are prepped for Windows deployment. For this reason, I am simply picking the first file that matches the name - in all *practical* cases it will work ok (I will probably add some warning in future, though).

Qbix wrote:I thought DOS paths were allowed in critical locations. Maybe I never committed that or it has bugged out?

I am seeing this specifically with paths passed to "mount" and "imgmount". I also see, that some publishers try to use "imgmount" to mount directories on Windows (which is not supposed to work, I think?).

Qbix wrote:I agree that it might be nice to do for the user, but only if it is 100% reliable.

I think most users would be fine at least with DOSBox failing loudly when a path is not found (0.74-2 fails silently). It would be nice to print errors of mount/imgmount to stderr and not only to DOS console.

No, as there are no plans to move to Git at this point.

I got you. Would you accept some git-specific patches though? I am specifically talking about mirroring svn:ignore props to .gitignore files to allow using git-svn as svn client.

I have experience with migrating large codebases from legacy version control system to Git and converting DOSBox repo seems (was) rather painless. You maintained nice, clean history, used svn-merge correctly, did not commit any large binary artifacts throughout the years, did not commit to tags and avoided other svn traps - really nice job :) (basically I found nothing serious that would need to be corrected during migration). I think I might create a Git mirror of official repo, but I'll continue this topic in proper thread.
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 4
Joined: 2019-5-17 @ 20:19

Re: steam-dos - does it count as DOSBox frontend?

Postby Azarien » 2019-5-24 @ 23:35

dreamer_ wrote:Subversion makes it really inconvenient.


You can always use git-svn.
Azarien
Oldbie
 
Posts: 601
Joined: 2015-5-14 @ 07:14

Re: steam-dos - does it count as DOSBox frontend?

Postby dreamer_ » 2019-5-26 @ 11:18

Yeah, I could use git-svn - that's why I asked QBix if he would accept some git-specific patches (svn:ignore props need to be mirrored into .gitignore files).

In fact, I would never use svn client directly - git-svn is so much better.

But it doesn't solve the problem really - right now DOSBox is in quite stupid situation where usage of SVN promotes forking of the project (instead of contributing back). Some forks use Git, other put tarballs with dosbox releases into git and copies of patch files (ridiculous, but easier than maintaining git-svn fork), others do not use any version control at all (Dosbox ECE). Moving to Git would be beneficial to the community as a whole.
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 4
Joined: 2019-5-17 @ 20:19

Re: steam-dos - does it count as DOSBox frontend?

Postby Qbix » 2019-6-05 @ 13:23

dreamer_ wrote:
Qbix wrote:DOSBox had that at one point, but timidity used a full cpu core when connecting to it, even when not using it. Maybe they fixed it or ubuntu/debian changed their configuration. So that is why dosbox doesn't probe the timidity port.

Ah, that makes sense :) When testing on my old laptop running Fedora 29, timidity (2.14) uses <1% when idling, ~7% when connected, ~14% when actually playing + some pulseaudio tax.

6% extra, when doing nothing, is not great. I read that is a lot more when you run timidity as root (as it is on my linux system). There seem to be some fixes around to fix timidity in that respect.

Of course, but it's rather unlikely when running a DOS game. Basically, user would need to manually create a conflicting file in a directory that was originally created on DOS or Windows. For my tool it's not a problem, because files in Steam depot are prepped for Windows deployment. For this reason, I am simply picking the first file that matches the name - in all *practical* cases it will work ok (I will probably add some warning in future, though).

True, it will work in a lot of cases, except it ideally should work in all cases when you are dealing with mount commands, as the user has to be able to trust that. It should not break when some directory is added which changes which directory is being picked. The problem doesn't really exist if the publisher picked the right names from the start... Nonetheless, it is a nice feature to have, although I really would prefer publishers picking the right names.

If I were to add it to the mainline it would be through some sort of mount option or dosbox option to do "fuzzy" matching. For me it makes no sense to do that as default behaviour. (not stating that I will add it or that I won't add it)

I am seeing this specifically with paths passed to "mount" and "imgmount". I also see, that some publishers try to use "imgmount" to mount directories on Windows (which is not supposed to work, I think?).

No that is not supposed to work. Got an example game where this happens ?

I think most users would be fine at least with DOSBox failing loudly when a path is not found (0.74-2 fails silently). It would be nice to print errors of mount/imgmount to stderr and not only to DOS console.

From a packaging perspective, you are right, but normally an user would always see the DOS console, as that is where the user enters the commands...
I could add an informative message to stdout though, similarly we do for shell redirection in order to help the user out.


I got you. Would you accept some git-specific patches though? I am specifically talking about mirroring svn:ignore props to .gitignore files to allow using git-svn as svn client.

Wouldn't it be better to submit a patch/feature request to git-svn to handle the svn:ignore props ?
This way a lot more people would benefit.
I don't have a good reason to reason to accept git-specific patches, nor bazaar specific patches nor mercury specific patches. (how many version control systems are out there)
I have tried git a few times and it's not very compatible with my workflow. I am working with some people to see if I can find a working solution, but it's not a high priority.

I have experience with migrating large codebases from legacy version control system to Git and converting DOSBox repo seems (was) rather painless. You maintained nice, clean history, used svn-merge correctly, did not commit any large binary artifacts throughout the years, did not commit to tags and avoided other svn traps - really nice job :) (basically I found nothing serious that would need to be corrected during migration). I think I might create a Git mirror of official repo, but I'll continue this topic in proper thread.

There are several people who have already a git mirror of the official repo. You might want to consider cloning one of those.
Water flows down the stream
How to ask questions the smart way!
User avatar
Qbix
DOSBox Author
 
Posts: 10838
Joined: 2002-11-27 @ 14:50
Location: Fryslan

Re: steam-dos - does it count as DOSBox frontend?

Postby dreamer_ » 2019-6-10 @ 12:07

First of all, thank you for fixing background buffer colour issue in r4229 - I am tracking this in https://github.com/dreamer/steam-dos/issues/8 waiting for next release of DOSBox :)

No that is not supposed to work. Got an example game where this happens ?

Yes, MegaRace 2 (This game is also on GOG, but without Linux support - which is weird for a DOSBox game).

Linux version uses:
Code: Select all
mount d . -t cdrom

(but it does not work on Steam because of other bugs in packaging of this game)

Windows version uses:
Code: Select all
imgmount d "." -t iso

(and it works, at least when running through SteamPlay/Proton 4.2-6)

In my tool, I am converting mount command for this particular title from imgmount back to mount - and it works beautifully.

From a packaging perspective, you are right, but normally a user would always see the DOS console, as that is where the user enters the commands...

Not so much for games started through some kind of launcher (Steam, Lutris, GameHub, Gnome Games, etc) - in those cases mount commands come from autoexec section of some conf file, written by someone else. Let me describe one specific scenario, where lack of warnings bit me:

  • User A owns a DOS game (let's say, Doom) and packages it for Lutris using paths found in his copy (which might come e.g. from his backup floppy image or Internet Archive or who knows). Lutris installer is going to invoke "dosbox BASE/DOOM.EXE". It works for user A.
  • User B installs a game using his own copy of Doom - in his copy path is "base/DOOM.EXE", Lutris picks up .conf file submitted by User A.
  • Invoking "dosbox BASE/DOOM.EXE" results in new DOSBox prompt (just Z:>), no error, no warnings on stdout/stderr, no warnings in DOS prompt (not even failed "mount C BASE")

This seems like a good first bug for someone to tackle on ;) In my tool I verify all relevant paths and either leave a warning on stderr or inject error message to dosbox with "-c @echo Message". I might work on fixing it, but I am working on fixing fullscreen behaviour right now, speaking of which…

On Linux, the behaviour of `sdl.fullresolution=desktop` is broken on multi-monitor setups. By default, it results in DOSBox window stretched over the whole working area - which is unusable e.g. with even number of displays or when they use different resolutions. There is easy workaround though, SDL >= 1.2.14 accepts SDL_VIDEO_FULLSCREEN_DISPLAY environment variable. Using `sdl.fullresolution=<real resolution of first display>` and `SDL_VIDEO_FULLSCREEN_DISPLAY=0 dosbox` makes dosbox behave as `fullresolution=desktop` should behave by default (in my opinion). Maybe someone depends on value `desktop` though, so new value for fullresolution might be a good idea? `sdl.fullresolution=display 0`? I don't know how fullscreen behaves in DOSBox on other OSes though.

I have halfway-finished implementation of borderless window for dosbox, and I could adapt it easily to fix this issue instead. What is your preferred way of reviewing patches? This forum? Some mailing list? Is there contribution guide somewhere (I looked, but couldn't find any doc)?

Wouldn't it be better to submit a patch/feature request to git-svn to handle the svn:ignore props ?

Not really... Git and SVN differ in this regard. Git stores all source-code related metadata with the content, instead of props/parallel metadata storage - this way all the same algorithms can be used for automatic merge/rebase of metadata as code - preventing various failures.

There are several people who have already a git mirror of the official repo. You might want to consider cloning one of those.

Some of those people even contacted me through PMs, but I can't respond because I have messaging functionality blocked (I am not active enough on this forum, I guess).
Can I have possibility of sending PMs unlocked? Thank you in advance :)
Code: Select all
| ← Ceci n'est pas une pipe
User avatar
dreamer_
Newbie
 
Posts: 4
Joined: 2019-5-17 @ 20:19


Return to DOSBox General

Who is online

Users browsing this forum: No registered users and 2 guests