ResidualVM Forum
https://forums.residualvm.org/

Increasing GF's Resolution...
https://forums.residualvm.org/viewtopic.php?f=2&t=266
Page 2 of 2

Author:  JohnnyWalker2001 [ Sat Dec 14, 2013 2:33 pm ]
Post subject: 

One thought: Maybe when the resolution was increased, the lighting wasn't been scaled up, as well?

Author:  Nitrus [ Sat Dec 14, 2013 11:02 pm ]
Post subject: 

Not sure, though I don't think that's possible. The lights should be objects just like any other actor/model, without polygonal geometry obviously, but they should at least share traits like position and scale. Bear in mind though that the images were scaled to my laptop's resolution, and then passed through compression for *.jpeg, to make their sizes Web-friendly, some deterioration has probably occurred. Not sure, but maybe even the color profile of my display comes into play (and I have fiddled with that).

Author:  momomomo888 [ Wed Apr 09, 2014 9:00 am ]
Post subject: 

Hi!

Did you just increase the resolution values at gfx_base? or have you upscaled all the pixel screen-relative positions (like in the class TextObject)?

Screen resolution options would be better inside the configuration ini. That seems easy enough... at gfx_base childs' constructor call.

Code:
if (ConfMan.hasKey("width") && ConfMan.hasKey("height")) {
 __gameWidth = ConfMan.getInt("width");
 __gameHeight = ConfMan.getInt("height");
}


And make __gameHeight and __gameWidth ints instead of non static consts.

Author:  JohnnyWalker2001 [ Wed Apr 09, 2014 8:20 pm ]
Post subject: 

I have no idea what you just wrote, buy I hope one of the ResidualVM devs notices soon, as it sounds wonderfully promising.

Author:  klusark [ Thu Apr 10, 2014 12:14 am ]
Post subject: 

momomomo888 wrote:
Hi!

Did you just increase the resolution values at gfx_base? or have you upscaled all the pixel screen-relative positions (like in the class TextObject)?

Screen resolution options would be better inside the configuration ini. That seems easy enough... at gfx_base childs' constructor call.

Code:
if (ConfMan.hasKey("width") && ConfMan.hasKey("height")) {
 __gameWidth = ConfMan.getInt("width");
 __gameHeight = ConfMan.getInt("height");
}


And make __gameHeight and __gameWidth ints instead of non static consts.


We have thought about doing that in the past, but currently there are still too many issues with using a non-standard resolution that we do not want to give any indication that we support it. The most notable bug that will have to be fixed before we add this option is that our software renderer currently does not support any scaling whatsoever.

Author:  momomomo888 [ Thu Apr 10, 2014 7:07 am ]
Post subject: 

klusark wrote:
We have thought about doing that in the past, but currently there are still too many issues with using a non-standard resolution that we do not want to give any indication that we support it. The most notable bug that will have to be fixed before we add this option is that our software renderer currently does not support any scaling whatsoever.


Hey!

Well... I understand software rendering has its limits (and nowadays resolutions!), and I didn't thought about non-standard resolutions when specifying each value separately... but anyway, it could be an opengl only option. So you could always callback to the original resolution when changing to software renderer.

The android (although I'm all for an iPad version) + point&click + deluxe mods have encourage me to try to up the rendering resolution, as it seems Nitrus has already done.

But it's my first time looking around the RVM code, so I'm a bit lost.. At first I didn't understand why the textures looked pixelated no matter if I was using the deluxe pack or original assets. I looked at the code searching if the texture filtering used was GL_NEAREST, but it's only used like that on fonts, and movies surfaces.. And then I realized it was the rendering resolution...

I'll try to make it work :) but although there is no official support, any indication of where to touch would be greatly appreciated.

Edit: Yep... as you said... it's already implemented, just changing the g_driver->setupScreen on grim.cpp attached to a par of keys inside the ini file. If I don't find the keys I just set 640x480. There is no need to mess with the rest of classes, as I thought at first.

With the point&click mod have a few issues though... the inventory background blackbox is smaller than it should and clicking to walk around returns in a wrong path. I tried to see the walking boxes on debug mode, but It doesn't seem to show :?

Hovering and clicking on dialogs/objects works perfectly.

Edit2: Ok, everthing seems to run now with the P&C mod also. I needed to change getBoundingBoxPos() (for text positioning), rayCast() (for walking) and worldToScreen() (i'm not sure where it's used) methods to apply the _scalingH/_scalingW to their winX/winY size.

I'm not used to GIT, so I'll post the code changes here or on tobiaspfaff's topic

Page 2 of 2 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/