#8159 closed patch (outdated)
Aspect ratio (feature wish #654098)
| Reported by: | SF/cigaes | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | Graphics: Scalers |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
This patch is a proof of concept for the aspect ratio feature wish. It adds a ratio800 graphics mode that make the 320×200 games run in 800×600 using a raw pixel duplication algorithm. So it does a ×2.5 scaling horizontally and a ×3 scaling vertically.
In order to make it work, I had to split _scaleFactor into four parts: horizontal and vertical part, and numerator and denominator. I had also to add the x and y arguments to the scaling function, so it can know the fraction part of the target pixel.
This patch only affects SDL backend. Since there is an API change for the scalers, some others backends may be affected, but the change is quite trivial. The only one seems to be gp32, but since I do not have the required environment, I do not want to touch it.
I will try to make a better scaling method, with offset optimizations and antialiasing.
Ticket imported from: #670437. Ticket imported from: patches/264.
Attachments (8)
Change History (23)
comment:1 by , 22 years ago
by , 22 years ago
| Attachment: | ratio800.diff added |
|---|
comment:2 by , 22 years ago
Uh? I *did* check the box and put the file! Let us retry.
Regarding the speed, the change in the common part is quite small. It adds a few divisions, and I think it is really nothing in front of the dialog with the display. The ratio800 scaler itself, altough not optimized at all, is faster that the 3x scaler.
comment:3 by , 22 years ago
Here is an up-to-date version, with a scaler function a bit more optimized, with some anti-aliasing.
comment:4 by , 21 years ago
It no longer applies cleanly to the CVS trunk though (and my quick-and-dirty attempt to do it manually crashes except on fullscreen updates, but that's probably my own fault).
The resulting image looked a bit "chunky" (which, again, may be my own fault). It'd be neat if aspect-ratio correction and smooth scaling could be combined, like they seem to be on the screenshot at http://www.aarongiles.com/scumm/aspect.html
Doing that might require a separate step (and a separate surface?) though...
by , 21 years ago
| Attachment: | scummvm-ratio800-20030617.diff added |
|---|
comment:5 by , 21 years ago
I have updated it to the trunk, and it works at least for Atlantis intro. I attach the patch.
As for the "chunky" image, it is not your fault: the problem is that I do not know the theory behind smooth scaling, so the scaling used here is stupid: each 2x1 pixel rectangle scales to a 5x3 rectangle, where the the 6 pixels on the left and the 6 pixels on the right are the same color as the source pixels, and the 3 pixels in the middle are the mean. Someone who understands smooth scaling should be able to do it whti few problems, I believe.
The worst problem with this patch is that it will only work with SDL back-end, and perharps others backends will not even compile, since I add two parameters (x and y) to the scaler function. But it should be easy to correct for someone that have those back-ends.
comment:6 by , 21 years ago
(SourceForge ate my first attempt at writing this comment when it went down for maintenance. I hope I didn't forget anything this time around.)
I don't know much about smooth scaling either. What I meant was that once the image has been scaled - smoothly or not - you could simply stretch it to the correct aspect ratio. I'm attaching a rough patch to show what I mean. It's very much work-in-progress, and there are a few issues I know about already.
* It only works for the SDL backend. I've made a few untested changes to the OpenGL backend, but that was just to accomodate for the other changes I made.
* The formulas for converting between corrected and uncorrected Y coordinates are scattered all over the place.
* The stretched image looks slightly jagged in some cases. It's usually most noticeable on text and, less importantly, the tv2x scaler. This is because I simply duplicate every fifth line. I'm told bilinear filtering is much better, so I've added a comment about how I think it could be done. Stretching only in one direction should mean the algorithm can be simplified.
* It adds a new buffer, large enough to hold the entire scaled and aspect-ratio corrected screen. With a 3x scaler that's about 1.3 MB, if I'm not mistaken. It should be possible to do the stretching inside the _hwscreen->pixels buffer, but I'm not going to try that until I know the code is working. On the other hand, the buffer is only allocated when the feature is used.
To enable the feature, use the --aspect-ratio command-line option, or "aspect_ratio=true" in the config file, or Ctrl-Alt-a to toggle it.
comment:7 by , 21 years ago
I made a few screenshots:
http://www.update.uu.se/~d91tan/ScummVM/pic1.png http://www.update.uu.se/~d91tan/ScummVM/pic2.png http://www.update.uu.se/~d91tan/ScummVM/pic3.png
pic1.png is just the advmame2x scaler pic2.png is the advmame2x scaler plus aspect-ratio correction pic3.png is the ratio800 scaler
(I got a bit lucky in pic2.png in that the text was distorted in a symmetric way. The stretching artifacts can be a bit more noticeable than this sometimes. Hopefully a better stretching method can improve the worst cases.)
by , 21 years ago
| Attachment: | alt-aspect-ratio2.diff added |
|---|
Cleaned up patch against a June 18 CVS snapshot
comment:8 by , 21 years ago
I do not really like the idea of two successive scalings. With ratio800 or 3x, scummvm is already almost at its speed limit on my box. I have tried to add simple smoothing, using convolution (with 3-1 coefficients).
This version makes two hypothesis on the scaler API: first, that it is safe to enlarge horizontally the destination area of at most one pixel at each side (to have even boundaries); second, that it is safe to peek one pixel beyond the side of the source area. Both hypotheses seems true, since it does not crash nor have fancy colors on the borders; if they are not, it is easy to avoid them, but this will make the code less straightforward and probably a bit slower.
This is not perfect: the whole image seems a bit blury, and the thin fonts are not really nice when segments meets at pixel corners. Bit it is indeed smoother.
comment:9 by , 21 years ago
Well, we did now add the alternate aspect ratio patch to CVS. Did you actually try that, and check the speed on your system? I don't notice a speed difference with and without the additional (bilinear) aspect ratio correction from CVS on my iBook/500.
comment:10 by , 21 years ago
The bilinear filtering can be a bit slow, particularly in the cases where the whole screen is updated, e.g. the SMUSH movies and the Simon games. My computer (450 MHz PIII) will skip frames at the beginning of the Full Throttle intro with advmame2x + aspect-ratio correction, unless I compile with -O2.
At the very least it would be nice if we added options for faster, less exact aspect-ratio correction. We already have the code for it, and even the pixel-doubling method doesn't look *that* bad, I think.
comment:11 by , 21 years ago
| Resolution: | → outdated |
|---|---|
| Status: | new → closed |
comment:12 by , 21 years ago
The fast-but-still-nice filter is now the default, and apparently sufficiently fast for regular use for virtually every supported system. Note that for full performance, enabling optimizations (i.e. -O2 or even -O3) is very important; only then will the full speed be enabled, by inlining the methods (I made them templates on purpose, for maximum speed). On my machine, the optimizer has a huge effect on this and other filters. Same for advmame
by , 20 years ago
| Attachment: | scummvm-ratio800-20041024.diff added |
|---|
up-to-date for the more recent CVS version
comment:13 by , 20 years ago
The official two-pass aspect ratio correction system is too slow for my laptop. Furthermore, my laptor has an exactly 800x600 display. Si I keep updating my 800x600 scaler now and then. Do you mind if I use this patch tracking system to publish it?
comment:14 by , 20 years ago
Well, I don't think we "mind" -- however, I don't think that "publishing" your patch on a closed&rejected patch tracker item is that helpful. It would probably serve people better if you posted it on a website of your own or so...
comment:15 by , 6 years ago
| Component: | → Graphics: Scalers |
|---|
There is no patch attached here. Besides, what you describe regarding the API changes sounds ... odd. I'll reserver any remark on it till i see the actual code.
BTW, regarding "proof of concept": we of course know it is *possible*. The question is, do we want to do it at this time? I think no. On my machine, we already spend 40% and more of the processing time in the GFX backend (SDL + our scalers); adding more to it doesn't sound like a good idea.