TilemapEd, Tilemap editor for the X16

[Dacobi]

I think maybe it has something to do with SDL_WINDOW_ALLOW_HIGHDPI. I'll check it out tomorrow.

I've updated the dev release on GitHub with a version where I've added SDL_WINDOW_ALLOW_HIGHDPI to the Window flags in the hope that it will prevent SDL from scaling the pixel size on 4K displays.

Scale2x is actually literally one of those fancy upscaling algorithms

I also tried upscaling the offscreen rotation texture by 8x before rotating and then scale back down, but it didn't seem to have any beneficial effect. Probably because the SDL renderer doesn't use any texture filtering and of course doesn't have any algorithm for upscaling.

[Dacobi]

It is possible to enable texture filtering in SDL, but I'm not sure it's a good idea in regards to how the final result will look on the X16.

On this screenshot texture filtering is enabled which causes the Sprite frames previews to appear blurry.
I'm not sure if this can be enabled/disabled in realtime. Now it's a hint I pass on to SDL when creating the renderer.
I could make it an INI file setting. It's only when using Scale/Rotate that the end result will be affected by the filtering.

(Edit) It can be changed in realtime, so I think I'll add it as an INI file or Project settings option.
And also add a function to apply filtering only to Tiles/Frames.

Screenshot from 2023-05-30 09-47-29.png (111.12 KiB) Viewed 55897 times

[Johan Kårlin]

I've updated the dev release on GitHub with a version where I've added SDL_WINDOW_ALLOW_HIGHDPI to the Window flags in the hope that it will prevent SDL from scaling the pixel size on 4K displays.

Sorry to say, it didn't make any difference. But this is not of high priority, it is mostly about aesthetics, I can still edit the sprite if I minimize the palette dialog.

[Dacobi]

Sorry to say, it didn't make any difference. But this is not of high priority, it is mostly about aesthetics, I can still edit the sprite if I minimize the palette dialog.

I just don't understand why the problem appears. other than the HIGHDPI hint I can't find anything else to try.
Guess I'll have to ask on the forum. I may need to use some Windows specific code.

A friend of mine still has a problem where the window is larger than the desktop and he's also on a 4K display. So something weird is going on.

[Dacobi]

I may have gotten the SDL hint the wrong way around. I've just updated the dev release with a version where I disable HIGHDPI instead of allowing it.
If this doesn't help I'll try asking on the SDL forum.

Also there's a Project setting for Texture filtering which is used for Scale/Rotate when enabled.

[Johan Kårlin]

Nope, the problem persists I am afraid. Strange.

[Dacobi]

Nope, the problem persists I am afraid. Strange.

It's really weird. I'm going to drag a cable to my TV in the living room so I can test in Windows at 4K

[Dacobi]

I've done some testing on my 4K TV in Windows and the problem seems to be Windows Desktop scaling.

One solution is to simply set desktop scaling to a lower value, but I've also updated the dev release with a version that has a manifest file which tells Windows not to apply desktop scaling for the program.

It may however be necessary to enable external manifest files first, but I'm not sure.
(Edit) It does seem to be necessary, but then Windows will no longer scale the program.
https://www.unixgr.com/enable-external- ... windows-10

When the manifest file is loaded it sort of worked on my system. There's just some weirdness with the placement of TileSet/Sprite Frames when changing window size/maximising that I still need to figure out.

[DragWx]

Scale2x is actually literally one of those fancy upscaling algorithms

I also tried upscaling the offscreen rotation texture by 8x before rotating and then scale back down, but it didn't seem to have any beneficial effect. Probably because the SDL renderer doesn't use any texture filtering and of course doesn't have any algorithm for upscaling.

Right, you would need to specifically run the pixel art through a special upscaling filter if you were going to do the upscale/rotate/downscale method; using the native bicubic interpolation is just going to give you a bunch of blurry pixels, which may not be what you'd want for rotation.

Also, to deal with DPI scaling on Windows with the manifest file, here's what you do:

yourProgramName.exe.manifest

Code: Select all

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

I think I grabbed this code from here originally. "dpiAware" is the one that's compatible with older versions of Windows, and "dpiAwareness" is the newer W10+ one with extra capabilities. In my project, the older "dpiAware" one was good enough for me so that's why the other one is commented out.

yourProgramName.rc

Code: Select all

1 24  "yourProgramName.exe.manifest"

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.

[Dacobi]

I just updated the dev release on GitHub with a version where the manifest file is linked in, and it seems to work : )