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: |
Description
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... http://vogons.zetafleet.com/viewtopic.php?t=9198
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.
- GUI
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 , 16 years ago
comment:2 by , 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 , 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 , 16 years ago
| Priority: | normal → low |
|---|
comment:5 by , 6 years ago
| Component: | → Graphics: Scalers |
|---|
comment:6 by , 3 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
This has been finally done, now we have scaler plugins.
Well, this "(don't) interpolate source pixels rendered on more than one physical pixel." should be read the other way around...