Commander X16

Taking to account that sprites are very small lo res images, I think your example looks good. The sprites I have rotated have less details than your example, and all are rotated with the first manually drawn car as reference.

Taking to account that sprites are very small lo res images, I think your example looks good. The sprites I have rotated have less details than your example, and all are rotated with the first manually drawn car as reference.

If you keep rotating the sprite frame all the way back to zero there's actually very little deformation. So I think I'm going to stay with this approach.

I've updated the dev release on GitHub with a version that has a Rotate Selected Frame dialog.

I'm going to try if I can use the same approach for Scale. Maybe something with Src and Dest Texture Rects.

(Edit) Scale works very well using Src and Dest Texture Rects and SDL Offscreen rendering
I've updated the dev release on GitHub again.

Dacobi wrote: ↑Mon May 29, 2023 10:16 am If you keep rotating the sprite frame all the way back to zero there's actually very little deformation. So I think I'm going to stay with this approach.

Then it must be very good : )!

I noticed a few things when I created 16x16 sprites with many frames (for simplicity I have several sprites in one file). The palette overlaps the sprite editor and the frames are very small. Probably you are aware of this. See attached image.

The palette overlaps the sprite editor and the frames are very small. Probably you are aware of this. See attached image.

Yes, depending on your Desktop resolution this can be a problem. I haven't really looked into it yet other than the ability to close/open the Sprite frames window.

As for the scale of the Sprite frames, I've just copied the code from the TileSet window, but I'm not sure what the best approach is. Maybe some settings that can be changed for min/max Tile/Frame size?
Of course the Frames should fill the width of the window, I'll take a look at the calculation.

(Edit) What resolution are you running at? When I create a large number of 16x16 Sprite frames the layout looks like this:
I've only increased the window height a bit from the default of 1000p. And my desktop resolution is 1440p

I have 2160p, which seems to be the problem. The palette overlaps the sprite drawing area no matter how I resize the window.

Dacobi wrote: ↑Mon May 29, 2023 8:00 am I've been looking over the code, but it's a lot, and I didn't really understand the scale2x function.

IIRC, the way fancy sprite rotation algorithms work is, they first scale-up the pixel art using a fancy upscaling algorithm which tries to smooth out pixellated edges, just like those upscaling filters you find in old SNES and Genesis emulators. Then, it rotates that and scales it back down.

Scale2x is actually literally one of those fancy upscaling algorithms.

Rotation is indeed a destructive transformation, so you won't be able to, for example, rotate 45 degrees, then -45 degrees, and expect to get the original sprite back.

I have 2160p, which seems to be the problem. The palette overlaps the sprite drawing area no matter how I resize the window

This shouldn't be a problem, but maybe SDL does some form of 2x scale on a 4K display.
Does the same thing happen if you maximize the window?

Maybe try running the program with --opengl

Nothing changes when I use OpenGL and it doesn't matter if I maximize the window or resize it in any way. The sprite area and the palette are always the same size and the palette overlaps it similarly. My other sprite which is 16x32 works because then the sprite area is scaled down and reduced to half the size. See attached image.

Nothing changes when I use OpenGL and it doesn't matter if I maximize the window or resize it in any way

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

Scale2x is actually literally one of those fancy upscaling algorithms

I might look into it at a later point, but for now I'm going to stick with the offscreen rendering method.