TilemapEd, Tilemap editor for the X16

[Dacobi]

Use windres (part of your compiler toolchain) to compile your .rc file into a .res file, then include the .res file along with all of the .o files when you link the main binary. This is what embeds the manifest into the EXE so you don't need any registry tweaks or supplementary files

I ended up with an rc file like this

Code: Select all

#include "winuser.h"
1 RT_MANIFEST tilemaped.exe.manifest

And my manifest

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <asmv3:application>
    <asmv3:windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>      
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

[Johan Kårlin]

I am afraid I don't see how Windows desktop scaling is related to the isolated problem that 16x16 sprites are rendered too big. Windows scaling affects programs as a whole not single graphical elements, or am I wrong? When I test the latest two releases simultaneously, this is how it looks (I have the display setting set to 125%):

screenshot.png (118.04 KiB) Viewed 41535 times

The latest version in the background is ignoring the display setting and is thus displayed in 100%. The other version in front follow my settings and are thus displayed in 125%. Both have the problem of rendering the drawing area for 16x16 sprites too big.

But I can also mention that for me the latest version is still an improvement. Because when TilemapEd is rendered in 100% it is very near the size of all other windows I have that are rendered in 125%. When TilemapEd follows my display settings of 125%, it is rendered bigger than my others programs like for example Visual Studio Code. So there is a calibration issue here.

[Dacobi]

The latest version in the background is ignoring the display setting and is thus displayed in 100%. The other version in front follow my settings and are thus displayed in 125%. Both have the problem of rendering the drawing area for 16x16 sprites too big.

My Windows installation had scale at 200% which resulted in a layout like your previous screenshot.

I simply don't understand what else it could be. Could you post full screenshots of both versions when maximized?

For me the newest version will render with the same scale as in Linux even when Windows desktop scaling is at 200%

(Edit) Is your display 16:9?

[DragWx]

I gave the code a cursory glance, and I spotted a potential gotcha:

In TEditor.cpp, under EMODE_SPRITE, mPalette is positioned according to mSprite->mTexParam.

Then right after that, mSprite->renderEd() is called, which calls mFrame->renderEd(), which draws its elements with the positioning information from mFrame->mTexParam, and not mSprite->mTexParam.

I suspect these two mTexParam objects are getting out of sync somehow.

[Dacobi]

This is what the layout looks like for me in Win10 at 4K, when Desktop scaling is not in effect.
Your screenshots clearly have a very different scale, but I don't understand where it's comming from if Desktop scaling is disabled.
(Edit) Are you using Win11?
(Edit 2) Maybe I'm misunderstanding the problem entirely? Is it only a problem if the program is in Window mode? Or is it also present when the window is maximized?
What I mean is that compared to your earlier full window screenshot, your Palette window looks like its 4x larger than in my 4K screenshot.

win104k.png (78.34 KiB) Viewed 41500 times

Then right after that, mSprite->renderEd() is called, which calls mFrame->renderEd(), which draws its elements with the positioning information from mFrame->mTexParam, and not mSprite->mTexParam.

TSFrame (mFrame) only has one constructor which takes a mTexParam* that is always set to the mTexParam of the parent Sprite, so mFrame->mTexParam and mSprite->mTexParam should always be interchangeable.

Until I figure out the problem, I've updated the dev release with a version that has a Tile Edit/Sprite Edit Int Slider to set the current editor scale of Tiles and Sprite frames.

[Dacobi]

I think I understand and figured out the problem specifically with 16x16 Sprites.
There's a disparity in the Sprite constructor for how scale is set up specifically for 16x16 Sprites.

I'll upload a new version in a few hours that hopefully should fix it. Also my plan was to add Tile Edit scale to the project settings and use it as a starting point for when Sprites are created/loaded so that users can set up a scale for a specific window size.

[Dacobi]

I just uploaded a version that should work on any desktop resolution.
All sprites, besides 8x8, should be created with almost the same scale and there is a separate scale for tiles and sprites which is saved to the project settings.

I've also changed how and when the Palette window and Sprite frames positions/size are/is updated.
It may still need some tweaking.

[Johan Kårlin]

Now, it works! The palette dialog is placed nicely beside the drawing area of the sprite. But the size of the pixel grid is very different depending on the size of sprite. In the attached image I tested to create a 64x64 sprite.

bigsprite.png (113.08 KiB) Viewed 41447 times

The squares become quite small. But maybe the plan is to add the possibility to zoom in and out with ctrl+mousewheel just like the tilemaps?

I guess your other questions aren't relevant anymore, but I have a 16:9 display, 3840x2160. And nothing changes if I resize the window or maximize it.

[Dacobi]

The squares become quite small. But maybe the plan is to add the possibility to zoom in and out with ctrl+mousewheel just like the tilemaps?

I guess that would be a requirement to be able to work on 64x64 Sprites. I had already mapped the mouse wheel to scroll through the Frames, but that could be move to CTRL + mouse wheel.

I guess your other questions aren't relevant anymore, but I have a 16:9 display, 3840x2160. And nothing changes if I resize the window or maximize it.

There's just one thing I still don't understand. The screenshot you just posted, is that when maximised on a 4K display?
If it is, there still seems to be a difference how the program is scaled on your machine.

I just uploaded a version 10min ago where the Sprite Edit scale can be set and saved to project settings on an individual Sprite level.

[Johan Kårlin]

No, it is not maximized, far from. The size of the window is about 30% of the screen. This is how it looks if I maximize:

bigsprite2.png (137.92 KiB) Viewed 41436 times

Nothing really changes, I just get a lot more empty space.