Scalers

Threepwood · Post by **Threepwood** » Mon Jul 17, 2006 10:00 am

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

Vinterstum · Post by **Vinterstum** » Mon Jul 17, 2006 12:46 pm

That's something that would only be useful with, say, an OpenGL scaler (see past discussions). The current scalers need to scale to 2x or 3x, they can't do arbitrary resolutions.

Threepwood · Post by **Threepwood** » Tue Jul 18, 2006 8:50 am

I don`t understand, what this has to do wiht opengl

Vinterstum · Post by **Vinterstum** » Tue Jul 18, 2006 9:10 am

Just that arbitrary scaling is something we'd use an OpenGL backend for, to take advantage of hardware acceleration etc.

gord · Post by **gord** » Fri Jul 21, 2006 6:12 am

to put it simply, scaling increases the size of a window by 2x or 3x. opengl can make a window any size you want.

rented mule · Post by **rented mule** » Mon Jul 24, 2006 3:35 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...

fingolfin · Post by **fingolfin** » Mon Jul 24, 2006 5:59 pm

Sure. Of course it is possible to do that, nobody denied that. Virtually everything is possible in IT, as long as you put enough talent and other resources at solving the problem.

The question just is, does one want to do it, and does the required effort warrant the result.

rented mule · Post by **rented mule** » Mon Jul 24, 2006 6:43 pm

fingolfin wrote:...and does the required effort warrant the result.

IMO...yes.

But that's just me.

gord · Post by **gord** » Mon Jul 24, 2006 8:58 pm

its not really hard to do, iv impimented an opengl version of the mega-drive emulator gens from an sdl only version. its just as simple as sending the display data to a texture and rendering that as a quad on the screen.

scummvm seems to be more of a 'use sdl or lump it' dealy though

Post by **eriktorbjorn** » Mon Jul 24, 2006 9:44 pm

gord wrote:its just as simple as sending the display data to a texture and rendering that as a quad on the screen.

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:scummvm seems to be more of a 'use sdl or lump it' dealy though

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.

Vinterstum · Post by **Vinterstum** » Tue Jul 25, 2006 1:01 am

Really, it's just an issue of a dev dedicating enough time to implement it, and most importantly -maintain- it. Personally I considered it at one time, but decided to use whatever little free time I have these days to other things (kyra/kyra2). Most of us are in a similar position, I suspect

.

gord · Post by **gord** » Tue Jul 25, 2006 1:28 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

fingolfin · Post by **fingolfin** » Tue Jul 25, 2006 9:21 am

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

clem · Post by **clem** » Tue Jul 25, 2006 11:35 am

fingolfin 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.

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

Post by **eriktorbjorn** » Tue Jul 25, 2006 11:49 am

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

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.)