Opened 16 years ago

Closed 3 years ago

#7646 closed feature request (fixed)

Scalers cleanup

Reported by: SF/zorbid Owned by: sev-
Priority: low Component: Graphics: Scalers
Version: Keywords:
Cc: Game:


ScummVM comes with a lot of scalers (some obsolete), and there are a lot of pending scalers items in the patch/feature request trackers, but no one has been interested in touching this area for a while, so I guess it may be another GSoC candidate...

Here's a summary of what I've read mixed with some suggestions.

I realise that rendering quality is a very subjective issue, so this is of course open for discussion.

AFAICT, scalers can be grouped in the following categories.

- Small device down scaler(s).

- Big screen up scalers (for the SDL backend, on relatively fast hardware), subdivided in - * Blocky (for native VGA feel) - * Edge guessing / smoothing (from SCALE2x-3x to HQ2x). - * Old monitor / TVscreen simulation (for pre-VGA screens and non PC games).

Here are my sugestions:

Idealy, these filters should be resolution and aspect ratio indepedant, stretching the picture up to the screen borders using the native desktop resolution in full screen, or the borders of the window. This would be future proof (I've seen request for a 5x scaler in the tracker, in 3 years someone will request a 10x...).

Regarding aspect ratio, 3 options should IMO be implemented : square pixels (best for Scumm games up to MI2 at least), force 4/3, and stretch to max in both directions. This should please all users AFAICT.

A few scalers of each kind should be implemented, with simple options for optimised performance or quality.

- Simple scaler.

The blocky filter should be the most trivial. Hq/Lq option: (don't) interpolate source pixels rendered on more than one physical pixel. A linear interpolation scaler could fall here too.

- Edge guessing

`Moe` of DOSBox fame wrote an hardware accelerated HQnX inspired by HQ2X, with independant x and y scaling. I don't know how resource intensive it would be if ported to the CPU...

2xPM has been mentioned as a better HQ2X/mame2x. The source seems to be much more simple too (faster to compile?), but it seems to be hardcoded and optimised to 2x, and adapting it for arbitrary resolution probably means a complete rewrite, which won't be easy since the high level rationale would have to be deduced from the source (unless the author is still reachable... the site hasn't been updated since 2005).

- Old screen simulation

HQ: Sev submitted a patch for this, and BlueMSX screen simulation has been mentioned.

Fast: (Soft) scanlines + the current "dot matrix" scaler?

I suppose that most of these are fixed resolution scalers, but resolution independence could be achieved with either a linear or a blocky interpolation pass afterwards, and should IMO look good.


I'd see the GUI for this as a tab with two multiple choice widgets for scaler type (out of the three discussed above) and aspect ratio (maybe a third for the scaling factor?), plus some sub-tabs (or a lower part of the window automatically switching to the relevant options) below to customize each kind of scaler.

What do you guys think of this?

Ticket imported from: #2013428. Ticket imported from: feature-requests/462.

Change History (6)

comment:1 by SF/zorbid, 16 years ago

Well, this "(don't) interpolate source pixels rendered on more than one physical pixel." should be read the other way around...

comment:2 by SF/zorbid, 16 years ago

Sorry to spam this tracker item once more, I'd like to clarify two points: namin and GUI.

The current scalers names are idiosyncratic, and of little help to non technical users, that's why I sugest these name changes. I don't know how you would welcome yet another tab in the GUI. The rationale is that these are enhancements rather than native games settings.

comment:3 by fingolfin, 16 years ago

Clarification: " there are a lot of pending scalers items " -> those are not really pending items, those are all rejected items. We only keep them open, in case users are interested in trying the patches. We have currently no plans at all to add further scalers.

All in all, what you say sounds sensible, and it might indeed be a good GSoC project, or an interesting project for an active (new?) developer. But there are many things to take into considerations. For example, the work by Moe looks cool, but is not directly usable by us, as it relies on a modifed SDL (and env var hacking).

Also, portability issues have to be taken into account. Like with your other proposal: Certainly and interesting task, but also a major and daunting one.

comment:4 by fingolfin, 16 years ago

Priority: normallow

comment:5 by digitall, 5 years ago

Component: Graphics: Scalers

comment:6 by sev-, 3 years ago

Owner: set to sev-
Resolution: fixed
Status: newclosed

This has been finally done, now we have scaler plugins.

Note: See TracTickets for help on using tickets.