Scalers

[eriktorbjorn]

I think the main technical problems with non-integer scalers (i.e. ones that do not scale exact 2, 3, ... times) are:

• The mouse cursor handling, which is already overly complicated. (Some games use a different scale and palette for the cursor than they do for the rest of the game.)
• Partial screen updates. We generally don't update the entire screen at once, and there could be glitches in the seams between the different areas. (There were a couple of such glitches after we added aspect-ratio correction.)

I don't know if these problems will be easy or hard to overcome, or even if they will be problems at all.

Personally, I'm waiting for one of those who've said that it's worth the trouble to submit a patch.

[gord]

I don't see why one has to go through OpenGL to get the image stretched properly to fullscreen. As I see it this is a 2D-2D operation and relying on (potentially) 3D APIs does not feel right. There are still ways to do 2D gfx properly, as scummvm demonstrates with SDL.

Of course, supporting arbitrary scalers or not in scummvm is another issue, given especially the complexity of an arbitrary upsampling/downsampling filter. Complexity in terms of computational complexity but also in terms of image processing algorithms. Fortunately though, we could use resampling filter kernels from other open source projects (VirtualDub comes to mind).

opengl stands for open graphics library, it doesn't have to be 3d, it just accelerates the whole thing. stretching an image to a non integer size (especially if you want it to look good with linear/cublic interpolation) takes up a lot of cpu cycles, especially with something large like comi at 3x. essentially by using opengl though sdl you are uploading the surface to a texture, like you normally would (uploading small chunks of data is possible for dirty rectangle updating, zsnes uses it for a fact), its just that you get to stretch it to whatever size you want without a performance impact.

That sounds overly optimistic to me. I've encountered several OpenGL applications where I've gotten nothing but a white window instead of the intended graphics, and they were probably running at 640x480 or 800x600 or something like that. I would guess the textures they were using were still a lot smaller than 2048x2048.

now thats an old card that actually sounds to me like texture compression which isn't supported / texture bitdepths, but even then you can retrieve the max texture size from opengl and make the textures fit, its not a guessing game.


and i don't know if its worth the trouble, it depends on scummvm's current infrastructure, personally i think the current system is fine but an opengl implientation would be the sugar on top.

[Vinterstum]

I don't see why one has to go through OpenGL to get the image stretched properly to fullscreen. As I see it this is a 2D-2D operation and relying on (potentially) 3D APIs does not feel right. There are still ways to do 2D gfx properly, as scummvm demonstrates with SDL.

Of course, supporting arbitrary scalers or not in scummvm is another issue, given especially the complexity of an arbitrary upsampling/downsampling filter. Complexity in terms of computational complexity but also in terms of image processing algorithms. Fortunately though, we could use resampling filter kernels from other open source projects (VirtualDub comes to mind).

I guess it boils down to the fact that any platform that would be powerful enough to do realtime arbitrary scaling on the CPU, will also be OpenGL compatible . So there's really no reason to NOT use OpenGL for this. The only exception I could see (of a platform powerful enough, but with no OpenGL) is something like the XBox, and we don't have an official port for that anyway.

Handhelds and similar won't have a high enough resolution for this to be an issue for a long time, and even they are starting to get 3D hardware (the newest Dell Axim, for example). Not that you need 3D hardware for OpenGL, but you get my meaning .

[rented mule]

can you tell me why there's a black border around, say, Monkey Island 1 at 3x

Cause 320x200 X3 = 960x600... hence the black borders you get on your 1280x1024 screen mode. That's the way fixed scalers work, no voodoo magic behind it. 'nuff said.

Exactly...that's what I wanted to hear...why fingolfin is trying to make me believe otherwise is beyond me. I want to hear those words from fingolfin himself.

[sev]

why fingolfin is trying to make me believe otherwise is beyond me. I want to hear those words from fingolfin himself.

Contribute to ScummVM as much code as Fingolfin did, and then come back with your statements. Until that go and read forum rules, especially Forum Rule #4.


Eugene

PS. The reason for black borders in your case was explained in this thread already. And I here do not have them. Your fault.

[Vinterstum]

Exactly...that's what I wanted to hear...why fingolfin is trying to make me believe otherwise is beyond me. I want to hear those words from fingolfin himself.

You make less and less sense. What on earth are you trying to say that fingolfin is 'making you believe'? That ScummVM somehow already does arbitrary resolutions? If so I suggest you re-read his posts.

[rented mule]

why fingolfin is trying to make me believe otherwise is beyond me. I want to hear those words from fingolfin himself.

Contribute to ScummVM as much code as Fingolfin did, and then come back with your statements. Until that go and read forum rules, especially Forum Rule #4.


Eugene

PS. The reason for black borders in your case was explained in this thread already. And I here do not have them. Your fault.

I have utmost respect for fingolfin...I just want to understand his reasoning. I'm telling him there's a black border on a certain resolution with a certain scaler...there's no alternate scaling that stretches the image to fit the screen which is what fingolfin is claiming (he says the OS and his modern display do the scaling)...it's simply untrue.

I'm not being mean or disrespecting anyone. I just want answers. Disagreeing with someone isn't against Forum Rule #4 or any rule for that matter.

[rented mule]

Exactly...that's what I wanted to hear...why fingolfin is trying to make me believe otherwise is beyond me. I want to hear those words from fingolfin himself.

You make less and less sense. What on earth are you trying to say that fingolfin is 'making you believe'? That ScummVM somehow already does arbitrary resolutions? If so I suggest you re-read his posts.

He's making me believe ScummVM looks terrific on a 24" screen. It's already looking pretty bad on 20" screens.

I'll check it out on a 24" display soon enough though.

[LordHoto]

(he says the OS and his modern display do the scaling)...it's simply untrue.

Maybe it works on his OS and his display, but not on yours?

[rented mule]

(he says the OS and his modern display do the scaling)...it's simply untrue.

Maybe it works on his OS and his display, but not on yours?

Ok...have I stepped into the Twilight Zone? Why did this thread get created in the first place? And why are people talking about an OpenGL solution? If the OS does all the scaling or if the display does all the scaling (or both) then why is there a bunch of people (including ScummVM devs) talking about an OpenGL solution? Obviously the problem is solved.

Thanks.

[gord]

to get that kind of effect you either have to have a new Mac, windows Vista or linux running xgl(or aiglx)/compiz. an opengl solution meens the problem is fixed for 95% of people, including ports to consoles that have an opengl implimentation. just leaving it be meens the problem is solved for 10% of people (maybe).

the real discussion should stick to the facts instead of idle bickering. is it possible? will it work for a reasonable number of people? is it worth it?

[LordHoto]

to get that kind of effect you either have to have a new Mac, windows Vista or linux running xgl(or aiglx)/compiz. an opengl solution meens the problem is fixed for 95% of people

at least with Xorg on Linux I've got always a streched screen in fullscreen with my 1280x1024 tft, without any black borders, the scaling isn't too good, but it *works* at least. Then again I don't use fullscreen mode often.

is it possible?

why shouldn't it?

will it work for a reasonable number of people?

It'll work for those with OpenGL implementations if you speak about an OpenGL based system.

is it worth it?

I'm fine with the current system atm (a neat simple 4x scaler would be nice though), so I don't see any reason to work on it myself, but if you think it's worth it, you can always start working on it and if the code isn't too ugly and not too hacky and works well I don't see any reason why it would be rejected. I've to say that I wrote a quick OpenGL based renderer for ScummVM once, which worked quite well, not that optimized though.

[eriktorbjorn]

(a neat simple 4x scaler would be nice though),

The trivial, non-smoothing 4x scaler is very easy to add, of course. I thought it would be possible to use the current "AdvMame" code to do 4x scaling, but for whatever reason it glitched/crashed a lot. I think there is a HQ4x scaler, but I didn't even look at it.

The changes to the SDL backend are pretty trivial, too, but the GUI would take a bit more work, since it isn't scaled the same way as the rest of the game. The fonts are not scaled, and while this is a feature, not a bug, they do look ridiculously small when used at 1280x960. The classic theme looked particularly ridiculous, with tiny fonts and a gigantic mouse cursor. We would probably also need a "1.25x" scaler for the modern theme's cursor.

Note that I do not have any plans for adding 4x scalers, I just wanted to see what would be needed to do so.