First post, by Elamaton
I'm in the middle of a project that involves capturing gameplay video from several different emulators (MAME, DOSBox, WinUAE etc.) and processing it into a form that's fit to edit in a professional application (Final Cut Pro in my case). To this end, I've done some research into the scaling methods and common aspect ratios that are used in each of the emulators, and found DOSBox a bit lacking.
(EDIT: the actual motivation behind this post is to advocate the addition of Normal4x - if all I wanted to do was to edit videos in Final Cut, then I'd just do all the scaling with Final Cut and leave DOSBox in peace. But I'm a gamer, first and foremost. 😀 The former paragraph just outlined how I came across the issue originally.)
To me, it seems that MAME is the smartest citizen in scalingland. By default, it does automatic 4:3 aspect correction (or 3:4 with vertical games), which has its equivalent in dosbox.conf (aspect = true). But MAME's strength lies in the very sexy prescale option that presumably uses a simple nearest neighbor method to double/triple/quadruple/etc. the horiz/vert pixel counts of the image before the "real" scaling for the aspect correction is done. That particular scaling is apparently bilinear due to the slight blurriness involved, although I haven't found it explicitly mentioned anywhere.
By reading threads concerning scaling and aspect ratios here at Vogons, I've come to assume that DOSBox's Normal2x and Normal3x scalers basically do nearest neighbour pixel dimension doubling/tripling. With aspect=true, some bilinear scaling is thrown to the mix for the final aspect-corrected image. (Correct me if I'm wrong with some of that.)
I've done some tests with still images captured from DOSBox. The relevant lines from dosbox.conf:
output=ddraw
windowresolution=1280x960
aspect=true
scaler=[none, normal2x, normal3x]
I took a screengrab with IrfanView of each of the different scalers, from the exact same image in Tyrian, the original resolution being 320x200. Scaler=none was extremely blurry (as expected), normal2x was sharp, and normal3x was even sharper, being the best option available.
The inclusion of Normal4x has been requested several times in various threads. I'm supporting that cause as well. The reason is really very obvious: 3x was sharper than 2x, and 4x would be sharper than 3x when used on any large modern LCD's with native resolutions starting from 1280x1024.
I tested this in practice using VirtualDub and its nifty filter chaining feature. I took the original 320x200 screenshot and first resized it to 300% relative (equivalent to Normal3x) with the "Nearest neighbor" option, and then added a "Bilinear (interpolation only)" scaling to 1280x960, which also did the aspect correction. It looked identical to the aspect-corrected Normal3x screenshot from DOSBox, confirming the validity of the experiment, so I took the next step.
I changed the NN scaling in VDub to 400% (equivalent to a non-existent Normal4x) and left the later bilinear scaling alone. The resulting image was clearly sharper and more pleasing to the eye than the Normal3x image. I'm certain that if Normal4x did exist, it would look identical to the simulated image in VirtualDub, because that's exactly what happens with Normal3x and Normal2x (tested that one as well).
This is a completely obvious conclusion. Quality-wise, 4x > 3x > 2x, after the bilinear aspect correction step. The less difference there is in the resolutions of the "source" image (after pixel doubling/tripling/quadrupling) and the final bilinearly aspect-corrected image, the better the quality will be. Scaling 960x600 to 1280x960 will NOT look as good as scaling 1280x800 to 1280x960.
Given this fact, I don't really understand why Normal4x doesn't already exist. I'm not a C/C++/ASM coder, but I can't imagine how it would be hard for the DOSBox coding wizards to implement, given the existence of the other Normal scalers already to build upon. (Yeah, yeah, "Why don't YOU do it if it's that easy", I know. But seriously.)
The need for Normal4x exists. It has been frequently requested. Many people would honestly prefer it to anything now available. The image quality advantage is clear. Other proposed scaling methods (hwscale etc.) either don't do the job (i.e. don't keep the pixels relatively pristine) or have drawbacks (like increased CPU usage).
Developers, I implore, nay, BEG you to implement it in a near-future release.
