Increasing GF's Resolution...

Discussions regarding the development of the mod "Grim Fandango Deluxe"

Moderator: ScummVM Team

User avatar
JohnnyWalker2001
Posts: 405
Joined: Mon Oct 16, 2006 1:27 pm
Location: London, UK

Post by JohnnyWalker2001 »

One thought: Maybe when the resolution was increased, the lighting wasn't been scaled up, as well?
Nitrus
Posts: 177
Joined: Wed May 18, 2011 9:49 am

Post by Nitrus »

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).
momomomo888
Posts: 7
Joined: Tue Feb 25, 2014 8:24 pm

Post by momomomo888 »

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: Select all

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.
User avatar
JohnnyWalker2001
Posts: 405
Joined: Mon Oct 16, 2006 1:27 pm
Location: London, UK

Post by JohnnyWalker2001 »

I have no idea what you just wrote, buy I hope one of the ResidualVM devs notices soon, as it sounds wonderfully promising.
klusark
Posts: 23
Joined: Tue Mar 27, 2012 11:12 pm

Post by klusark »

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: Select all

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.
momomomo888
Posts: 7
Joined: Tue Feb 25, 2014 8:24 pm

Post by momomomo888 »

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
Post Reply