TilemapEd, Tilemap editor for the X16

[Dacobi]

Ok, now it makes sense : )

I think then it would make sense if Windows desktop scaling was a setting that could be enabled/disabled, but as long as the manifest is required to disable it, I don't know how to make it an option.

[DragWx]

The issue wasn't with desktop scaling, so it probably won't hurt to take it out at this point, unless you're planning to intentionally read what the current DPI is and manually scale your GUI elements in your code.

On Windows, if the program isn't DPI aware, the user has the option to choose whether they want Windows to scale it for them, or to leave it unscaled (it's in the properties dialog, under compatibility). I can't speak for other OSes though.

[Dacobi]

The issue wasn't with desktop scaling, so it probably won't hurt to take it out at this point, unless you're planning to intentionally read what the current DPI is and manually scale your GUI elements in your code.

This issue wasn't desktop scaling, but a friend of mine who's been testing the program had a bug where the program would start larger than the desktop, with no way of changing the window size. All controls were outside the desktop.
This bug has been fixed by the manifest and I don't know how else to fix it.
I've tried all combinations of Window flags.

[DragWx]

The quickest thing you could do is provide some command line options to manually specify a window size to start the program with. Ideally, if you're already saving the window's size and position when exiting, this will fix the issue for the user. You could also consider changing the hardcoded default window size to something safer, like 1024x768.

If you're telling the OS not to automatically scale the application for you, then you really ought to add the ability to scale the UI in your program, otherwise people with 4K laptop screens won't have a good time.

[Dacobi]

The quickest thing you could do is provide some command line options to manually specify a window size to start the program with. Ideally, if you're already saving the window's size and position when exiting, this will fix the issue for the user. You could also consider changing the hardcoded default window size to something safer, like 1024x768.

I'm actually working right now on the INI file, so there's an option to save Window size/Maximize state.

Ideally I should find a way to detect Windows UI scale, otherwise a safe Window size would be very small.

(Edit) I just added "--highdpi <uiscale>, --nohighdpi" CLI options.

[Dacobi]

I just uploaded a dev test where font sizes are scaled when "--highdpi <uiscale>" is used.

It doesn't look great, but makes a lot more sense when UI scale is ~200%

[Dacobi]

I'm almost done with Sprite Rotation Range, which is the last feature on my list before the next official release.

Currently only a number of intervals between start and end angle can be specified, but maybe an arbitrary angle could also be specified?

(Edit) I just updated the dev release on GitHub, which now has 2 different ways to create rotations of frames.

Here's a screenshot of the current feature. This is when texture filtering is enabled.

Screenshot from 2023-06-06 10-44-24.png (95.95 KiB) Viewed 37182 times

[Dacobi]

I just uploaded 1.4.0-RC1 to GitHub.

Sprite Frames can now be zoomed and scrolled using Mouse Wheel / CTRL + Left Mouse Button.
You can also scroll through all Sprite Frames using LSHIFT + Mouse Wheel.

I added a xpos check to the Palette render function so the windows doesn't end outside the main window when Sprite frame zoom is larger than the width of the window - the width of the Palette.

The "View->Sprites->Sprite Create" menu is now "Edit->Sprite Tools".

[Dacobi]

I just uploaded RC3 to GitHub, where the Tile Editor has zoom and grab using mouse wheel/CTRL + left mouse button
and the BrushList for Pixel brushes has it's own pixel scale so Brushes don't change scale when zooming using mouse wheel/menu items.

[Dacobi]

I just uploaded version 1.4.6 to GitHub. I think/hope I found all the bugs : )