Rotating Images

I have written some code to rotate 16x16 Sprites and have modified the Sprites library to render from PROGMEM or RAM. My efforts are here > https://github.com/filmote/RotateImages

I have included a simple app that rotates an image in PROGMEM and one that does the same in RAM. The new commands in the Sprites library are below:

Sprites::drawOverwriteRAM();
Sprites::drawExternalMaskRAM();
Sprites::drawEraseRAM();
Sprites::drawSelfMaskedRAM();
Sprites::rotateCW();
Sprites::rotateCCW();
Sprites::rotate180();

The rotated sprites can be seen below:

19 am

Maybe someone better than me can:

  • devise an efficient way to rotate images of sizes other than 16x16
  • oprimise the code to make it more efficient
  • work out how to omit the code from the compilation (in the draw…() functions) so that it does not increase size if you are not using them.

I hope it may help others who are running into memory issues when including lots of PROGMEM images.

6 Likes

@Pharap suggested that the rotation could be done directly into the screen buffer rather than into a staging array.

1 Like

Some thoughts:

  • consider a flipping mode: horizontal - vertical
  • see if you can just add 1 variable to the main function: drawSprite (x, y, sheet, frame, orientation)

05

just out of curiosity … why do you need sprites images to be in RAM ?

I don’t … however, I was thinking of writing a Galaga game. To get smooth graphics, I would need 16 images of the same enemy in all rotations and I could achieve the ame by having only 4 images and rotating them. In Galaga, there are 6 or 7 different enemies so this added up.

Rotating the images into a pre-defined 16x16 pixel array using separate rotate functions and simply changing the draw…() functions in the Sprite class meant that the changes to the drawSprite function was minimal. If you do not need the rotate functions then they would not get compiled into the code. Including it within the drawSprite function probably would increase the code size even if you didn’t need it.

1 Like

Good idea, but still have a look at the bit set, you could use.
I’m still confused why you created

  • Sprites::drawOverwriteRAM();
  • Sprites::drawExternalMaskRAM();
  • Sprites::drawEraseRAM();
  • Sprites::drawSelfMaskedRAM();

Most likely copying an image into a buffer and then rotating the isolated buffer is easier than trying to rotate and draw to the screen buffer at the same time. One less problem to solve as it were.

[Replies to self] Forgot to add that the rotate functions handle masks and in my game I would need the same amount of masks.