Sprite RAM "rotation" within the same RAM

[pjmi1]

This is difficult to explain without being misunderstood...

Please would it possible to have a new function which is equivalent to deleteSprite() followed by createSprite(), using new width & height dimensions but not reallocating the RAM - since the RAM required is the same for when width*depth is the same.

For instance: recreateSprite( oldspritePtr, newwidth, newheight)

I use a large full screen sprite as a framebuffer to render the display and need to change the entire display orientation on the fly (in steps of 90 degrees). The library needs to know the dimensions have changed - it's not the same as just rotating the sprite because eg the text plot width changes.

Until now I have succesfully used deleteSprite() then createSprite(with height/width swapped) but on my ESP32 things go wrong now - the createSprite() seems to not simply re-use that same RAM freed from the deleteSprite() even though it is exactly the same size - the callocSprite can't find enough RAM required for the replacement sprite.

The recreateSprite() system could be enhanced further by allowing any sprite size changes if the RAM required is <= the original size allocated by the createSprite().

[Bodmer]

I get the idea. It would cause problems for 4bpp and 1bpp sprites since each line may be padded, hence required RAM allocation may be different if width and height are swapped. So this would have constraint implications which is messy.

It sounds like there is not enough usable RAM left in your application once a large sprite is defined. In this case probloems are likely to recur. If your board has PSRAM then enable it and the sprite class will automatically use it, then these memory problems will be solved.

[pjmi1]

Thanks for your reply Bodmer - that's a good point which I hadn't considered. One easy fix for this is for createSprite() to allocate slightly more RAM than it does now - enough for this padding needed in a future width/height swap though, instead, the user could simple create a sprite bigger than they need to reserve the RAM they'll need later.

I've realised there's actually a serious problem around trusting the OS to handle memory allocation and fragmentation properly over time. For embedded systems this has to be as foolproof as possible. Best practice for coding such devices is for all resource allocation to be done at setup so that issues are apparent during testing and not at some random time after deployment.

With a system that pre-allocates the maximum size of a sprite and being able to re-use this RAM for different size sprites helps with this philosophy. At setup, the user could createSprite() as large a size as they will ever need, which allocates the RAM, then they can recreateSprite() (or resizeSprite()) to the sizes they require ongoing, knowing that no new RAM is being allocated by the OS to cause problems.