KainXVIII wrote:

Is Norton Commander windows supposed looks so.. squished?

This is a pixel-to-pixel representation of the source 640x400 image. What settings did you use and what did you expect? If you want aspect-ratio correction at so small a size, try the lossy surfacenp.

Ant_222 wrote:

KainXVIII wrote:

Is Norton Commander windows supposed looks so.. squished?

This is a pixel-to-pixel representation of the source 640x400 image. What settings did you use and what did you expect? If you want aspect-ratio correction at so small a size, try the lossy surfacenp.

Honestly, i don't know. But back in the day when i have old pc with ms-dos and NC i think it looks different, i mean it fills full screen. Or my memory deceive me 😀

KainXVIII wrote:

Is Norton Commander windows supposed looks so.. squished?

Does the attachement look better to you? I used the following settngs with Yesterplay80's enhanced build:

1windowresolution=original
2output=surfacenp
3surfacenp-sharpness=0
4aspect=true

KainXVIII wrote:

Honestly, i don't know. But back in the day when i have old pc with ms-dos and NC i think it looks different, i mean it fills full screen.

Yes, it did, on 4 x 3 CRT displays. If you want a pixel-perfect image with aspect-correction you shall need a display with the following minimal dimensions:

1w: 640*5 = 3200
2h: 400*6 = 2400

Ant_222 wrote:

Yes, it did, on 4 x 3 CRT displays. If you want a pixel-perfect image with aspect-correction you shall need a display with the […]
Show full quote

KainXVIII wrote:

Honestly, i don't know. But back in the day when i have old pc with ms-dos and NC i think it looks different, i mean it fills full screen.

Yes, it did, on 4 x 3 CRT displays. If you want a pixel-perfect image with aspect-correction you shall need a display with the following minimal dimensions:

Copy code to clipboard

1w: 640*5 = 3200
2h: 400*6 = 2400

So its my monitor to blame 😀
surfacenp is slow for me, especially when screen fades.

KainXVIII wrote:

So its my monitor to blame :)

Well, I have no problems with the slightly "squished" image. It is more important to keep it pixel-perfect.

KainXVIII wrote:

surfacenp is slow for me, especially when screen fades.

Then try openglnb or surfacenb in fullscreen. I fear it will require either parallalization or SDL 2.0 to make surfacenp faster. I will gladly accept any help in optimising my scaling routine.

KainXVIII wrote:

surfacenp is slow for me, especially when screen fades.

Yeah, this is the single reason I still use opengl with forced normal4x.

Ant_222 wrote:

Well, I have no problems with the slightly "squished" image. It is more important to keep it pixel-perfect. […]
Show full quote

KainXVIII wrote:

So its my monitor to blame 😀

Well, I have no problems with the slightly "squished" image. It is more important to keep it pixel-perfect.

KainXVIII wrote:

surfacenp is slow for me, especially when screen fades.

Then try openglnb or surfacenb in fullscreen. I fear it will require either parallalization or SDL 2.0 to make surfacenp faster. I will gladly accept any help in optimising my scaling routine.

Note, I have not changed the defaults unless otherwise specified.

I've noticed that switching between window and full screen is super-slow (at 4K) roughly 10 seconds. Almost as slow as stock dosbox.

scapepp:
Scaling: 320 x 200 (1.2) --[8.0 x 10.0]--> 2560 x 2000 (1.2), which seems wrong somehow. scalepp idle is only showing 0.13%

scalenp:
Scaling: 320 x 200 (1.2) --[8.8 x 10.6]--> 2824 x 2118 (1.2), 0.48% idle
Scaling: 320 x 200 (1.2) --[9.0 x 10.8]--> 2880 x 2160 (1.2) (full screen)
There is a distinctive screen lag/draw-lag that exists here that didn't exist with scalepp

Compared to my SDL2 build, (0.33% CPU max windowed/fullscreen at the same resolutions) there's definitely something amiss in np that is slowing down the actual emulated refresh display adapter that isn't reflected in the host CPU. Like you shouldn't really be able to see the screen redraws unless slowed down to the speed of an XT. It does kinda remind me of trying to play a game on a 286 however where the window repaints took longer than one second.

My theory is that the cpu time measurement here isn't really reflective of what is going on (using less than 4% of the host CPU.) The emulated machine needs to do X many things in a cycle, and if scalepp/scalenp is doing what I think it's doing, it might be slowing down the emulated VGA itself. When I run syschk on my build I get 44526 char/sec @ 10,000 cycles. When I run it on yesterplay80's build I get 43384/char/sec at 10,000 cycles. Daum's build (D3D) is 44526 as well, but it also doesn't do the correct windowed resolution.

So there is a slight impairment. 44526 is also what you get from stock dosbox at 10,000 cycles at any resolution.

Linked below are photos of the 4K monitor and how it looks with yesterplay80's build. I'll apologize for the size, I've only cropped it.
ScalePP:

ScaleNP:

The image sharing site requires you to click on it once to zoom it to the original size. I'd normally use another site but it's getting flaky.

Kisai wrote:

I've noticed that switching between window and full screen is super-slow (at 4K) roughly 10 seconds. Almost as slow as stock dosbox.

It may be caused by the mere entering into a new graphical mode, because my scalers currently work strictly at 32bpp. I don't think I have done anything in my patch to make it switch modes faster than stock DOSBox, so I don't see why you should expect that.

scapepp:
Scaling: 320 x 200 (1.2) --[8.0 x 10.0]--> 2560 x 2000 (1.2), which seems wrong somehow. scalepp idle is only showing 0.13%[/qutoe]What is wrong?

The image sharing site requires you to click on it once to zoom it to the original size. I'd normally use another site but it's getting flaky.

You could have provided a direct link, like this. Why do you photograph your monitor instead of posting the result of PrintScreen?

I will answer the rest of your post, and your other posts, later.

There were interesting discussion about how dosbox capture screenshots (without "true" aspect ratio), so i have question - can i resize these captured screenshots to 320x240 with pixel perfect image (with IrfanView for exampe)? Simple resize gives ugly result, resample not much better

Ant_222 wrote:

scapepp:
Scaling: 320 x 200 (1.2) --[8.0 x 10.0]--> 2560 x 2000 (1.2), which seems wrong somehow. scalepp idle is only showing 0.13%

What is wrong?

I'm not sure, something seems off about the pixel shape since it's not 1.33, instead it's 1.28:1

Ant_222 wrote:

You could have provided a direct link, like this. Why do you photograph your monitor instead of posting the result of PrintScreen?

I will answer the rest of your post, and your other posts, later.

I took photos of the monitor to show you what the actual aspect ratio and window-boxing looks like. If I hit print-screen while full screen it does not show any effect imposed by the monitor. Please do not take me for an idiot.

The SDL2 build I have switches between full screen and windowed mode instantly, but yesterplay80's build literately takes 10 seconds to switch in and out of windowed mode, and when it switches to full screen the initial image is pushed to the left before it moves to the center. This seems excessively slow and can't be chalked up entirely to the 4K resolution, especially when Dosbox-X and ykhwong's builds switch instantly as well. The stock dosbox takes 2-3 seconds, owing to the fact that the monitor is actually switching modes.

These are screenshots from windowed mode

SDL2 2560x1920 window

yesterplay80 scalenp 2560x1920 window

yesterplay80 scalepp 2560x2000 window

If you zoom into all of these, you'll notice that scalepp does in fact have multiplied pixel sizes ( 4 wide x 5 tall pixels ), where as scalenp is 4 wide, 4 tall and has a blended pixel row on the top and/or below, which gives it something of a shadow. The SDL2 texturenb is looks like a row of 4 wide x 4 tall followed by a 4 wide x 5 tall without the blending in a 5-4-5-5-5 pattern going down.

KainXVIII wrote:

There were interesting discussion about how dosbox capture screenshots (without "true" aspect ratio), so i have question - can i resize these captured screenshots to 320x240 with pixel perfect image (with IrfanView for exampe)? Simple resize gives ugly result, resample not much better

To resize a 320x200 image in a pixel-perfect manner with aspect-ratio correction, you should select the Resize (faster) mode, uncheck the Preserve aspect ratio option, and specify a horizontal scale of 500% and a vertical scale of 600%. Thus you will end up with a 1600x1200 image.

Kisai wrote:

Ant_222 wrote:

scapepp:
Scaling: 320 x 200 (1.2) --[8.0 x 10.0]--> 2560 x 2000 (1.2), which seems wrong somehow. scalepp idle is only showing 0.13%

What is wrong?

I'm not sure, something seems off about the pixel shape since it's not 1.33, instead it's 1.28:1

You are correct. The exact PAR of 1.2 would be achieved by a 10x12 scale, but your display is not big enough for that, whereas a scale of 5x6 is considered too small by the algorithm, so it chose a compromise. The resulting aspect ratio is slightly off. Did you perceive this visually or by measuring? Should you prefer a 1600x1200 image with the exact aspect ratio?

Why do you photograph your monitor instead of posting the result of PrintScreen?

I took photos of the monitor to show you what the actual aspect ratio and window-boxing looks like. If I hit print-screen while full screen it does not show any effect imposed by the monitor. Please do not take me for an idiot.

I don't. Whereas my patch operates at the display's native resolution, the output pixels are square and PrintScreen will give a faithful reproduction. You should have the same aspect ratio of 1:28 with it.

The SDL2 build I have switches between full screen and windowed mode instantly, but yesterplay80's build literately takes 10 seconds to switch in and out of windowed mode, and when it switches to full screen the initial image is pushed to the left before it moves to the center. This seems excessively slow and can't be chalked up entirely to the 4K resolution, especially when Dosbox-X and ykhwong's builds switch instantly as well. The stock dosbox takes 2-3 seconds, owing to the fact that the monitor is actually switching modes.

Thanks for the report. I will check it.

Ant_222 wrote:

KainXVIII wrote:

There were interesting discussion about how dosbox capture screenshots (without "true" aspect ratio), so i have question - can i resize these captured screenshots to 320x240 with pixel perfect image (with IrfanView for exampe)? Simple resize gives ugly result, resample not much better

To resize a 320x200 image in a pixel-perfect manner with aspect-ratio correction, you should select the Resize (faster) mode, uncheck the Preserve aspect ratio option, and specify a horizontal scale of 500% and a vertical scale of 600%. Thus you will end up with a 1600x1200 image.

Nice, it works!
Before i just resize image to 320x240 and then double enlarge two times and get something like this

Kisai wrote:

These are screenshots from windowed mode
[...]
If you zoom into all of these, you'll notice that scalepp does in fact have multiplied pixel sizes ( 4 wide x 5 tall pixels ),

Correct. That is what I define as pixel-perfect: each pixel is represented as an m x n rectangle, where m and n are the same for the whole image. There is no blurring but the pixel aspect ratio (PAR) may be slightly off, because the ratio m:n approximates it.

where as scalenp is 4 wide, 4 tall and has a blended pixel row on the top and/or below, which gives it something of a shadow.

Indeed—surfacenp stands for near-perfect and introduces a small amount of interpolative distortion. It was modeled on the super-sampling technique when a high normalnx scaler is applied and the result downscaled interpolatively by the GPU.

The SDL2 texturenb is looks like a row of 4 wide x 4 tall followed by a 4 wide x 5 tall without the blending in a 5-4-5-5-5 pattern going down.

That is nearest-neighbor interpolation. My patch offers it via surfacenb, but stock DOSBox already has it in openglnb

KainXVIII wrote:

Ant_222 wrote:

To resize a 320x200 image in a pixel-perfect manner with aspect-ratio correction, you should select the Resize (faster) mode, uncheck the Preserve aspect ratio option, and specify a horizontal scale of 500% and a vertical scale of 600%. Thus you will end up with a 1600x1200 image.

Nice, it works!
Before i just resize image to 320x240 and then double enlarge two times and get something like this

But you did it not as a described?

Ant_222 wrote:

KainXVIII wrote:

Ant_222 wrote:

To resize a 320x200 image in a pixel-perfect manner with aspect-ratio correction, you should select the Resize (faster) mode, uncheck the Preserve aspect ratio option, and specify a horizontal scale of 500% and a vertical scale of 600%. Thus you will end up with a 1600x1200 image.

Nice, it works!
Before i just resize image to 320x240 and then double enlarge two times and get something like this

But you did it not as a described?

Err, no, now i do how you described (if i understand you right)

KainXVIII wrote:

Err, no, now i do how you described (if i understand you right)

Looks correct to me.

Ant_222 wrote:

You are correct. The exact PAR of 1.2 would be achieved by a 10x12 scale, but your display is not big enough for that, whereas a scale of 5x6 is considered too small by the algorithm, so it chose a compromise. The resulting aspect ratio is slightly off. Did you perceive this visually or by measuring? Should you prefer a 1600x1200 image with the exact aspect ratio?

I actually perceived this visually, which kinda did "something isn't correct here" itch. Like in the nearest-neighbor algorithm, the aspect ratio is correct, so the thing that you notice more is that the text-fonts are not the right shape.

So I suppose it would matter more if the source video is text or graphics. Text-mode things have a definitely wrong look to it, but are the least impacted, since we're talking about showing all the pixels, and is far crisper than a CRT could ever be. Remember that CRT's often analog controls and were never perfect, so I think the text-mode could get away with this. In graphics mode, it comes back to "is a circle a circle" which the test is typically Wing Commander.

ScalePP

ScaleNP

SDL2-TextureNB

yhkwong,d3d

Of the screenshots, ScalePP seems warped just a little. But I think if the game was being played it wouldn't be noticed as much.

Scalepp, 104x110
Scalenp, 104x105
SDL2, texturenb 104x106
ykhwong d3d, 103x106

Same order:

Interestingly, it looks scalenp might be closer to an even shape.