Grimrock

Changing the render quality from high to low causes the game to render an image that is bigger than the screen, which leads to all the buttons being inaccessible (making it impossible to revert). The only way to recover from this is to manually edit the CFG file.

Screen Capture [1920x1080]

The screen in question has a resolution of 1920x1080.

Also, changing the mode from fullscreen to windowed results in a window that always uses the full height of the screen, even when the resolution is clearly inferior (ex., setting windowed resolution to 1024x768 when the desktop resolution is 1920x1080 results in a 1440x1080 window). Since there is no way to interactively resize the game window, this makes it impossible to have a window that takes up only part of the screen. Additionally, in this window, the buttons to apply new options also (sometimes) appear "outside" of the screen, making it impossible to change settings.

Both bugs might be related to the fact that the system uses a high-DPI screen, with text scaling set to 150% in Control Panel > Appearance and Personalization > Display. The game seems to be (incorrectly) applying this setting to its own screen buffer.

Naturally, the game should render things at the correct size, but at the very least there should be a way to apply settings without clicking the "Apply" button (ex., pressing return), or the "Apply" button should be positioned in a better place (ex., top left of the window).

Could you try turning off dpi scaling to see if it helps, please?

RFC3251 wrote:Changing the render quality from high to low causes the game to render an image that is bigger than the screen, which leads to all the buttons being inaccessible (making it impossible to revert). The only way to recover from this is to manually edit the CFG file.

Screen Capture [1920x1080]

The screen in question has a resolution of 1920x1080.

Also, changing the mode from fullscreen to windowed results in a window that always uses the full height of the screen, even when the resolution is clearly inferior (ex., setting windowed resolution to 1024x768 when the desktop resolution is 1920x1080 results in a 1440x1080 window). Since there is no way to interactively resize the game window, this makes it impossible to have a window that takes up only part of the screen. Additionally, in this window, the buttons to apply new options also (sometimes) appear "outside" of the screen, making it impossible to change settings.

Both bugs might be related to the fact that the system uses a high-DPI screen, with text scaling set to 150% in Control Panel > Appearance and Personalization > Display. The game seems to be (incorrectly) applying this setting to its own screen buffer.

Naturally, the game should render things at the correct size, but at the very least there should be a way to apply settings without clicking the "Apply" button (ex., pressing return), or the "Apply" button should be positioned in a better place (ex., top left of the window).

Well known and reported problem since vanilla version 1.1.3 (see viewtopic.php?f=12&t=4567, or viewtopic.php?f=12&t=4914 or viewtopic.php?f=12&t=4649 or many more). People should keep on reporting this bug, if enough people will report this problem the priority in the fixing queue will hopefully (?) rise.

Badhabit, I just read a couple of posts that you have written during the holidays. The way I understand your problem is that if you start grimrock in a windowed resolution taller than the desktop resolution, part of the window will be cut off. Is this correct?

petri wrote:Badhabit, I just read a couple of posts that you have written during the holidays. The way I understand your problem is that if you start grimrock in a windowed resolution taller than the desktop resolution, part of the window will be cut off. Is this correct?

hi petri, that was a try to analyze the underlying reason for the multiple times reported "can't access the lower part of the option menu" problem (now around a dozend reports with pretty different setups). This multi-monitor setup (report viewtopic.php?f=12&t=4649) was leading me to the guess that there is a mis-detection problem. Can it be that you use the a "native" autodetected monitor resolution on scaling even in windowed mode (see viewtopic.php?f=12&t=4649&start=20#p49198)? In such cases LOG should just rely on the user selected windowsize and scale to to it, no more fancy autodetection stuff. In general, I think this problem would be gone once and for all if LOG would support (stupid) downscaling below 1024x768 or at least allows scrolling of the option menu like the load menu. Hope a solution of anykind will be included in the coming 1.3.7. patch

There is no autodetetection or scaling of the window contents. We just open a window as specified by the config file and render the 3d scene to it. The gui is rendered on top the of the scene pixel-perfect with 1:1 mapping between texels and pixels. Dialogs are centered in the viewport.

Please note that getting pixel perfect rendering out of d3d9 is actually harder than rendering 2d elements that scale up & down with the resolution. To achieve pixel-perfect rendering we have to care things such as the discrepancy of centers of pixels and texels (an unfortunate feature of DirectX before version 10) and carefully authoring the graphics so that they fit to the screen and look good in all supported resolutions.

Why do we jump through all these hoops? One reason is that we care about image quality a lot, meaning that we wanted to preserve Juho's high detail art. Upscaling & downscaling bitmaps always results in noticeable decrease in image quality. If you compare grimrock's gui graphics with some other games that have scaled guis you'll notice that grimrock's gui is much crisper. This is because texture filtering always blurs the image (except when the scaling is disabled by carefully setting up texture and screen coordinates like we do).

Rendering 1:1 means that there is a certain minimum resolution that is required to fit the graphics to the screen. Therefore LoG requires a minimum resolution that is at least 720 pixels tall. Making gui graphics at most 720 pixels high we can be sure that the content fits into the renderable area (this is not precisely true because if you have a desktop resolution of 1280x720, the window will be about 720+20 pixels tall with its titlebar and some clipping will occur but that is beside the point).

Steam's hardware survey shows that 99.85% of Steam users can meet the minimum resolution requirement (see http://store.steampowered.com/hwsurvey). Therefore we think that this is a sensible requirement.

Back to the original poster's problem, the real question is, why is the opened window 50% larger than what is requested. Obviously this will easily cut off a large area of the window, causing problem not only with the options dialog but some parts of the 3d view will be cut off as you have demonstrated here viewtopic.php?f=12&t=4649&start=20#p49198. And as the original poster reported, in this case this has probably something to do with Windows DPI scaling thing.

The bottom line is changing the option dialog to be scrollable or scaled is just treatment for the symptoms without fixing the real issue(s) causing the window to be larger than the desktop size.

I hope this helped to shed some light on how the gui works and why it has been designed like this.

petri wrote:There is no autodetetection or scaling of the window contents.
We just open a window as specified by the config file and render the 3d scene to it. The gui is rendered on top the of the scene pixel-perfect with 1:1 mapping between texels and pixels. Dialogs are centered in the viewport.

Please note that getting pixel perfect rendering out of d3d9 is actually harder than rendering 2d elements that scale up & down with the resolution. To achieve pixel-perfect rendering we have to care things such as the discrepancy of centers of pixels and texels (an unfortunate feature of DirectX before version 10) and carefully authoring the graphics so that they fit to the screen and look good in all supported resolutions.

Why do we jump through all these hoops? One reason is that we care about image quality a lot, meaning that we wanted to preserve Juho's high detail art. Upscaling & downscaling bitmaps always results in noticeable decrease in image quality. If you compare grimrock's gui graphics with some other games that have scaled guis you'll notice that grimrock's gui is much crisper. This is because texture filtering always blurs the image (except when the scaling is disabled by carefully setting up texture and screen coordinates like we do).

Rendering 1:1 means that there is a certain minimum resolution that is required to fit the graphics to the screen. Therefore LoG requires a minimum resolution that is at least 720 pixels tall. Making gui graphics at most 720 pixels high we can be sure that the content fits into the renderable area (this is not precisely true because if you have a desktop resolution of 1280x720, the window will be about 720+20 pixels tall with its titlebar and some clipping will occur but that is beside the point).

Steam's hardware survey shows that 99.85% of Steam users can meet the minimum resolution requirement (see http://store.steampowered.com/hwsurvey). Therefore we think that this is a sensible requirement.

Back to the original poster's problem, the real question is, why is the opened window 50% larger than what is requested. Obviously this will easily cut off a large area of the window, causing problem not only with the options dialog but some parts of the 3d view will be cut off as you have demonstrated here viewtopic.php?f=12&t=4649&start=20#p49198. And as the original poster reported, in this case this has probably something to do with Windows DPI scaling thing.

The bottom line is changing the option dialog to be scrollable or scaled is just treatment for the symptoms without fixing the real issue(s) causing the window to be larger than the desktop size.

I hope this helped to shed some light on how the gui works and why it has been designed like this.

Thanks for the detailed explanation, appreciated. While I can see your point in getting the best out of juho's artwork you should consider for robustness and performance reasons a downscaling support for <1024x768 modes. You can still recommend that for best LOG experience it should be played >=1024x768. Why I think it is important enough? On one hand, there are several reports by people with integrated and ATI cards with only <30fps which is not enough for the timed puzzles, selecting a lower resolution is often a better looking and more fine grained solution possiblity than the low spec mode. While having the option for a low spec mode is nice, it is a extreme approach which reduces the visual quality and LOG experience significantly as it limits the light source number pretty severe and select the rendered one pretty "illogical" (see viewtopic.php?f=12&t=4611&start=10#p52309). The low spec mode for performance reasons is therefore even more in conflict with your "max-quality" policy than plain downscaling would be. Also, there are people with netbooks with pretty low resolutions and was there not an early announcement of an iOS version of LOG? There are also people with pretty adavanced and exotic multimonitor setups with incoherent Y sizes and extreme aspect ratios were your "jumping through the hoops approach" seems to stumble (and a plain scaling approach would most likely work). And as last point there is always the chance for misdetecting the resolution on first startup of LOG which could lead to an cutted option menu if downscaling is not supported (suffered it myself with 1.1.3, was not able to reproduce it).

Also,I still think your focussed on question "Back to the original poster's problem, the real question is, why is the opened window 50% larger than what is requested." has the the something to do with the physical resolution which is in taken in consideration for the viewport. If you look on my test (1024 x 1600 in physical 1360x768), it fullfills the minimum size reqirements for viewport and physical screen. On start-up, viewport and text would be correctly centered if it would be not cutted to the physical Y-size. As the viewport was cutted to around 768 (the physical Y-size) option menu is not accessible anymore.

1024 x 1600 in physical 1360x768
start up situation: window starts not centered, but grimrock is centered according to the physical screen

moved window down: Y size is NOT 1600 (seems 768) while it seems to be cutted to that size, leading to messed up the centering


Point is, the scaleing and cutting behaviour in windowed mode changes for a fixed viewport with changed native screen resolution, a unexpected, unusual and most likely unwanted behaviour.

Another case, on this report viewtopic.php?f=12&t=4649#p48764 a triple monitorsetup with 2 different physical monitor sizes and another windowed size was used. In the end he had to use a very strange resolution which he found empirically (After playing around with the cfg file, I was able to set the resolution to 1270x710 and the entire screen is visible on my 1920x1080 monitors. YAY! viewtopic.php?f=12&t=4649&start=10#p49067).

I agree on your opinion on a scrollable option menu - would be not right solution but at least a quickfix if the real reason is not found or by design not easily implementable (or even more dirty: bound the return button to apply... the important stuff is on top). cheers

Yes, the window rect is clampled to the desktop by Win32 API when opening a new window. You're saying that we should work around this behavior. Perhaps but I don't see why. It's not possible to fit a 1024 x 1600 window entirely to the screen anyway when your desktop resolution is 1360x768. If the window size wouldn't be clamped, the window would be too large and you couldn't press the Apply button.

So to recap:

With a single monitor setup, choose a windowed resolution that is same or smaller than desktop resolution (having a higher resolution doesn't make any sense to me).

With multimonitor setup that have variable sized monitors, select the monitor with the largest resolution as your primary monitor and run log on it. We'll probably add a monitor selection dropdown in the next incarnation of the engine if people are having problems with this.

If you have any another problem that prevent you from enjoying log, please tell us and we'll happily assist in setting it up properly.

About the DPI issue. I just checked that if you enable 150% DPI scaling in Windows, all windows will be forced to be 150% in size thus causing the problem you describe. I wonder who at Microsoft thought that this was a good idea

petri wrote:Yes, the window rect is clampled to the desktop by Win32 API when opening a new window. You're saying that we should work around this behavior. Perhaps but I don't see why. It's not possible to fit a 1024 x 1600 window entirely to the screen anyway when your desktop resolution is 1360x768. If the window size wouldn't be clamped, the window would be too large and you couldn't press the Apply button..

This clipping behaviour seems to be a standard but not required win32 API behaviour. I tried it with FTL (http://www.ftlgame.com) and it worked fine to have a window size bigger than screen size (was not clipped, but naturally, had to move the window around, game was completely useable). Also, the LOG window could be shifted around and therefore the apply button would be reachable. (But again, this "strange" use case was constructed only for debugging purposes, as this clipping mightbe the root of problem in the multimonitor and DPI case)

Some googling revealed, that you have to use a additional flag SWP_NOSENDCHANGING (0x0400) on the SetWindowPos function to prevent clipping. Maybe this could help also in the multimonitor problem case and DPI case.

petri wrote: So to recap:

With a single monitor setup, choose a windowed resolution that is same or smaller than desktop resolution (having a higher resolution doesn't make any sense to me).

One use case would be support of systems with resolutions <1024x768, at least user could shift the window around when it is not supported by scaleing in fullscreen. (1024x768 window on a 800x600 device makes sense)
I assume the Quality, performance & robustness argumentation was not convincing enough for a general low resolution support (by scaling)? What a pity.

petri wrote: With multimonitor setup that have variable sized monitors, select the monitor with the largest resolution as your primary monitor and run log on it. We'll probably add a monitor selection dropdown in the next incarnation of the engine if people are having problems with this..

hmmm.... the choice of unrestricted defining a arbitrary viewport in the multiple monitor screen domain would be the most general & powerful solution for this case. (maybe the flag SWP_NOSENDCHANGING is already enough!)

petri wrote: If you have any another problem that prevent you from enjoying log, please tell us and we'll happily assist in setting it up properly.

Well, if you really ask about other smaller things which could be "ironed out"... you have my list here (viewtopic.php?f=12&t=4567).