LEGO Island's clickable bitmap hitboxes are slightly misaligned downwards

[Ramen2X]

In 2D areas, LEGO Island has clickable bitmaps. The hitboxes for these bitmaps become misaligned when using DDrawCompat with the game's Direct3D HAL rendering mode. This does not occur in the game's windowed mode. The rest of the game appears to work perfectly fine.

To reproduce: Install LEGO Island, and add DDrawCompat's ddraw.dll to the game directory. Using CONFIG.EXE, make sure the game is set to use Direct3D HAL as the rendering mode. Launch the game, and after the intro movies (skip with the spacebar), try clicking on one of the bitmaps, such as the animated book, or the directional arrows on each side. The clicks will not register, and you will instead have to click slightly below the bitmaps to hit the hitboxes.

Interesting to note, if you set the game to use Ramp Emulation (with 3D acceleration enabled), the whole game window becomes slightly misaligned rather than just the clickable hitboxes.

[narzoul]

This doesn't seem to be a bug in DDrawCompat. It happens with native DirectDraw also. The game doesn't properly handle DPI scaling factors higher than 100% (as expected of such an old game). Set your desktop DPI scaling factor to 100% as a workaround. Maybe there's some tool to do that automatically when launching the game.

I'm not sure if this can be fixed by DDrawCompat. I tried messing with overriding system metrics before, but it caused more issues than it solved.

[narzoul]

Found another partial workaround: set "Run in 640x480 screen resolution" in the executable's Compatibility properties. It seems to also reset DPI scaling to 100% just before the game is launched. However, this only lasts until alt-tabbing out of the game. When going back, the screen will be shifted again from the top. I guess this is a decent solution if you can avoid using alt-tab.

[Ramen2X]

That's interesting, thank you. I guess I never noticed that this could happen natively since using Direct3D HAL as the rendering mode produces borderline unplayable results on my setup without utilizing a wrapper.

Set your desktop DPI scaling factor to 100% as a workaround.

My screen DPI scaling factor is at 100% and the issue still occurs. However, I can confirm that using the "Run in 640x480 screen resolution" option does address the issue, and out of curiosity have also confirmed that hacking the game to run in 1920x1080 also fixes the issue.

Do you think this issue is a limitation of DDraw itself? The reason I ask is because in my testing with this game, when using wrappers that utilize API conversion, this doesn't happen.

[narzoul]

Do you think this issue is a limitation of DDraw itself? The reason I ask is because in my testing with this game, when using wrappers that utilize API conversion, this doesn't happen.

I don't think so, it was also reported for dgVoodoo: https://www.vogons.org/viewtopic.php?p=415020#p415020

[narzoul]

Some more info about this from vogons: https://www.vogons.org/viewtopic.php?p=413133#p413133

[Ramen2X]

Thanks for the information! I'm thinking the reason I didn't get the issue with other wrappers is because I may have used resolution override settings with them. I just tried out dgVoodoo + 640x480 and can confirm the same issue is there.

Some more info about this from vogons: https://www.vogons.org/viewtopic.php?p=413133#p413133

This was especially interesting; it's intriguing that the issue could possibly be caused by the game compensating for the position offset from a non-existent window caption (possibly explaining why this particular issue doesn't occur in windowed mode?), however I'm not quite sure what "caption" is referring to. Does it refer to the title/name of the window? The game does have a window title (see attached screenshot), and even if you create your own window for the game by intercepting CreateWindowExA, the issue is still present, so I am a little confused about that.

Thanks again!

[Ramen2X]

It turns out I was wrong, creating a new window for the game and changing its styling to remove the title bar does fix this issue once and for all. This is a good enough workaround for me personally, but I do still wonder why this wasn't a problem in previous versions of Windows. Thanks for the help!