Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Grimoire Thread

ManaJunkie

Arbiter
Joined
Feb 15, 2018
Messages
281
GoG was right in not publishing this shit. Your game sucks ass. Die in hell.
I am a dude whose remaining sanity is absorbed by his offspring, his wife, his job and this godforsaken place here. When i started with this gaming crap over 35 years ago i saw the passion becoming professional, professionals becoming an industry and the industry becoming a soulless moloch that fills miles of shelves with crap packed in atrocious dvd boxes. So this crazy guy delivers his work thats full of passion, humour and dedication. You wonder why people enjoy the hell out of his game?

Shut up, whiffet!
 
Last edited:

Solanacean

Educated
Joined
Sep 25, 2017
Messages
42
Cleve, I was able to reproduce the weird scaling/cropping issue some users were complaining about on Steam forums. The culprit is DPI virtualization introduced in Windows Vista. When it's on, Windows messes with the game (as well as any application that doesn't explicitly tell it to fuck off by declaring itself as DPI aware for that matter), and it is on by default when using system DPI settings >120% in Vista and above.

I'll provide some info which would hopefully make it more or less clear what's going on here.

Your code calls GetSystemMetrics(SM_CXSCREEN) and GetSystemMetrics(SM_CYSCREEN) to get the current desktop resolution and the result is then passed to CreateWindowEx in order to create a borderless window which spans the entire screen. Well, the above GetSystemMetrics calls work as expected if the system doesn't use DPI virtualization, but when it does, they fail to get the real resolution, giving you the virtual resolution instead. Basically, when DPI virtualization is on, Windows is lying to you.

Your code also calls GetDeviceCaps(hdc, HORZRES) and GetDeviceCaps(hdc, VERTRES). When system uses DPI vitualization, these calls return bogus data as well, giving you the virtual resolution again instead of the real one. And you rely on this data, among other things, in your screen rendering code. More specifically, you use it for calculating fg_vbscale's parameters xMinClient, xMaxClient, yMinClient and yMaxClient as well as fg_vbpaste's parameters xClient and yClient. So you see why Windows messing with it is bad news.

Steps to reproduce the problem on Windows 7:

1. Make sure you're using Aero theme.
2. Right click on Windows desktop and from the popup menu choose "Screen resolution"
3. Click on "Make text and other items larger or smaller"
4. Choose "Larger - 150%", click Apply, log off and then log on again
5. Run Grimoire in fullscreen mode with scaling

The good news is that this problem is really easy to fix. I'll get on to that later. Need to find my damn notes.
 
Last edited:

Bad Sector

Arcane
Patron
Joined
Mar 25, 2012
Messages
2,223
Insert Title Here RPG Wokedex Codex Year of the Donut Codex+ Now Streaming! Steve gets a Kidney but I don't even get a tag.
Cleve, I was able to reproduce the weird scaling/cropping issue some users were complaining about on Steam forums. The culprit is DPI virtualization introduced in Windows Vista.

Ah yeah, i had the same issue with my own engine getting zoomed in. The fix is trivial, just call SetProcessDPIAware from user32.dll right after your program starts (in WinMain). In my engine i call that via LoadLibrary and GetProcAddress so that it works even in older Windows versions (also i'm mostly using Borland C++ 5 released in 1997 which has no idea about such things so i have to load any new stuff dynamically :-P), but according to Microsoft docs this is supported since Vista so if your minimum requirements (...and compiler :-P) include that you can simply use it directly.
 

Solanacean

Educated
Joined
Sep 25, 2017
Messages
42
Ah yeah, i had the same issue with my own engine getting zoomed in. The fix is trivial, just call SetProcessDPIAware from user32.dll right after your program starts (in WinMain). In my engine i call that via LoadLibrary and GetProcAddress so that it works even in older Windows versions (also i'm mostly using Borland C++ 5 released in 1997 which has no idea about such things so i have to load any new stuff dynamically :-P), but according to Microsoft docs this is supported since Vista so if your minimum requirements (...and compiler :-P) include that you can simply use it directly.
Indeed, calling SetProcessDPIAware is one way to declare DPI awareness, although according to the article on microsoft.technet, using this method "is discouraged, except in very specific circumstances", because "if a DLL caches DPI settings during initialization, invoking SetProcessDPIAware in your application might generate a possible race condition". And yes, using run-time dynamic linking (importing the function via LoadLibrary/GetProcAddress) is the proper way to do it unless compatibility with Windows XP is not required, which I believe is not the case here. If Cleve decides to take this route, the following code does the job:

Code:
HMODULE hUser32 = LoadLibrary(_T("user32.dll"));
typedef BOOL (WINAPI *SetProcessDPIAwareFunc)();
SetProcessDPIAwareFunc setDPIAware = (SetProcessDPIAwareFunc)GetProcAddress(hUser32, "SetProcessDPIAware");
if (setDPIAware)
{
    setDPIAware();
}
FreeLibrary(hUser32);

The other (recommended) way to make an application DPI aware is to set dpiAware property in the application's assembly manifest file. The article I mentioned above explains how to do it in Visual Studio 2005 and 2008 (I think).
 
Last edited:

Solanacean

Educated
Joined
Sep 25, 2017
Messages
42
The manifest code embedded in the Grimoire's executable looks like this:

Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

Using resource tuning tool, I extended it with this code:

Code:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
  <windowsSettings>
    <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">True/PM</dpiAware>
  </windowsSettings>
</application>

This is the final result:

Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">True/PM</dpiAware>
    </windowsSettings>
  </application>
</assembly>

Tested it on Windows 7 and Windows XP, works beautifully.
 
Last edited:

Lady_Error

█▓▒░ ░▒▓█
Patron
Joined
Oct 14, 2012
Messages
1,879,250
generate a possible race condition

thinking.png
 
Joined
Jun 16, 2019
Messages
115
Location
US
Insert Title Here
On a scale of 1 - 10, how hard is this game to get into if you've played like, half of two blobbers before? I want to play it for the memes but am kinda spooked since people are saying the UI is confusing and it doesn't explain anything.
 

luj1

You're all shills
Vatnik
Joined
Jan 2, 2016
Messages
12,869
Location
Eastern block
Solution to mouse problems - reduce mouse polling rate to 125 Hz in driver software

Solution to improper scaling - set your launch options in steam properties for the game to -w1024 -h768

Still necessary?
 

Cleveland Mark Blakemore

Golden Era Games
Übermensch Developer
Joined
Apr 22, 2008
Messages
11,557
Location
LAND OF THE FREE & HOME OF THE BRAVE
Cleve, I was able to reproduce the weird scaling/cropping issue some users were complaining about on Steam forums. The culprit is DPI virtualization introduced in Windows Vista.

Ah yeah, i had the same issue with my own engine getting zoomed in. The fix is trivial, just call SetProcessDPIAware from user32.dll right after your program starts (in WinMain). In my engine i call that via LoadLibrary and GetProcAddress so that it works even in older Windows versions (also i'm mostly using Borland C++ 5 released in 1997 which has no idea about such things so i have to load any new stuff dynamically :-P), but according to Microsoft docs this is supported since Vista so if your minimum requirements (...and compiler :-P) include that you can simply use it directly.

That used to be in the code a couple years back. I think Shams recommended it. It was sitting in there until about 2014 when I began my final code cleanup to release it. I deleted that line when I looked up what it did.

I took it out, thinking it just more fluff trying to hitch a ride on the mean, lean Grimoire machine of basic vanilla Windows old school.

So there. I admitted it. Shams recommended it, I took it out. I messed up. I'm sorry I cannot keep up with every new version of Windows writing out fake data to fool older versions. So it appears all these scaling problems on some machines are my doing.

This is another reason I am so glad I have moved to Unity where all these issues are handled by the backend rendering engine.

EDIT : Just tried it and it fixed the problem on one of the test machines. Seriously, I really appreciate it. At least this problem will be finally fixed in the next release coming up.

EDIT #2 : ... and SetProcessDPIAware sounds like a neckbeard gay sex function stuck into Windows just to make millennials feel extra special. Can you blame me? Do you know how many of these fluff commands you could stick into your code just to try to cover every eventuality? You can just see the Microsoft guy who wrote that command chugging a monster through a hole in the wall at the local rest stop on the highway.
 

Solanacean

Educated
Joined
Sep 25, 2017
Messages
42
and SetProcessDPIAware sounds like a neckbeard gay sex function stuck into Windows just to make millennials feel extra special. Can you blame me?
No one is blaming you, Cleve. Certainly not me. I appreciate all the hard work you've been doing and have a deep respect for you. Please consider using assembly manifest file with dpiAware property set to true rather than SetProcessDPIAware though. It does the same thing but it's safer, cleaner and is recommended by Microsoft.
 
Last edited:

biggestboss

Liturgist
Joined
Feb 16, 2017
Messages
528
I'm going to buckle down and force myself to beat this game. I played this back at release having paid the full price for incline, but stopped after one of Cleve's patches destroyed my save file.

Time to stare at character creation for a couple of hours.
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom