Ant_222 wrote:Thank you very much, Yesterplay80. I have found out the same thing last evening. In addition to the conditional compilation directive, something has changed that made some hunks apply with an offset, which I will try to fix as well. It would be trivial if I knew SVN better and could use its full power by storing my patch in it.
Excellent! Can you teach me how to do it? The only way I see is to get a non-conflicting revision (e.g. 4055), apply the patch (with offset but without conflicts), update conditional compilation in sdlmain.cpp with C_DDRAW, then get the latest (conflicting) revision, apply the patch (with conflicts), replace sdlmain.cpp with the modified version from the previous revision and make a fixed patch using svn -diff. But there ought to be a simpler method. Did you use some graphical merge utility?Yesterplay80 wrote:The offset is already fixed in the file I provided, it applies cleanly with r4063 now.
Are you certain your drivers are recognised and working, and that the Hardware manager shows no malfunctioning devices?Imagine multiple tearing lines on the same screen; that's exactly what I get, so it's all juddery and jumpy. We're talking an intel G41 Express on top of WinXP, everything up to date.
Well, I don't get any tearing with my patch either, and by more work to do I meant that high load aggravates the bug or problem, which must be there in the first place. When my patch begins to stutter on my PC, it does so gracefully and without many tearing lines.Now, there's this source port called "Chocolate Doom" that tries to do something similar to what this patch does (similar as far as the intended end result is concerned, of course) and I don't get this type of tearing at all, meaning the "more work to do" part of the equation could still potentially be improved.
That's a different kettle of cod. It has, for example, native support for hardware-accelerated integer scaling with independent horizontal and vertical scaling factors—just what the pixel-perfect mode needs!It's being done with SDL2, though, so I'm not getting my hopes up
It is the first time I hear of a 3:2 aspect ratio in MS-DOS. What game uses it? Edit: Ok, 720x480 is 3:2.DosDaddy wrote:Is there a way to change the default aspect ratio ECE will correct a non-square pixel 3:2 image to?
If I do not misunderstand you, then correcting from 200 to 240 and to 267 implies non-integer scaling factors: 1.2 and 1.33 respectively—something that the Pixel-perfect patch is designed never to do so as to avoid interpolation artefacts. Can you specify a game and post a screenshot (or textshot) of the console output, where the patch shows its scaling parameters?The value currently in place seems a bit overkill, effectually leaving you with a 320x267 image when AR-correcting for 320x200, whereas mode 13h on a CRT would have almost always resulted in a 4:3 output back in the day (320x240).
320:200 ->[4x5]-> 1280:1000 = 1.28 (vs. the ideal 1.33).
I fear I do not fully understand you. With aspect=true the current version of the patch corrects the image as closely to 4:3 as possible. If you clarify your proposal with specific (numeric) examples, then I will consider it.Ideally this setting should be configurable to the satisfaction of the user, but a simple, hard-coded, alternative 4:3 mode would be enough for this dog.
Ant_222 wrote:If I do not misunderstand you, then correcting from 200 to 240 and to 267 implies non-integer scaling factors: 1.2 and 1.33 respectively—something that the Pixel-perfect patch is designed never to do so as to avoid interpolation artefacts. Can you specify a game and post a screenshot (or textshot) of the console output, where the patch shows its scaling parameters?
Ant_222 wrote:In order to get an ideal 4:3 image with a 320:200 game, the Pixel-perfect patch needs an area of at least 1600x1200 pixels. With my monitor of 1680:1050 I get an almost-perfect correction to
- Code: Select all
320:200 ->[4x5]-> 1280:1000 = 1.28 (vs. the ideal 1.33).
I see:Notice the native resolution is 1440x900 and I'm going from windowed to fullscreen and back.
Available area: 1424x858
That's right, but you do not have 1600x1200, so the patch cannot reproduce the aspect ratio perfectly. Notice that it must use integer scaling factors in order to keep the image pixel-perfect. It therefore chose 3 and 4 as horizontal and vertical scales respectively, which resulted in a pixel aspect ratio (PAR) of 4:3 or 1.33, vs. the target (perfect) PAR of 6:5, or 1.2. What should you expect (or desire) my patch to do instead? If you would prefer to have square pixels (unity PAR), just disable aspect-ratio correction in the config file.Here's the thing: a 320x200 picture AR-corrects to 4:3 perfection at 1600x1200, but proportionally downscale that 1600x1200 to 320x... and you get 320x240
Ant_222 wrote:I suppose the smaller figure is the size of your window, because in fullscreen the available area should be 1440x900, but I did not find it in the screenshot...
Ant_222 wrote:That's right, but you do not have 1600x1200, so the patch cannot reproduce the aspect ratio perfectly. Notice that it must use integer scaling factors in order to keep the image pixel-perfect. It therefore chose 3 and 4 as horizontal and vertical scales respectively, which resulted in a pixel aspect ratio (PAR) of 4:3 or 1.33, vs. the target (perfect) PAR of 6:5, or 1.2. What should you expect (or desire) my patch to do instead? If you would prefer to have square pixels (unity PAR), just disable aspect-ratio correction in the config file.
Nearest-neighbor interpolation (openglnb and surfacenb)) will give you that "uneven distribution of pixels." Pixel-perfect mode, however, avoids it like the plague and keeps the pixels crisp and clear in all circumstances.I think I figured out the problem here; you're looking at this from a purely theoretical perspective, and I perhaps from a slightly more practical one. Technically, though, since it's not possible to apply pixel-perfect 4:3 aspect ratio correction to 320x200 without at least 1600x1200, anything short of that will inevitably result in an uneven (imperfect) distribution of pixels, causing some rows to look thicker than others, and there's no fixing that at lower resolutions irrespective of the mathematical accuracy of the scaling factors involved.
This is not possible in pixel-perfect mode because the ratio of 720 to 200 is not an integer. But go ahead and try one of the nearest-neighbor modes! They will give you the perfect aspect ratio at the expense of regular pixels.Ultimately, though, what I'm looking to get out of 320x200 is 960x720 rather than 960x800, as it so happens to be right now, but it's likely that this patch is designed to work strictly under certain parameters (integer everything) and this alternative mode of correction may not be viable/desirable or simply beyond the scope of the project.
Have you excluded possible problems with the graphics driver and/or SDL1's interaction with it? If you can compile C programs, you might try my non-graphical scaling benchmark with different optimisation levels to isolate your CPU performance with regard to pixel-perfect scaling and compare it with those of several other users, including me.DosDaddy wrote:Alright, sorry about the delay, but I finally got around testing this on other computers and the results pretty much confirm what you had already suggested; my CPU's just aren't up to the task.
I think that the P4 670 should be faster than my AMD A4-4300, whereas I failed to reproduce your performance problem. Strange...DosDaddy wrote:Chocolate Doom's scaling works as fast as it does because everything's handled in hardware via SDL2, but there's no escaping that even the venerable P4 670, though still very usable, can't keep up with that much passing of time.
Thank you for the feedback. The scaling algorithm itself is very simple and primitive, but it was quite difficult for me to integrate it into DOSBox. I feel chary of doing the same for some unofficial SDL2 fork because I fear that all my work will be lost because of incompatibility with some major modification to the official DOSBox. I am mickle glad and grateful that my original patch lives on.DosDaddy wrote:It's a shame, though, because your scaler does something that a lot of emulators desperately need and actually does it quite well :/
Users browsing this forum: No registered users and 1 guest