DOSBox Feature Request Thread

General information and assistance with DOSBox.

Re: DOSBox Feature Request Thread

Postby Ant_222 » 2019-2-22 @ 13:18

junglemontana wrote:Not sure if anyone else is interested, but bicubic and/or Sinc/Lanczos based scaling would be interesting too.
Is the blurring that you get with the overlay, ddraw, and opengl outputs not enough for you? What is the reason for blurring sharp images?
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

Re: DOSBox Feature Request Thread

Postby junglemontana » 2019-2-23 @ 15:42

Ant_222 wrote:
junglemontana wrote:Not sure if anyone else is interested, but bicubic and/or Sinc/Lanczos based scaling would be interesting too.
Is the blurring that you get with the overlay, ddraw, and opengl outputs not enough for you? What is the reason for blurring sharp images?


Aren't those based on bilinear interpolation? Bicubic or Sinc should provide somewhat better results.

I undestand that many people like the blocky appearance of nearest-neighbor upscaling but I often prefer something smoother. :P The scalers used by Dosbox (e.g. hq, supersai) are very nice but it seems that they only support certain resolutions.
junglemontana
Newbie
 
Posts: 39
Joined: 2019-2-16 @ 17:37

Re: DOSBox Feature Request Thread

Postby Ant_222 » 2019-2-23 @ 19:36

junglemontana wrote:Aren't those based on bilinear interpolation? Bicubic or Sinc should provide somewhat better results.
Yes, and bicubic is indeed vastly better for photographic interpolation, whereas for pixel art I consider both methods equally useless. Bicubic interpolation is much slower and it may be difficult to implement with sufficient efficiency.
junglemontana wrote:I undestand that many people like the blocky appearance of nearest-neighbor upscaling but I often prefer something smoother. :P
Anything except pixel-perfect integer scaling distorts the original image, the sort of the distortion depending on the interpolation technique used. The distortion of nearest-neighbor interpolation is irregular pixel sizes. But large, sharp pixels, are part of MS-DOS aesthetics. Remember also that monitors used to be smaller, so you may want to sit further back from your large display to make the image appear smaller.
junglemontana wrote:The scalers used by Dosbox (e.g. hq, supersai) are very nice but it seems that they only support certain resolutions.
When don't they work for you?
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

Re: DOSBox Feature Request Thread

Postby junglemontana » 2019-2-23 @ 20:55

Ant_222 wrote:
junglemontana wrote:Aren't those based on bilinear interpolation? Bicubic or Sinc should provide somewhat better results.
Yes, and bicubic is indeed vastly better for photographic interpolation, whereas for pixel art I consider both methods equally useless. Bicubic interpolation is much slower and it may be difficult to implement with sufficient efficiency.


Performance may become a problem, though I'm not familiar with that. Some video renderers support real-time bicubic and Lanczos upscaling but I'm not sure if they are hardware accelerated or pure software implementations.

junglemontana wrote:The scalers used by Dosbox (e.g. hq, supersai) are very nice but it seems that they only support certain resolutions.
When don't they work for you?


For example, when hq2x is used (even with the forced option), selecting video mode 800x600x16 in the original GTA causes Dosbox to print a message "Scaler can't handle this resolution, going back to normal" and the game is not scaled.

I posted a question about this here:
viewtopic.php?f=31&t=65372
junglemontana
Newbie
 
Posts: 39
Joined: 2019-2-16 @ 17:37

Re: DOSBox Feature Request Thread

Postby Ant_222 » 2019-2-23 @ 21:24

junglemontana wrote:For example, when hq2x is used (even with the forced option), selecting video mode 800x600x16 in the original GTA causes Dosbox to print a message "Scaler can't handle this resolution, going back to normal" and the game is not scaled.
Looks like an arbitrary constraint to me. The relevant constants can be redefined in
Code: Select all
src/gui/render_scalers.h
.
junglemontana wrote:I posted a question about this here:
viewtopic.php?f=31&t=65372
Sadly, no replies.
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

Re: DOSBox Feature Request Thread

Postby Gatekeeper » 2019-3-04 @ 13:42

Suggestion: DOSBox should have the option to preserve files' original date/time modified.

This isn't usually a problem, however I've had numerous cases of patches or even game expansion installers failing due to incorrect date/time modified. Example: Duke Nukem Plutonium PAK - it won't install under DOSBox (says the original game files are missing or corrupted), but works just fine in PCem, running DOS 5.00a.

The really NASTY example, though, is Star Wars: X-Wing & TIE Fighter games. Their expansions also fail to install correctly due to mismatched date/time modified. But the installer doesn't tell you that. Oh no, it makes it look like everything installed correctly... and then the game is messed-up and has severe graphical glitches or just crashes randomly. It took me nearly 10 (ten) years to figure this out, and I only realized what was going on after comparing the MD5 checksums of the files. Old fiels were simply not replaced with the new ones, even though the installer allegedly did that (and never gave me any error messages).

An experiment with files, whose original date/time modified was restored to original with a third-party program, showed that these same expansions install successfully under DOSBox... proving that it was the date/time modified that caused this whole confusion. Other things (mostly patches) that fail to install in DOSBox also work correctly in PCem (or an old laptop that I borrowed for experimental purposes).

Yes, I can always use PCem to install stuff and it is fairly convenient to use... but I hope we can all agree that being able to do everything within DOSBox, without resorting to third-party programs, would be better. I've been using DOSBox for over 12 years now and it's one of the best applications I've ever discovered :happy:
Don't waste your time, or time will waste you...
User avatar
Gatekeeper
Newbie
 
Posts: 23
Joined: 2006-4-14 @ 22:50
Location: Sofia, Bulgaria

Re: DOSBox Feature Request Thread

Postby DosFreak » 2019-3-04 @ 15:48

DOSBox can already do this if you use a HD image.

Without an image DOSBox would have to do that across all host filesystems unless it's determine to only do that for specific ones which would be annoying.

Would likely be better to print a message to console when that functionality is used or when specific hashes are detected.

Another concern although slight is security since a modified file would reflect an earlier date but obviously dates on files are easy to change anyway.
User avatar
DosFreak
l33t++
 
Posts: 10444
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Feature Request Thread

Postby Gatekeeper » 2019-3-05 @ 09:35

HD image - I'll look into it. Thanks!
Don't waste your time, or time will waste you...
User avatar
Gatekeeper
Newbie
 
Posts: 23
Joined: 2006-4-14 @ 22:50
Location: Sofia, Bulgaria

Re: DOSBox Feature Request Thread

Postby junglemontana » 2019-3-09 @ 18:23

Ant_222 wrote:
junglemontana wrote:For example, when hq2x is used (even with the forced option), selecting video mode 800x600x16 in the original GTA causes Dosbox to print a message "Scaler can't handle this resolution, going back to normal" and the game is not scaled.
Looks like an arbitrary constraint to me. The relevant constants can be redefined in
Code: Select all
src/gui/render_scalers.h
.
junglemontana wrote:I posted a question about this here:
viewtopic.php?f=31&t=65372
Sadly, no replies.


Hm, thanks for the tip. I edited that file and changed the SCALER_MAXWIDTH/MAXHEIGHT and SCALER_COMPLEXWIDTH/COMPLEXHEIGHT macros to 1280/1024 instead of the default 800/600, then compiled Dosbox, and now the scalers work as I wanted. Performance of the hq scaler is just a bit slow, as one might expect. I'll try others as well.

Were those limits originally set for performance reasons? I think a warning would be enough when someone uses heavy scalers for high resolutions...


Just for general curiosity, would these scalers benefit from multithreading? Or even some sort of OpenCL/CUDA acceleration?
junglemontana
Newbie
 
Posts: 39
Joined: 2019-2-16 @ 17:37

Re: DOSBox Feature Request Thread

Postby Gernot66 » 2019-6-06 @ 00:02

Blast me if it was already asked, but it took me two hours only to read the opener to this thread.

One thing i strongly miss, proper help if i type e.g. "COPY /?" i only get informed "Copy" as explanation "copy files" command "copy" (aha! i thought it's to cook eggs).
To use the real DOS command help to the commands is neither useful since DOSBox is quite restricted. I would really appreciate if i.e. a "copy /?" would return the possible commandline options for the command as it usually does.

Example; i would have liked to copy a file in DOSbox but keep the flags of the original file like "XCOPY" does (perhaps i will use an old DOS proggie for this)
I explain it a little further; the task is to copy around a miles sound driver and well i would like if i see on the date if it's the original or the altered file which is present in the game but if it's copied over with a new date i can't see easy which it is and have to open it if i can preserve the date i would know immediately which it is, things can go wrong sometimes.

However, this is for sure not only a problem for "COPY" it's a problem for all DOS commands.
Guess of a newbe (which i can't claim of myself to be) he will stand in the pouring rain with such a help "copy is used to copy files".
Guess of a simple DIR a lot can be done with it, i.e. generate a playlist but what are the switches and which work for what?

Imho it would be already a big help only to output the possible switches without any explanation, for this you can refere to the web.

If i have to refere to a text/wiki or browse the source ok that's also fine for me - for me.
(recently i didn't found much help to this and believe me i took my time, you are so serious about this that i get week in the knees from and do my best to find an answer before i ask).
I also read help texts with an old reader, i like that much, i display charts and maps also with DOSBox and an old picture viewer.

Commander Jameson
User avatar
Gernot66
Newbie
 
Posts: 41
Joined: 2019-4-21 @ 18:13
Location: Scirocco Station, Ross154

Re: DOSBox Feature Request Thread

Postby awgamer » 2019-6-06 @ 01:26

>i only get informed "Copy" as explanation "copy files"

That's an easy fix.

src/shell/shell.cpp
void shell_init() {
..
MSG_Add("SHELL_CMD_COPY_HELP","Cooks eggs.\n");

There ya go :happy:
awgamer
Oldbie
 
Posts: 568
Joined: 2014-7-26 @ 07:42

Re: DOSBox Feature Request Thread

Postby jmarsh » 2019-6-06 @ 03:09

If you want dates preserved you will have to mount disk images instead of directories, knowing the command details won't be enough.
jmarsh
Member
 
Posts: 282
Joined: 2014-1-04 @ 09:17

Re: DOSBox Feature Request Thread

Postby krcroft » 2019-6-06 @ 04:01

One thing i strongly miss, proper help if i type e.g. "COPY /?" i only get informed "Copy" as explanation "copy files" command "copy" (aha! i thought it's to cook eggs).
To use the real DOS command help to the commands is neither useful since DOSBox is quite restricted. I would really appreciate if i.e. a "copy /?" would return the possible commandline options for the command as it usually does.


DOSBox's emulation of the standard fare of DOS commands is very limited, which is why the output from /? from them is so sparse.
It would be possible to add more verbosity to /? atleast explaining the actual positional arguments that DOSBox /does/ support.

For example, the output from copy /? currently shows:

Code: Select all
C:\> copy /?
Copy files.

COPY

C:\>


Which admittedly is a bit sparse, especially for users new to DOS. It could probably be expanded to something like this:

Code: Select all
C:\> copy /?
Copy files.

COPY SOURCE DESTINATION

Description of arguments:
   - SOURCE is an existing file
   - DESTINATION can be a file or directory.
     - If DESTINATION is an existing file, its content will be overwritten with that from the SOURCE
     - If DESTINATION is an non-existing file, it will be created and it's content copied from source SOURCE
     - If DESTINATION is a directory, the SOURCE file is copied into the directory having the the same name as the SOURCE
 
Limitations:
   - SOURCE and DESTINATION cannot be the same.
   - DOSBox's COPY does not support .... as provided by MSDOS 5.0+ (or something like that)
   - If you need need all features provided by MSDOS's COPY, please see <path to some Wiki page>

C:\>


I could see this being helpful to those like yourself (who are old DOS users, but new to DOSBox), and especially those who are outright new to DOS or command line interfaces general. As time wears on, I suspect the percent of new-to-DOS users will grow, so it's probably useful to add this.

Wearing my general developer hat, I suspect if the DOSBox core developer(s) put out a request there would be many hands go up offering help. Then again it's really only the text that's valuable (to save busy-work of fixing contributors code/variable names/etc) we could probably start a thread for this and non-dev Vogoner's could contribute and improve the help messages, and the DOSBox dev's simply drop in the final revisions.

A much taller and unlikely request is expecting DOSBox's commands to actually match MSDOS's functionality. In your case, I would suggest using your host OS to bulk manipulate your DOS files/directories before jumping into DOSBox. Microsoft's absorption of GNU and Ubuntu means you can easily use BASH in Windows without having to install msys or cygwin.
User avatar
krcroft
Member
 
Posts: 328
Joined: 2017-4-29 @ 15:07
Location: Ogden's Retreat

Re: DOSBox Feature Request Thread

Postby jmarsh » 2019-6-06 @ 07:26

If you want real DOS commands, just run real DOS in DOSBox.
jmarsh
Member
 
Posts: 282
Joined: 2014-1-04 @ 09:17

Re: DOSBox Feature Request Thread

Postby Dominus » 2019-6-06 @ 07:32

Yes, keep the goal of DOSBox in mind when requesting features: to run old games.
The copy command exists in DOSBox to allow game installers to work. It's not there for end users. If you want file operations use your host, that's much safer and trustworthy than a DOS emulator. You really don't need the copy command to play games.
If you want to work outside of DOSBox' scope, install Freedos and use its tools.

So reading a bit of this thread would have helped to learn whether a request is actually feasible/in DOSBox' scope ;)
User avatar
Dominus
DOSBox Moderator
 
Posts: 7975
Joined: 2002-10-03 @ 09:54
Location: Ludwigsburg

Re: DOSBox Feature Request Thread

Postby awgamer » 2019-6-07 @ 00:41

jmarsh wrote:If you want real DOS commands, just run real DOS in DOSBox.


You can also run most real DOS commands in DOSBox's DOS, they're DOS programs like any other.
awgamer
Oldbie
 
Posts: 568
Joined: 2014-7-26 @ 07:42

Re: DOSBox Feature Request Thread

Postby jmarsh » 2019-6-07 @ 01:37

Those aren't DOS commands, they're programs.
Commands are executed by the command interpreter (e.g. command.com).
jmarsh
Member
 
Posts: 282
Joined: 2014-1-04 @ 09:17

Re: DOSBox Feature Request Thread

Postby Ant_222 » 2019-7-28 @ 14:40

junglemontana wrote:Just for general curiosity, would these scalers benefit from multithreading? Or even some sort of OpenCL/CUDA acceleration?
Yes, by a factor of the number of cores, which is why the implementation of XBRZ was parallel. The modern solution, however, would be to implement those scalers as pixel shaders.
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

Re: DOSBox Feature Request Thread

Postby Kisai » 2019-9-22 @ 00:20

There is a feature in dosbox-x that should be backported to dosbox. OpenDML (AVI 2.0) avi support. I actually have a diff between r4000 and dosbox-x's files for that somewhere, but basically the issue is that if you're recording the video using the internal recording mechanism, if it hits the file size limit (2GB), the avi file is completely unusable. I originally worked around it just by having it stop and immediately restart the recording every X frames, which was more of a bandaid workaround than a true fix.

Unfortunately that diff is against an older version of dosbox, and not vanilla dosbox. Not a trivial change, but it touches the avi writer and wav writer in the process.
Kisai
Member
 
Posts: 129
Joined: 2010-5-05 @ 08:04

Re: DOSBox Feature Request Thread

Postby krcroft » 2019-10-07 @ 18:35

Some games like Destruction Derby expect their CD audio tracks to have exact placement in terms of their minute, second, frame (MSF) values. Ripping a CDROM to BIN and CUE lets one see those MSF values in the CUE file: each track's INDEX 01 value is the MSF expected by the game.

Unfortunately when a BIN+CUE is converted to individual audio track files (.opus, .flac, .wav, or .ogg), DOSBox looses the ability to provide the same original MSF values because it calculates them on the fly based on the length of each track, which are not guaranteed to perfectly match the original BIN+CUE track lengths. A deviation in track length by a mere 1/75th of a second (due to padding or rounding to full codec frame-sizes) is enough to ripple that error through all the downstream tracks MSF values.

To address this at the time, I wrote a small update that let users continue to use the original CUE's MSF values in conjunction with their compressed audio files, which pacifies Destruction Derby into working again (viewtopic.php?f=33&t=62417&p=699194#p699194). It turns out though that "INDEX 01 XX:YY:ZZ" is not standarized CUE syntax when dealing with file-based tracks, as RibShark pointed out here (https://sourceforge.net/p/dosbox/bugs/4 ... /da67/49d4). He then suggested a compliant method to provide MSF track values by embedding them inside CUE comments (details below).

I removed this MSF change to my main audio patch, which again broke Destruction Derby (viewtopic.php?f=32&t=52414&p=790811#p791529).

QBix, ripsaw8080: is MSF handling for file-based audio tracks something you'd like to tackle for core DOSBox in the near-term? I'm happy to drop a bug in sourceforge just to track it.

Alternatively, I'm happy to implement this MSF handling using RibShark's suggested compliant format: REM MSF: MM:SS:FF in a stand-alone branch, that we can review. Let me know what you think.
User avatar
krcroft
Member
 
Posts: 328
Joined: 2017-4-29 @ 15:07
Location: Ogden's Retreat

PreviousNext

Return to DOSBox General

Who is online

Users browsing this forum: No registered users and 1 guest