Reply 20 of 733, by Ant_222
You shall be the first to test my buggy alpha build, but I am sorry to say that it won't come till the next weekend.
You shall be the first to test my buggy alpha build, but I am sorry to say that it won't come till the next weekend.
wrote:You shall be the first to test my buggy alpha build, but I am sorry to say that it won't come till the next weekend.
I am honored 😊
PS - at least on my settings i'm not getting this mess https://www.gog.com/upload/forum/2015/05/98be … 6b60a07f2cc.jpg
wrote:You mean non-square pixels? I plan to approximate them by representing each pixel on the display as an m-by-n rectangle, where m and n are small natural numbers.
I don't think that's going to work very well, if you use the same m and n for all pixels on screen.
The amount of 'non-squareness' of some videomodes is going to fit very poorly.
I think my approach would be to find the best integer-fit horizontally. Then you calc the fractional fit vertically, based on the proper aspect ratio and horizontal scale. Then you approximate this by distributing the rounding error over your scanlines... So some scanlines will be scaled up to n scanlines, others to n+1 scanlines.
As long as the resolution is high enough, the variation is very subtle, and shouldn't really be visible. I think it's much less annoying than having completely wrong aspect ratios at least.
wrote:wrote:You mean non-square pixels? I plan to approximate them by representing each pixel on the display as an m-by-n rectangle, where m and n are small natural numbers.
I don't think that's going to work very well, if you use the same m and n for all pixels on screen.
The amount of 'non-squareness' of some videomodes is going to fit very poorly.
Could you name several such ill-fitting graphical modes with corresponding games that I might test them?
wrote:I think my approach would be to find the best integer-fit horizontally. Then you calc the fractional fit vertically, based on the proper aspect ratio and horizontal scale. Then you approximate this by distributing the rounding error over your scanlines... So some scanlines will be scaled up to n scanlines, others to n+1 scanlines. As long as the resolution is high enough, the variation is very subtle, and shouldn't really be visible. I think it's much less annoying than having completely wrong aspect ratios at least.
That is exactly what the output device openglnb does, sans aspect correction. It really looks ugly to me I should prefer a distorted aspect ratio to this kind of irregular scaling, and I think that any pixel artist will concur. KainXVIII seems to agree as well (see his previous post). Such small games as ROTK-1 and "Lure of the temptress" look ugly even on my 1680x1050 display.
wrote:Its dosbox.conf settings for pixel perfect scaling which i use
output=direct3d pixelshader=bilinear.fx aspect=true scaler=normal5x […]
output=direct3d
pixelshader=bilinear.fx
aspect=true
scaler=normal5x
You might try to set aspect=false and output=surface to get a pixel-perfect, but not aspect-corrected, image. Should work well for games running in graphical modes with near-unity aspect ratios.
wrote:Could you name several such ill-fitting graphical modes with corresponding games that I might test them?
Wouldn't know any games offhand... but well... your regular CGA/EGA/VGA lowres is 320x200, then various Mode X games are 320x240, Hercules is 720x350, EGA hires is 640x350...
So that shows what you're going to be dealing with.
Here is "Lure of the Tempress" displays in the modified DOSBox in fullscreen with pixel-perfect aspect-ratio correction.
EDIT: the image was corrupted by the hosting. Uploading.
wrote:Here is "Lure of the Tempress" displays in the modified DOSBox in fullscreen with pixel-perfect aspect-ratio correction.
Your example has the source pixels scaled 4 pixels wide and 5 pixels high, scaled pixel aspect ratio 1.25, scaled resolution 1280x1000.
The ideal would be to scale 5 pixels wide and 6 pixels high, scaled pixel aspect ratio 1.2, scaled resolution 1600x1200.
Of course the ideal scaling won't fit on your display, so you are trading some accuracy in the aspect ratio for "perfectly blocky" scaling. How much will you allow the aspect ratio to be off (the tolerance) when deciding on the scaling factors for other combinations of source and display resolutions?
wrote:Your example has the source pixels scaled 4 pixels wide and 5 pixels high, scaled pixel aspect ratio 1.25, scaled resolution 1280x1000.
The ideal would be to scale 5 pixels wide and 6 pixels high, scaled pixel aspect ratio 1.2, scaled resolution 1600x1200.
Of course the ideal scaling won't fit on your display, so you are trading some accuracy in the aspect ratio for "perfectly blocky" scaling.
That's right.
wrote:How much will you allow the aspect ratio to be off (the tolerance) when deciding on the scaling factors for other combinations of source and display resolutions?
I see three possibilities here: a) find the best approximation that the resolution allows (may result in small magnification factors), b) magnify one side to the maximum and the other to the best scale possible (may result in suboptimal dispalyed aspect ratios), and c) find a compromise between magnification and aspect-ratio error. I can easily implement all three, but my first version will have c). Other progammers (or I later) may improve it, add their own algorithms, or manual control over vertical and horizontal scaling.
wrote:Wouldn't know any games offhand... but well... your regular CGA/EGA/VGA lowres is 320x200, then various Mode X games are 320x240, Hercules is 720x350, EGA hires is 640x350...
So that shows what you're going to be dealing with.
Being dearly short on time, I should appreciate someone's naming several games with which to test the pixel-perfect scaling and aspect correction. I must test my code for blatant errors before releasing the binary alpha version. Speaking of which, I can only prepare a Windows x86 build which I do in MinGW on my Windows XP machine.
After the alpha, we can discuss the interface to this feature. I think that for the time being an overlaypp (for [P]ixel-[P]erfect) would be OK.
My other concern is checking the changes back into the repository. If sdlmain.cpp is modified frequently, I might have trouble during merge.
Should be easy enough to find games in 320x200 or Hercules 720x350. Most early DOS games will support CGA, EGA, VGA and Hercules. Prince of Persia for example.
For 320x240 you could check out Mode X games, I think DOOM uses the 320x240 mode. Else try Quake, it supports various modes.
Then you need to find a high-res EGA game for 640x350... I am not sure, but I think SimCity may be one that uses it. Else there's various shareware board/card games that used that resolution. Or you could just install Windows 3.x with an EGA driver, that also gives you 640x350.
Flashback could be interesting, 256x224 double-height double-width.
The Dial8 graphics demo has some oddball tweaked resolutions.
Scali, OK, I will test it with several different games (but only with one display!).
Thanks for the samples, ripsaw8080. I think (not at my home PC right now) that dobule-height and double-width flags are handled in render.cpp and the final input surface used in sldmain.cpp already takes them into account. Will have to check whether I shall need to treat the render.src.ratio (IIRC) variable accordingly.
Albion has unusual resolution i think (360x240?)
wrote:Flashback could be interesting, 256x224 double-height double-width.
How should it be displayed? What is the aspect ratio of its native pixels? Since it is double-height and double-width, and render.src.ratio is unity, my algorithm magnifies it proportionally to 4x4 = 1024*896, which looks too narrow. Where is the snag?
The pixel aspect ratio DOSBox uses (based on overscan area as well as drawn area) for Flashback is 1.0, although it's possible there would be more horizontal stretching on a real CRT. The aspect calculation in Hal's MB6 uses something a bit wider, for example. Anyway, I guess you should just use the ratio indicated, and it will at least be consistent with other output methods. BTW, I think Flashback's unusual resolution is due to shared DNA with its console variants.
It is not always safe to calculate the pixel aspect ratio as:
0.75 * width / height
For 640 x 480 it is unity, and for 256x224 it is 0.857.
Whoever has Windows is welcome to try the new pixel-perfect scaling implemented in the attached build. Please, consult the readme file for configuration.
Update: respect the aspect ratio reported by DOSBox.
Thanks, looks cool, i guess! Is it normal, that most of the games has black borders around screen, its like a compromise for pixel perfect image?
PS - what dosbox version did you use?
PPS - AUDIO - Nuked OPL3 Patch for DOSBox(+Windows build) (SDL1) your dosbox can be pixel perfect AND opl3 perfect if you implement this patch 😎
wrote:Thanks, looks cool, i guess! Is it normal, that most of the games has black borders around screen, its like a compromise for pixel perfect image?
Yes.
wrote:PS - what dosbox version did you use?
Revision 3989.
wrote:PPS - AUDIO - Nuked OPL3 Patch for DOSBox(+Windows build) (SDL1) your dosbox can be pixel perfect AND opl3 perfect if you implement this patch
I believe it would be more correct to merge both the patches into the trunk.