Kisai wrote:

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 you perceived an error of

11 - (8/10) / (10/12) = 4%

I might need to add a setting specifying the relative importance of preserving the aspect ratio over using more of the screen area. This value is currently hard-coded in the patch (ASPECT_IMPORTANCE in pixelscale.cpp). If you increase it sufficiently, you will get a perfect 1600x1200 image, although too small.

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.

I agree, for I have no discomfort in reading text magnified in a pixel-perfect manner either with or without aspect-ratio correction.

In graphics mode, it comes back to "is a circle a circle" which the test is typically Wing Commander. [...] Of the screenshots, […]
Show full quote

In graphics mode, it comes back to "is a circle a circle" which the test is typically Wing Commander.
[...]
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

113x11 --[8x10]--> 104x110

which gives a 4% error as shown above. I can't comment on the other two cropped screenshots without knowing their full dimensions. On my system with surfacenp I have:

1320 x 200 (1.2) --[4.2 x 5.0]--> 1344 x 1008 (1.2)
2where 1344/1008 = 1.333

which is very close to the target 4/3 aspect ratio. Aspect-ratio error is best analysed using full screenshots.

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

Is scalenp a typo? surfacenb, surfacenp, and the hardware scaling modes of stock DOSBox should preserve the source PAR within tenths of a percent, which is an imperceptible difference.

Ant_222 wrote:

which gives a 4% error as shown above. I can't comment on the other two cropped screenshots without knowing their full dimension […]
Show full quote

Copy code to clipboard

113x11 --[8x10]--> 104x110

which gives a 4% error as shown above. I can't comment on the other two cropped screenshots without knowing their full dimensions. On my system with surfacenp I have:

Copy code to clipboard

1320 x 200 (1.2) --[4.2 x 5.0]--> 1344 x 1008 (1.2)
2where 1344/1008 = 1.333

which is very close to the target 4/3 aspect ratio. Aspect-ratio error is best analysed using full screenshots.

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

Is scalenp a typo? surfacenb, surfacenp, and the hardware scaling modes of stock DOSBox should preserve the source PAR within tenths of a percent, which is an imperceptible difference.

Everything but surfacepp was 2560x1920, I then zoomed the desktop window screenshots in photoshop down to the pixel grid and cropped them around the radar circle in wing commander in the same way. The point was "does this look like a circle?"

And oops that was how I named the screenshot files since they would look identical.

Kisai wrote:

Everything but surfacepp was 2560x1920, I then zoomed the desktop window screenshots in photoshop down to the pixel grid and cropped them around the radar circle in wing commander in the same way. The point was "does this look like a circle?"

Then all the tiny differences are due to the local interpolation effects. They can hardly cause a perceptible difference in the shape of objects:

12560/1920 = 1.333 = 4/3

It is impossible to detect the exact boundaries between the source pixels if they are interpolated.

And oops that was how I named the screenshot files since they would look identical.

Yes, they all have identical aspect ratios, except for surfacepp.

Thanks for testing!

Is this patch working on linux?
I get this while I'm compiling:

1sdlmain.cpp: In function ‘void ssPsEndUpdate()’:
2sdlmain.cpp:641:50: error: cannot convert ‘unsigned int*’ to ‘Bitu* {aka long unsigned int*}’ for argument ‘2’ to ‘char ssGetOutPixels(Bit8u**, Bitu*)’
3  ssGetOutPixels( &pix_out.pixels, &pix_out.pitch );
4                                                  ^
5sdlmain.cpp: At global scope:
6sdlmain.cpp:663:37: error: ISO C++ forbids declaration of ‘ssSetSurfaceMode’ with no type [-fpermissive]
7 ssSetSurfaceMode( SURFACE_MODE mode )
8                                     ^
9sdlmain.cpp:682:8: error: ISO C++ forbids declaration of ‘ssFree’ with no type [-fpermissive]
10 ssFree()
11        ^
12Makefile:358: recipe for target 'sdlmain.o' failed

Used the Alpha 10 patch available in the first post of this thread with DOSBox SVN r4000

marooned_on_mars wrote:

Is this patch working on linux?I get this while I'm compiling:
[...]
Used the Alpha 10 patch available in the first post of this thread with DOSBox SVN r4000

It should work on Linux, but I have only compiled in MinGW. I will analyse these erorrs and try to fix them. Thanks for the report.

No, thank YOU for the patch 😁

marooned_on_mars, please test the attached patch. I don't have a Linux environment set up, yet I think I have fixed the errors you indicated.

Seems that has fixed the errors on sdlmain.cpp, but now it complains on pixelscale.cpp instead:

1pixelscale.cpp:245:34: error: ISO C++ forbids declaration of ‘init_bound_cols’ with no type [-fpermissive]
2 static init_bound_cols( info* si )
3                                  ^
4pixelscale.cpp:251:34: error: ISO C++ forbids declaration of ‘free_bound_cols’ with no type [-fpermissive]
5 static free_bound_cols( info* si )
6                                  ^
7pixelscale.cpp:304:77: error: ISO C++ forbids declaration of ‘handle_dwh_scale’ with no type [-fpermissive]
8 static handle_dwh_scale( char dw, char dh, ps_pixels *pix_in, ps_rect* rect )
9                                                                             ^
10pixelscale.cpp:411:72: error: ISO C++ forbids declaration of ‘get_pixel’ with no type [-fpermissive]
11 static inline get_pixel( ps_format_in fmt, uchar* whence, uchar* pixel )
12                                                                        ^
13pixelscale.cpp:437:74: error: ISO C++ forbids declaration of ‘put_pixel’ with no type [-fpermissive]
14 static inline put_pixel( ps_format_out fmt, uchar* whither, uchar* pixel )
15                                                                          ^
16pixelscale.cpp:497:78: error: ISO C++ forbids declaration of ‘inc_rect’ with no type [-fpermissive]
17 static inc_rect( ps_rect* rect, ps_size size, char l, char r, char t, char b )
18                                                                              ^
19Makefile:358: recipe for target 'pixelscale.o' failed
20make[3]: *** [pixelscale.o] Error 1

The errors look similar.
When am I supposed to apply the patch? Before or after running autogen.sh?
Also, the patch doesn't seem to play nicely with munt's own diff file:

1$ patch -p1 < dosbox-SVN-r3892-mt32-patch.diff 
2patching file src/Makefile.am
3patching file src/dosbox.cpp
4Hunk #1 succeeded at 492 (offset 1 line).
5Hunk #2 succeeded at 508 (offset 1 line).
6patching file src/gui/Makefile.am
7Hunk #1 FAILED at 7.
81 out of 1 hunk FAILED -- saving rejects to file src/gui/Makefile.am.rej
9patching file src/gui/midi.cpp
10patching file src/gui/midi_mt32.cpp
11patching file src/gui/midi_mt32.h
12patching file src/mt32options.h

Anyone know what I must to to adjust munt's diff?

marooned_on_mars wrote:

When am I supposed to apply the patch? Before or after running autogen.sh?

Before you run "configure" even.

marooned_on_mars wrote:

Also, the patch doesn't seem to play nicely with munt's own diff file:

...

Anyone know what I must to to adjust munt's diff?

Do you know how diff files work? If not, I recommend reading this article first. It seems that the part of the Makefile.am the munt diff wants to change has already been altered by another patch before. Or the patch is for another version of the source file, maybe an older DOSBox version. Because of that, the patch routine can't find the pattern it is looking for and this results in the error you are getting. This might be something trivial like a line break, but might as well be something bigger. You have to compare the patched Makefile.am to the diff that's not working and see, wht exactly it tries to change and if you can actually find this pattern in the Makefile.am.

marooned_on_mars, I will fix those errors. Does anyone know why they are not reported in MinGW with the same makefile?

Ant_222 wrote:

marooned_on_mars, I will fix those errors. Does anyone know why they are not reported in MinGW with the same makefile?

Different compilers allow, forbid or tolerate different code, so I think it's just that.

Yesterplay80 wrote:

Ant_222 wrote:

marooned_on_mars, I will fix those errors. Does anyone know why they are not reported in MinGW with the same makefile?

Different compilers allow, forbid or tolerate different code, so I think it's just that.

Different versions of gcc with the same settings? Very strange, especially considering that mine are blatant errors, I must admit...

Ant_222 wrote:

Different versions of gcc with the same settings? Very strange, especially considering that mine are blatant errors, I must admit...

I don't know which compiler he's using. And I'm no pro at all, but I'm pretty sure different versions of the same compiler can do things different. You remember the graphic glitch in your DOSBox build? Same code, same compiler, different versions.

Yesterplay80 wrote:

Before you run "configure" even.

Obviously! I'm asking because munt's patch requires me to apply it after running autogen.sh

Yesterplay80 wrote:

Do you know how diff files work? If not, I recommend reading this article first. It seems that the part of the Makefile.am the munt diff wants to change has already been altered by another patch before.

Thanks, I'll look into it.

Yesterplay80 wrote:

Or the patch is for another version of the source file, maybe an older DOSBox version.

It was intended for r3892, but it compiled on r4000 too. Sergm only releases those patches when major stuff are changed in DOSBox's code.

Ant_222 wrote:

marooned_on_mars, I will fix those errors.

Thanks!

Yesterplay80 wrote:

Ant_222 wrote:

Different versions of gcc with the same settings? Very strange, especially considering that mine are blatant errors, I must admit...

I don't know which compiler he's using. And I'm no pro at all, but I'm pretty sure different versions of the same compiler can do things different. You remember the graphic glitch in your DOSBox build? Same code, same compiler, different versions.

Seems at compile time, gcc v6.2.0 20161109 was used, according to the configure logs.

marooned_on_mars, please check the attached corrected patch.

Yesterplay80 wrote:

I don't know which compiler he's using. And I'm no pro at all, but I'm pretty sure different versions of the same compiler can do things different. You remember the graphic glitch in your DOSBox build? Same code, same compiler, different versions.

That is more subtle. I have looked at the code that draws the welcome screen and did not understand a bit of it.

Okay, thanks for the fix Ant_222! This time it compiled properly. Though, I couldn't get it to stretch the image (or pixels) to the correct aspect ratio. Instead I get what I would normally get by using normal3x without aspect ratio correction. I'll read this thread in more detail to see what to change within DOSBox's configuration.

Also I fixed Munt's diff file, and I'll attach it. I would appreciate it if you could attach the file to the main post, so whoever might need it could see it.

marooned_on_mars wrote:

Okay, thanks for the fix Ant_222! This time it compiled properly. Though, I couldn't get it to stretch the image (or pixels) to the correct aspect ratio. Instead I get what I would normally get by using normal3x without aspect ratio correction. I'll read this thread in more detail to see what to change within DOSBox's configuration.

I can help you if you will specify your DOSBox settings and display resolution and give screenshots. Edit: Also pay heed to the Scaling: line in the DOXBox Status Window.

Settings:

1fullscreen=true
2fullresolution=desktop
3output=surfacepp
4machine=svga_s3
5aspect=true
6scaler=normal3x

My monitor's native resolution is 1366x768, which is the 16:9 analogue of 1024x768. I know, I know, I probably should get a bigger monitor, but money's tight right now. (gee, does that make me sound like a temporarily embarrassed millionaire... ugh)

I get this in STDOUT when I am in text mode:
Scaling: 640 x 400 (1.2) --[1.0 x 1.0]--> 640 x 400 (1.0)

And when in graphics mode/games:
Scaling: 320 x 200 (1.2) --[3.0 x 3.0]--> 960 x 600 (1.0)

So I'm guessing that the filter can't fit the corrected image? It should still work with 2x magnification.

Also you didn't say anything about my fixed munt diff. If you don't want to add it to the main post, then could you suggest me where I could post it?

marooned_on_mars wrote:

My monitor's native resolution is 1366x768, which is the 16:9 analogue of 1024x768.

Interesring—I have never heard of this format.

I know, I know, I probably should get a bigger monitor

Nope, I was not going to say that. My own main PC is some twelve years old and has Windows XP on it, and my other PC sports an old Viewsonic LCD with a resoltion of 1024x768.

I get this in STDOUT when I am in text mode: […]
Show full quote

I get this in STDOUT when I am in text mode:

Copy code to clipboard

1Scaling: 640 x 400 (1.2) --[1.0 x 1.0]-->  640 x 400  (1.0)

And when in graphics mode/games:

Copy code to clipboard

1Scaling: 320 x 200 (1.2) --[3.0 x 3.0]-->  960 x 600  (1.0)

So I'm guessing that the filter can't fit the corrected image? It should still work with 2x magnification.

You are correct. When my scaler is active, it overrides the scaler with none, so that won't help you. It is simply impossible to apply pixel-perfect aspect-ratio correction with your monitor.

Also you didn't say anything about my fixed munt diff. If you don't want to add it to the main post, then could you suggest me where I could post it?

I don't know what that munt diff is all about and how it is related to my patch. Do you suggest that I should include it into my patch and maintain it? What about the original author?