Scalers
Moderator: ScummVM Team
-
- Posts: 18
- Joined: Tue May 30, 2006 1:16 pm
Scalers
hi,
as everybody knows, there are different scalers with different abilities - but especially with tft displays it would be nice to select a scaler and a screen resolution, so that scummvm calculates a magnification and aspect ration corresponding to the existing resolution and selected scaler
as everybody knows, there are different scalers with different abilities - but especially with tft displays it would be nice to select a scaler and a screen resolution, so that scummvm calculates a magnification and aspect ration corresponding to the existing resolution and selected scaler
- Vinterstum
- ScummVM Developer
- Posts: 580
- Joined: Sun Oct 16, 2005 6:59 am
-
- Posts: 18
- Joined: Tue May 30, 2006 1:16 pm
- Vinterstum
- ScummVM Developer
- Posts: 580
- Joined: Sun Oct 16, 2005 6:59 am
-
- Posts: 70
- Joined: Wed Jan 25, 2006 5:27 pm
It's entirely possible to combine both. Richard Bannister has a shell that does this for his emulator ports to Mac OS X. You can resize a window or resize to fullscreen with any scaler...and it all looks top notch.
Ideally you'd use an HQ, SuperSaI, whatever scaler to get the most reasonable detail level for your monitor...then use OpenGL to scale that image to fill the screen.
Like I said...Bannister does this and allows you to get fullscreen on any scaler...
Ideally you'd use an HQ, SuperSaI, whatever scaler to get the most reasonable detail level for your monitor...then use OpenGL to scale that image to fill the screen.
Like I said...Bannister does this and allows you to get fullscreen on any scaler...
-
- Posts: 70
- Joined: Wed Jan 25, 2006 5:27 pm
- eriktorbjorn
- ScummVM Developer
- Posts: 3549
- Joined: Mon Oct 31, 2005 7:39 am
Wouldn't that risk running afoul of the texture size limit? Or is that solved by "rendering that as a quad"? I'm afraid I don't know much about OpelGL or its terminology.gord wrote:its just as simple as sending the display data to a texture and rendering that as a quad on the screen.
Not really. There are other backends than the SDL one. There even used to be an OpenGL renderer, but all it offered was one more 2x scaler (and a pretty mediocre one at that, if you ask me). No one wanted to maintain it, so it fell into disrepair and was removed.gord wrote:scummvm seems to be more of a 'use sdl or lump it' dealy though
- Vinterstum
- ScummVM Developer
- Posts: 580
- Joined: Sun Oct 16, 2005 6:59 am
most graphics cards these days have a fairly high texture limit, even if they don't a large texture can be cut up into smaller textures nice and quickly by using glPixelStorei. i had to do that because my graphics card doesn't support non power of two textures and the mega-drive runs at 320x240.
a quad is just a polygon by the way, nothing epecial, its just easyer to handle than two triangles![Wink ;)](./images/smilies/icon_wink.gif)
a quad is just a polygon by the way, nothing epecial, its just easyer to handle than two triangles
![Wink ;)](./images/smilies/icon_wink.gif)
Splitting the data up into multiple quads was exactly what the old OpenGL scaler did, and it caused a visible cut between the two parts of the pixel data. Given the way interpolation works, that's not really a surprise either.
Anyway: If somebody was to write a proper OpenGL based backend, and was definitely going to maintain it, and if it was written in a clean and not-so-buggy fashion -- we'd consider it for inclusion.
Note that it would possibly be based on the current SDL backend -- code sharing is easily possible, as demonstrated by the WinCE and Symbian backends which both are based on the SDL one).
However, since we have had bad experiences with this, we'll be picky. In particular, forget about any "Hey I've whipped this OpenGL hack up in 20 minutes and it works quite OK in the 2 cases I tested it in" patches, they'll be rejected![Smile :)](./images/smilies/icon_smile.gif)
Anyway: If somebody was to write a proper OpenGL based backend, and was definitely going to maintain it, and if it was written in a clean and not-so-buggy fashion -- we'd consider it for inclusion.
Note that it would possibly be based on the current SDL backend -- code sharing is easily possible, as demonstrated by the WinCE and Symbian backends which both are based on the SDL one).
However, since we have had bad experiences with this, we'll be picky. In particular, forget about any "Hey I've whipped this OpenGL hack up in 20 minutes and it works quite OK in the 2 cases I tested it in" patches, they'll be rejected
![Smile :)](./images/smilies/icon_smile.gif)
I guess you could try to "cut" the parts on a per-game basis where a natural boundary occurs, like between inventory/verb area and game area? would still be visible during fullscreen events and when the mouse passes over it thoughfingolfin wrote:Splitting the data up into multiple quads was exactly what the old OpenGL scaler did, and it caused a visible cut between the two parts of the pixel data. Given the way interpolation works, that's not really a surprise either.
- eriktorbjorn
- ScummVM Developer
- Posts: 3549
- Joined: Mon Oct 31, 2005 7:39 am
That doesn't sound like a very good idea to me. Anyway, I'm fairly sure I've seen examples of programs that do the texture cutting trick without any visible seams. (I even thought someone fixed that bug in the ScummVM OpenGL renderer before it was removed, but I could very well be mistaken about that.)clem wrote:I guess you could try to "cut" the parts on a per-game basis where a natural boundary occurs, like between inventory/verb area and game area? would still be visible during fullscreen events and when the mouse passes over it though