First Part of the Itch Scratched - Animation Scaling works on the Fly

First off, sorry for the ghastly screenshot used, but I needed a blank and unfinished section of the world that was really open, so I could see the things that I'm about to talk about without trees and things getting in the way.

So, based on my update from last night, the first part of the code to change was to modify the Graphics Rendering Engine to see if I could modify the code so that animations for Monster Encounters were no longer locked to the native game tile size of 64 pixels. I also wanted to at the same time see if I could also grow/shrink the canvas size. This would give me a two-fold benefit. 

First, by unlocking the rendering engine from a 64 pixel monster, I could have monsters that are large, larger and really large. Not doing that from the start was probably lazy, but that feels like a long time ago now.

Second, ideally I'd love to have monsters rendered at different sizes. At a most basic level, that allows me to use the same sprite, that's already stored in the engine as a bitmap as varying sizes - ie, multiple monster types. Re-using the same animation pack for two different things. Goblin? Sure. Lets make you tiny. Some Hobgobnlin? Sure. Same animation, but now you're quite large. All that while storing the same original bitmaps in memory. I was however concerned about framerate - would I be able to get away with scaling the rendering aspect on the fly, or would I need to create new bitmaps stored natively in the smaller/larger resolutions? Turns out, scaling on the fly works without any noticeable framerate impact, but in the emulator and a physical device. So, I get to write some code now that can scale models to re-use things at completely different scales, but also be able to subtly apply a small scaling to a particular monster in an encounter if it's a bit tougher and stronger than it's peers. Or weaker. There's always a runt I guess.