VOGONS

Common searches


DOSBox Feature Request Thread

Topic actions

Reply 200 of 298, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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?

Reply 201 of 298, by junglemontana

User metadata
Rank Newbie
Rank
Newbie
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. 😜 The scalers used by Dosbox (e.g. hq, supersai) are very nice but it seems that they only support certain resolutions.

Reply 202 of 298, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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?

Reply 203 of 298, by junglemontana

User metadata
Rank Newbie
Rank
Newbie
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:
Scalers and supported resolutions

Reply 204 of 298, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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

src/gui/render_scalers.h

.

junglemontana wrote:

I posted a question about this here:
Scalers and supported resolutions

Sadly, no replies.

Reply 205 of 298, by Gatekeeper

User metadata
Rank Newbie
Rank
Newbie

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 😀

Don't waste your time, or time will waste you...

Reply 206 of 298, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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.

How To Ask Questions The Smart Way
Make your games work offline

Reply 208 of 298, by junglemontana

User metadata
Rank Newbie
Rank
Newbie
Ant_222 wrote:
Looks like an arbitrary constraint to me. The relevant constants can be redefined in […]
Show full quote
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

src/gui/render_scalers.h

.

junglemontana wrote:

I posted a question about this here:
Scalers and supported resolutions

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?

Reply 209 of 298, by Gernot66

User metadata
Rank Newbie
Rank
Newbie

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

maintainer of "Phoenix" (Pioneer Space Sim derivate)
https://forums.frontier.co.uk/threads/phoenix … erivate.506984/

Reply 212 of 298, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

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:

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:

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.

Reply 214 of 298, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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 😉

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 217 of 298, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 218 of 298, by Kisai

User metadata
Rank Member
Rank
Member

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.

Reply 219 of 298, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

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 (Re: [SOLVED] Destruction Derby IMG file mounted, asks for CD). 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/497/#e5 … /acc7/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 (Re: DOSBox ECE (for Windows & Linux)).

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.