VOGONS

Common searches


Reply 320 of 733, by PhilsComputerLab

User metadata
Rank l33t++
Rank
l33t++
Ant_222 wrote:
PhilsComputerLab wrote:

My understanding and experiments led to 1600 x 1200 being the pixel perfect resolution to display 320 x 200 games in 4:3 aspect ratio. I'm just wondering what I'm missing here.

That is correct for 320 x 200 games with the 5:6 pixel aspect raio. My patch should give this result with a 1600 x 1200 monitor. If it does not, post the game, a screenshot, and the relevant fragment of the config file.

So what does this project then do? I'm sorry I think I'm missing something obvious here 😊

YouTube, Facebook, Website

Reply 321 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
PhilsComputerLab wrote:

Ant_222 could be so kind and briefly explain how this project works? The gist of it?

In pixel-perfect mode, the patch draws each pixel of the source image as a rectangle of m x n pixels, where m:n approximates the original pixel aspect ratio (PAR) as well as possible (and often exactly, e.g. 1.2 = 6:5). The pixels are thus kept sharp and are all of the same size (unlike the nearest-neighbor interpolation).

Reply 322 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
PhilsComputerLab wrote:

So what does this project then do? I'm sorry I think I'm missing something obvious here :blush:

In other words from those in my previous post, this patch removes graphical distortion such as all kinds of interpolation and lossy (irregular) aspect ratio correction that is built into DOSBox. Edit: It might help to compare the appearance of the surfacepp with standard DOXBox modes.

Reply 323 of 733, by PhilsComputerLab

User metadata
Rank l33t++
Rank
l33t++
Ant_222 wrote:

approximates the original pixel aspect ratio (PAR) as well as possible

Oh now I get it. The aspect ratio gets changed, that's what I was missing!

So would your project benefit from a high resolution display, because it has more pixels to work with? 4K for example?

YouTube, Facebook, Website

Reply 324 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
PhilsComputerLab wrote:
Ant_222 wrote:

approximates the original pixel aspect ratio (PAR) as well as possible

Oh now I get it. The aspect ratio gets changed, that's what I was missing!
So would your project benefit from a high resolution display, because it has more pixels to work with? 4K for example?

In that case:

  • + screen area would be used more effectively,
  • + the emulated aspect ratio would be more accurate (and very likely exact),
  • - emulation would be slower

Reply 327 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member

So, I've been playing around with this patch tonight and am trying to determine the "best" setting for my preferences. I've read the patch notes and have done my own testing, and would just like to verify my findings.

Based on my experience, it seems that when playing in fullscreen mode, surfacepp gives the most accurate and sharpest picture. However, in windowed mode, surfacepp unfortunately does not seem to have a correct aspect ratio.

For windowed mode, both surfacenb and openglnb appear identical, while surfacenp seems a bit blurry as compared to the former. So my conclusion so far is thus:

surfacepp = Best possible picture for fullscreen mode. Accurate and sharp image.
surfacenp or openglnb = Most accurate and most sharp picture for windowed mode

Here are the screenshots I took with some notes. Some feedback on all this would be nice. I wish that surfacepp could also be used in windowed mode, otherwise, I have to switch output modes when I want to play in fullscreen versus when I want to play in windowed mode.

Here I have ranked the different modes as I have found through my testing:

Fullscreen mode
1. surfacepp (most accurate)
2. openglnb (less accurate)
3. surfacenp (seems potentially more accurate than surfacenb)
4. surfacenb (least accurate?)

Windowed mode
1. openglnb/surfacenb (seemingly identical - most accurate/most sharp)
2. surfacenp (more blurry/less correct)
3. surfacepp (incorrect aspect ratio)

surface-sharpness and surface-collapse-dbl were at their default values.

Am I interpreting all this correctly? Looking for some input here. I just want the most accurate and the sharpest image in both fullscreen and windowed mode and am simply trying to determine which settings will give me that. It would also be interesting to hear which setting may be the best "middle ground" so that I wouldn't have to switch between output modes frequently. As of right now, openglnb seems to be the best option for both fullscreen and windowed mode, if it indeed is more accurate than surfacenb when in fullscreen mode. Seeing as how surfacepp seems to give the best possible picture in fullscreen mode, it would be nice if it also produced the best (most correct/sharp) picture in windowed mode, as well.

Edit: Upon further testing it seems that surfacepp does in fact give a correct aspect ratio in windowed mode when the resolution is set high enough. I didn't see this in the patch notes - what's the minimum resolution at which surfacepp will render an accurate image in windowed mode? Is this dependent upon the game or across the board?

Reply 328 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

lukeman3000, the result of surfacepp depends entirely on the available area as measured in pixels. If you specify the windowed-mode resolution (nearly) as large as your display then the result will likely be identical to that of the full-screen mode. If the game is, say, 300x200 and you display it in a 600x400 window, it is simply impossible to display it with a correct aspect ratio with integer scaling, because the only available option is:

300x200 -> [2x2] -> [600x400]

Your interpretation depends on how you define accuracy. With surfacenb and openglnb the aspect ratio is accurate and the pixel boundaries sharp, but the pixels themselves are irregular. With surfacepp the pixels are sharp and regular, but their aspect ratio is not always accurate (but the best possible for the current setup). With surfacenp the aspect ratio is accurate but the pixels are slightly blurry.

lukeman3000 wrote:

Upon further testing it seems that surfacepp does in fact give a correct aspect ratio in windowed mode when the resolution is set high enough. I didn't see this in the patch notes - what's the minimum resolution at which surfacepp will render an accurate image in windowed mode? Is this dependent upon the game or across the board?

That's it. It is not about a minimum resolution but, rather, about integer arithmetics. The answer depends on how well integer scales may approximate the target aspect ratio while keeping the image within the available area.

Reply 329 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member
Ant_222 wrote:
lukeman3000, the result of surfacepp depends entirely on the available area as measured in pixels. If you specify the windowed-m […]
Show full quote

lukeman3000, the result of surfacepp depends entirely on the available area as measured in pixels. If you specify the windowed-mode resolution (nearly) as large as your display then the result will likely be identical to that of the full-screen mode. If the game is, say, 300x200 and you display it in a 600x400 window, it is simply impossible to display it with a correct aspect ratio with integer scaling, because the only available option is:

300x200 -> [2x2] -> [600x400]

Your interpretation depends on how you define accuracy. With surfacenb and openglnb the aspect ratio is accurate and the pixel boundaries sharp, but the pixels themselves are irregular. With surfacepp the pixels are sharp and regular, but their aspect ratio is not always accurate (but the best possible for the current setup). With surfacenp the aspect ratio is accurate but the pixels are slightly blurry.

lukeman3000 wrote:

Upon further testing it seems that surfacepp does in fact give a correct aspect ratio in windowed mode when the resolution is set high enough. I didn't see this in the patch notes - what's the minimum resolution at which surfacepp will render an accurate image in windowed mode? Is this dependent upon the game or across the board?

That's it. It is not about a minimum resolution but, rather, about integer arithmetics. The answer depends on how well integer scales may approximate the target aspect ratio while keeping the image within the available area.

To make sure I'm understanding this correctly.. It sounds to me that surfacepp is probably the desired mode, given that the resolution is appropriate (if running in windowed mode). However, you state that with surfacepp, the pixels are sharp and regular, but their aspect ratio is not always accurate (but the best possible for the current setup) -- what does this mean, in layman's terms? I was under the impression that surfacepp was pretty much the gold standard way of playing old DOS games because it perfectly scales the image, but is this potentially not the case if I value a more accurate aspect ratio? I guess I just don't understand how all of these things play together or what constitutes a "good" image, or if I should even particularly care about whatever accuracy of aspect ratio is lost when using surfacepp, versus the pros of having sharp and regular pixels. What I'm looking for is the most accurate, sharp, and in general, "correct" image, so does surfacepp give me that?

Also, is there a way to calculate what is the lowest resolution for any given game that surfacepp will work correctly with in windowed mode? In some games, like Space Quest 3, it's easy to test because the window is significantly wider when the window resolution is set too low. However, in Space Quest 6, the window doesn't seem to change much (visibly, anyways) in it's aspect ratio, so it's hard for me to tell what is too low and what is not. In other words, do I need to know the native output of the game and then be able to apply a certain calculation to this to figure it out? Additionally, are there other, more identifiable, signs that surfacepp is working correctly at a given resolution?

Potentially in my lack of understanding of the way things work, one thought that occurred to me is that it would be nice if surfacepp would automatically fall back to another mode (such as surfacenp, surfacenb, or openglnb - whichever is specified) when the window size is too small for surfacepp to work properly. This feature could be enabled/disabled. That way, one output mode could be set so that the user could switch between a small windowed mode and a fullscreen mode on-the-fly and have the best of both worlds without having to change the output mode in dosbox's config file. But maybe it's not this simple nor could it work this way - I have no idea.

Reply 330 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
lukeman3000 wrote:

To make sure I'm understanding this correctly.. It sounds to me that surfacepp is probably the desired mode, given that the resolution is appropriate (if running in windowed mode).

Such is my conviction.

However, you state that with surfacepp, the pixels are sharp and regular, but their aspect ratio is not always accurate (but the best possible for the current setup) -- what does this mean, in layman's terms?

That every pixel of the game is represented as a rectangle of m by n pixels on your monitor, and the ratio of m to n may not always correspond to the pixel aspect ratio (PAR) of the emulated graphical mode.

I was under the impression that surfacepp was pretty much the gold standard way of playing old DOS games because it perfectly scales the image, but is this potentially not the case if I value a more accurate aspect ratio?

And if you have an insufficient display resolution. If you value the correct aspect ratio higher than sharp and regular pixels, then you should not use surfacepp when it fails to keep the aspect ratio. You can check that in the DOSBox console log window. My patch reports both the original and approximated aspect ratios. See if they differ.

I guess I just don't understand how all of these things play together or what constitutes a "good" image, or if I should even particularly care about whatever accuracy of aspect ratio is lost when using surfacepp, versus the pros of having sharp and regular pixels. What I'm looking for is the most accurate, sharp, and in general, "correct" image, so does surfacepp give me that?

I am sure that a small error in the aspect ratio may be sacrificed to sharp and regular pixels, so I do recommend surfacepp in all circumstances.

Also, is there a way to calculate what is the lowest resolution for any given game that surfacepp will work correctly with in windowed mode?

If the game's native PAR is unity then surfacepp will always give a perfectly accurate aspect ratio. Otherwise, you should analyse the equation:

PARn = xs / ys
xs <= Wh / Wg
ys <= Hh / Hg
xs and yx are integers.

where PARn is the game's native PAR, xs and ys integer horizontal and vertical scales, Wh nad Hh the size in pixels of the available output area (either the size of the window of the fullscreen resolution), Wg and Hg the width and height of the game's native graphical mode. Franky, it is easier to run the game and see the error of PAR approximation in the debug console!

In some games, like Space Quest 3, it's easy to test because the window is significantly wider when the window resolution is set too low. However, in Space Quest 6, the window doesn't seem to change much (visibly, anyways) in it's aspect ratio, so it's hard for me to tell what is too low and what is not.

AFAIK, SQ6 is a relatively modern, hight-resolution game with a unity PAR, so surfacepp should work perfectly with it.

Potentially in my lack of understanding of the way things work, one thought that occurred to me is that it would be nice if surfacepp would automatically fall back to another mode (such as surfacenp, surfacenb, or openglnb - whichever is specified) when the window size is too small for surfacepp to work properly. This feature could be enabled/disabled. That way, one output mode could be set so that the user could switch between a small windowed mode and a fullscreen mode on-the-fly and have the best of both worlds without having to change the output mode in dosbox's config file. But maybe it's not this simple nor could it work this way - I have no idea.

It is possible, but the definition of "properly" is a fuzzy one. As I said, for a pixel purist such as I, surfacepp is the best mode always.

Reply 331 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member

Thanks for the very detailed reply. I read the wikipedia article you linked and have somewhat of a better understanding now.

I was wondering, could you help me translate this?

Available area: 1280x1024
Scaling: 320x200 (1.20) --[4.0 x 5.0]--> 1280x1000 (1.25)

I found this after running Space Quest 3 with surfacepp and window size of 1280x1024. I opened up stdout.txt (which is in the dosbox folder) and saw this near the bottom; assumed it was from your patch. Or do I need to be looking elsewhere to get the information I need?

If this is correct, then how exactly do I interpret everything here? I assume the following:

Available area: 1280x1024 which is the size of the window that I specified in dosbox config
320x200 is the game's SAR or native resolution
(1.20) - not sure what this represents... I assumed it was 320/200 but that is 1.6
[4.0 x 5.0] 320 is multiplied by 4 while 200 is multiplied by 5 (but why/how is this ratio chosen?) to get
1280 x 1000 which is the maximum resolution possible for a perfect PAR image given the available area of 1280x1024
(1.25) Again I assumed this represents 1280/1000 but this is not true, as that is 1.28...

So, if possible, could you clear up these misunderstandings and also educate me as to what I should be looking for when trying to determine if the window size I chose is adequate for surfacepp to work properly or not?

Also, this is what I get when running it fullscreen:

Available area: 2560x1440
Scaling: 320x200 (1.20) --[6.0 x 7.0]--> 1920x1400 (1.17)

In actuality, I get this:

DOSBox version ECE
Copyright 2002-2017 DOSBox Team, published under GNU GPL.
---
CONFIG:Loading primary settings from config file C:\Users\lmill\AppData\Local\Temp\DOSBOX.CONF
MIDI: Opened device:mt32
PC speaker output buffer length: 145
mixer callback wants too many samples from pc speaker emulator: 442
mixer callback wants too many samples from pc speaker emulator: 296
mixer callback wants too many samples from pc speaker emulator: 151
Available area: 2560x1440
Scaling: 640x400 (1.20) --[3.0 x 3.0]--> 1920x1200 (1.00)
DOS keyboard layout loaded with main language code US for layout US
SHELL: Redirect output to nul
Available area: 2560x1440
Scaling: 320x200 (1.20) --[6.0 x 7.0]--> 1920x1400 (1.17)
MT32: LCD-Message: * SPACE QUEST III *
MT32: LCD-Message: INSERT BUCKAZOID
Available area: 2560x1440
Scaling: 640x400 (1.20) --[3.0 x 3.0]--> 1920x1200 (1.00)
Available area: 1280x1024
Scaling: 640x400 (1.20) --[2.0 x 2.0]--> 1280x800 (1.00)

But I assume that the line that matters is the line that includes the game's original resolution, which I believe would be the line with 320x200... That makes me wonder, what are all the other entries, and is there a better way to know which one pertains to the game (if you don't know its native resolution?)

Reply 332 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
lukeman3000 wrote:
Thanks for the very detailed reply. I read the wikipedia article you linked and have somewhat of a better understanding now. I w […]
Show full quote

Thanks for the very detailed reply. I read the wikipedia article you linked and have somewhat of a better understanding now.
I was wondering, could you help me translate this?

Available area: 1280x1024
Scaling: 320x200 (1.20) --[4.0 x 5.0]--> 1280x1000 (1.25)

I found this after running Space Quest 3 with surfacepp and window size of 1280x1024. I opened up stdout.txt (which is in the dosbox folder) and saw this near the bottom; assumed it was from your patch. Or do I need to be looking elsewhere to get the information I need?

This is from my patch indeed, and here is the explanation:

Available area is the maximum size of the output image. In windowed mode it is the window dimensions and in full-screen mode it is your full-screen resolution. Both are specified in the DOSBox config file. 320x200 is the resolution of the graphical mode of the game being emulated and 1.20 is its PAR, as reported by DOSBox. [4.0 x 5.0] shows the horizontal and vertical scaling factors that my patch applies. The final entry contains the resulting image resolution, 1280x1000:

320 * 4.0 = 1280
200 * 5.0 = 1000

and PAR:

5.0 / 4.0 = 1.25

Each pixel of the game is represented as a 4x5 rectangle and therefore has a PAR of 1.25. Since 1.25 is within 4.1% of 1.20, the aspect ratio of the scaled image is nearly perfect, and the difference is barely perceptible. If the available area were at least 1600x1200, then you would have a perfect PAR:

320 * 5.0 = 1600
200 * 6.0 = 1200
5.0 / 4.0 = 1.2 ( = source PAR)

Thanks for the question.

Edit:

(1.25) Again I assumed this represents 1280/1000 but this is not true, as that is 1.28...

To clarify—1.25 is the pixel aspect ratio. The image aspect ratio is:

Original image:
(320/200) / 1.2 = 4:3 ~ 1.333
(the standard CRT aspect ratio)

Resulting image:
1280/1000 = 1.28
(not quite 1.333, but close enough)

Edit2:

[4.0 x 5.0] 320 is multiplied by 4 while 200 is multiplied by 5 (but why/how is this ratio chosen?) to get 1280 x 1000

Those values provide the best approximation (1.25) of the original PAR (1.20) in the conditions given.

Reply 333 of 733, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Ant, is there a problem with 640x400 mode with your patch?
Norton Commander does not comply to 4:3 with your patch, or any other 640x400 game.
Even the basic DOS screen does not turn into 4:3, but remains 640x400.
They are all double-scanned, from 320x200 original resolution.
I'm sure 640x400 should be 4:3 like 320x200.


my important / useful posts are here

Reply 334 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
James-F wrote:
Ant, is there a problem with 640x400 mode with your patch? Norton Commander does not comply to 4:3 with your patch, or any other […]
Show full quote

Ant, is there a problem with 640x400 mode with your patch?
Norton Commander does not comply to 4:3 with your patch, or any other 640x400 game.
Even the basic DOS screen does not turn into 4:3, but remains 640x400.
They are all double-scanned, from 320x200 original resolution.

Double-scanning applies to rows but not to columns, does it not? Are you certain it is not true 640x400? See the debug output.

I'm sure 640x400 should be 4:3 like 320x200.

That is correct. In order to display 320x200 in the original 4:3 aspect ratio my patch needs a host resolution of at least 1600x1200, although 1280 x 1000 works well too. In order to do the same with 640x400 it would need 3200x2400 and 2560x2000 respectively. Do you have that?

Reply 335 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member

I think you already answered this but perhaps I didn't understand - you said that 1.20 is the PAR of 320x200, but how do you arrive at that PAR given the resolution? Do we have enough information to make that determination from what we are given in the dosbox log?

5 x 4 is the scaling factor applied to the original resolution (with an imperfect PAR of 1.25 as compared to 1.20) but the original pixels were not 5 x 4, so how is the height/width of the original PAR determined?

Reply 336 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
lukeman3000 wrote:

I think you already answered this but perhaps I didn't understand - you said that 1.20 is the PAR of 320x200, but how do you arrive at that PAR given the resolution?

Yes, I have already written that my patch relies on the value of the original PAR reported by DOSBox. This is the right value in the majority of cases.

Do we have enough information to make that determination from what we are given in the dosbox log?

Since the patch explicitly prints it in the log, yes :-) But it does not calculate it in any way. The resolution and PAR of the emulated game are its input parameters. They are shown to the left of the arrow in the log.

5 x 4 is the scaling factor applied to the original resolution (with an imperfect PAR of 1.25 as compared to 1.20) but the original pixels were not 5 x 4, so how is the height/width of the original PAR determined?

I hope that is clear now—the patch approximates the target ratio of 1.20 as a ratio of small integers such that the upscaled image is within the available area. The ideal approximation would be 5 x 6, but in your case the window is not large enough.

Edit: If you can read ANSI C, you may check the algorithm yourself:

/* /src/gui/pixelscale.cpp  */
static void get_perfect_scale
( ps_size size_in, /* input image dimensions */
float a_in, /* input image PAR */
ps_size size_out, /* available area */
int* scalex, /* horizontal scale */
int* scaley /* vertical scale */
)

Reply 337 of 733, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Ant,
When using any of the three pixel perfect outputs on a raspberry pi 3, screen-intensive transitions starve dosbox's audio emulator (such as any of the SB opl emus: nuked, default, fast, and compat), resulting in heavy stuttering of audio during the transition.
This happens even with ample cycles (24000), huge audio buffers, and low audio sampling rates such 22050 Hz.
A good example is Wolfenstien 3D, which starts by showing the hardware configuration status and then fade-transitions to the game menu screen. This initial fade causes music stuttering. Most menu choices transitions will also stutter the audio, as do heavy panning scenes during gameplay.

Surface and overlay are not affected, both with and without aspect correction.

I suspect the pi 3 doesn't have the horse power to perform the additional pixel perfect calculation per frame (despite building with gcc7, maximum ARM and neon optimizations, and profile feedback); perhaps there are shortcuts or optimizations that can be made in the algorithm?

Reply 338 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
krcroft wrote:

Ant,
When using any of the three pixel perfect outputs on a raspberry pi 3,

I am surprised and chuffed that my patch is used on the Raspberry Pi. In fact, there is only one pixel-perfect mode in my patch—surfacepp, which was the only one until I had yielded to implementing the slightly blurry "near-perfect" mode surfacenp, preferred by many users (but not me). The nearest-neighbor mode turned to be a special case of the latter, so I implemented it in surfacenb. surfacenp should be (and in my environment is) much slower than the other two because it performes floating-point calculations for interpolation.

screen-intensive transitions starve dosbox's audio emulator (such as any of the SB opl emus: nuked, default, fast, and compat), […]
Show full quote

screen-intensive transitions starve dosbox's audio emulator (such as any of the SB opl emus: nuked, default, fast, and compat), resulting in heavy stuttering of audio during the transition.
[...]
A good example is Wolfenstien 3D, which starts by showing the hardware configuration status and then fade-transitions to the game menu screen. This initial fade causes music stuttering. Most menu choices transitions will also stutter the audio, as do heavy panning scenes during gameplay.

I suspect the pi 3 doesn't have the horse power to perform the additional pixel perfect calculation per frame (despite building with gcc7, maximum ARM and neon optimizations, and profile feedback);

That should seem the case. Mine is a primitive and naive single-threaded software scaler. I have made what little optimizations I could easily arrive at. For example, I went to some trouble to keep the piece-wise updating of the screen via SDL's "update rectangles", which obviously does not help when the whole screen is refreshed with every frame.

If you understand advanced profiling techniques, perhaps you can help? The whole scaling algorithm is implemented in the files pixelscaling.h pixelscaling.cpp in the src/gui/ directory, and can be tested and profiled separately from DOSBox. I had a program that would read an image from the HDD, upscale a certain rectangle of it, and save the result to another file. I measured preformance by causing the program to repeat the upscaling several thousand times.

I can provide you with a minimal test program with no third-party dependencies, which will compile nigh anywhere. If you will determine the bottlenecks on your Raspberry Pi, I will see how they can be amended.

For reasons of generality I tried to implement pixel-format conversions on-the-fly via function pointers, but it being very slow, I added a fallback to direct memory copy if the pointer is null. Keep that in mind while testing.

Another problem with the development of the patch is my lack of time coupled with the maintenance of the code as a separate patch rather than an integral part of DOSBox. My patch begins a generic framework for device-independent software-based scalers, into which, for example, the long-coveted xBRZ could be added with relative ease. That has affected a lot of code, any change of which in the SVN is likely to break my patch. If the patch were accepted into the SVN I could work on it with a peace of mind.

Reply 339 of 733, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

I can provide you with a minimal test program with no third-party dependencies, which will compile nigh anywhere. If you will determine the bottlenecks on your Raspberry Pi, I will see how they can be amended.

I would be happy to try to help by getting profiling data for you. I'm a big fan and user of your patch on my general linux machine and would love to see this get wider adoption into retropie's dosbox distribution.