Scaling rendering error, all sprites / graphical elements seem too big by 1 pixel

[drone1400]

First of all, I am talking about the Windows release of DinkHD V2.05, running in Windowed mode. Though I presume the same issue is present in fullscreen mode?...

There is quite an annoying rendering issue when setting DinkHD's resolution to something other than the 1:1 640x480 resolution. In short, it seems that every sprite / hud element graphic is too wide and too high by exactly 1 pixel.

I am not quite sure if this issue manifests exactly the same at all resolutions, but for simplicity's sake, I'll only be talking about a 1280x960 scale, which should scale perfectly accurately as it is exactly double the native 640x480.

For comparison, here is a screenshot of the same screen from the DMOD Charlie's Legacy in both DinkHD and YeOldeDink, both set to 1280x960. Smoothing is disabled in both engines.

Game	Screenshot
DinkHD
YeOldeDink

First, ignore the text rendering as that is not what I am talking about here.

If you look at the individual puzzle pieces, they are natively 50x50 pixels each. At 1280x960, they should be 100x100 pixels. In DinkHD however, they are all 101x101 pixels. Their top/left coordinates are correct, but their height/width are both too big by 1 pixel.

The same goes for the left side-bar, which should be 40 pixels wide, but in DinkHD it is 41 pixels wide. Same for various HUD elements from the bottom of the screen...

That being said, it might not be just that simple, as there is some additional weird rendering happening with the sidebar, looking at it more closely, in actuality in some places the sidebar seems to be missing some black pixels too, but that might be a separate issue?

[SethRobinson]

Hrm, this is a similar issue to the scrolling one, sprites are rendered too big to fix sub-pixel holes caused by smoothing and scaling - I've applied the same fix, with smoothing off and at exactly 4:3 modes it will now look correct.

The second issue - some random thoughts without checking:

1. Does the engine apply a transparency key by default? Possibly based on the top left pixel color? Does the top left pixel color match the missing pixels? Might help narrow down the bug by taking a close look at the actual art.

2. I half remember that the code has hacks to turn transparency off and on for specific sequences. I assume this would use the same sequence as the original art though, but if it didn't, the hack might be missing, enabling transparency.

Anyway, I'll apply the fix for the "sprites rendered too big" issue.