Opened 17 years ago

Closed 16 years ago

Last modified 12 months ago

#8159 closed patch (outdated)

Aspect ratio (feature wish #654098)

Reported by: SF/cigaes Owned by:
Priority: normal Component: Graphics: Scalers
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)

ratio800.diff (14.7 KB ) - added by SF/cigaes 17 years ago.
ratio800_2.diff (14.6 KB ) - added by SF/cigaes 17 years ago.
scaler a bit more optimized
scummvm-ratio800-0.4.0.diff (14.3 KB ) - added by SF/cigaes 17 years ago.
up-to-date version for 0.4.0
scummvm-ratio800-20030617.diff (14.4 KB ) - added by SF/cigaes 16 years ago.
alt-aspect-ratio.diff (20.6 KB ) - added by eriktorbjorn 16 years ago.
Patch against a June 18 CVS snapshot
alt-aspect-ratio2.diff (21.9 KB ) - added by eriktorbjorn 16 years ago.
Cleaned up patch against a June 18 CVS snapshot
scummvm-ratio800-20030620.diff (15.3 KB ) - added by SF/cigaes 16 years ago.
with smoothing
scummvm-ratio800-20041024.diff (20.4 KB ) - added by SF/cigaes 15 years ago.
up-to-date for the more recent CVS version

Download all attachments as: .zip

Change History (23)

comment:1 by fingolfin, 17 years ago

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.

by SF/cigaes, 17 years ago

Attachment: ratio800.diff added

comment:2 by SF/cigaes, 17 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.

by SF/cigaes, 17 years ago

Attachment: ratio800_2.diff added

scaler a bit more optimized

comment:3 by SF/cigaes, 17 years ago

Here is an up-to-date version, with a scaler function a bit
more optimized, with some anti-aliasing.

by SF/cigaes, 17 years ago

Attachment: scummvm-ratio800-0.4.0.diff added

up-to-date version for 0.4.0

comment:4 by eriktorbjorn, 16 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 SF/cigaes, 16 years ago

comment:5 by SF/cigaes, 16 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.

by eriktorbjorn, 16 years ago

Attachment: alt-aspect-ratio.diff added

Patch against a June 18 CVS snapshot

comment:6 by eriktorbjorn, 16 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 eriktorbjorn, 16 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 eriktorbjorn, 16 years ago

Attachment: alt-aspect-ratio2.diff added

Cleaned up patch against a June 18 CVS snapshot

by SF/cigaes, 16 years ago

with smoothing

comment:8 by SF/cigaes, 16 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 fingolfin, 16 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 eriktorbjorn, 16 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 fingolfin, 16 years ago

Resolution: outdated
Status: newclosed

comment:12 by fingolfin, 16 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 SF/cigaes, 15 years ago

up-to-date for the more recent CVS version

comment:13 by SF/cigaes, 15 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 fingolfin, 15 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 digitall, 12 months ago

Component: Graphics: Scalers
Note: See TracTickets for help on using tickets.