YES. Call me a genius. I finally found a solution to a really tricky problem I encountered for the third time in my life. The problem is simple for every human beeing: there are two rectangle with a fixed aspect ratio. Find a way to fit a multidimensional cube B in multidimensional cube A while keeping the aspect ration the same for both. Rectangle B can be scaled but has to keep it's aspect ratio. When we think of two dimensions, we look at the rectangles (the 2D version of a cube) and can simply see which is bigger in height or width and know immediately which side in B has to be the same size a of the same side in A, and thus we are able to calculate the scale factor for B to fit in A. Now in three dimensions: we will have to take a closer look at not only four sides and two aspect ratio, but at six sites and three aspect ratios! It would take us a longer time to think about than in 2D, but it could work in the end. And what's with four dimensions? And Five and eight dimensions? I know this is quite exotic and in higher dimensions almost not of use, but for example, it's important if you want to fit an image to a screen that's doesn't hat a ratio of 16:9 or 4:3. What is if you want to code an image viewer and fit an image to a dynamic window size? Conventionally, you would end up writing special cases for all kinds of aspect ratios, having a version limited to 2D. I once create an almost purely logical approach of it and it was quite a bunch of if and else construction with a dozen of small formulas here and there.
That was the first encounter and didn't think about rewriting it - though it frightened me to port it to another language (like C++). Plus it looked butt-ugly, no sense for elegance. The second I encountered was during a java assignment with almost the same problem as asked above. I didn't how to get it working with another blunt set of if/else constructions. I stopped thinking about it and used another formulas while loosing the original feature I wanted to have. However, yesterday I started rewriting my entire engine/code base and faced a problem about screen resolution, number of characters on screen and the resolution character size. As you know, I don't just have pixels but a grid of fixed-width characters. So I wondered: if I keep using bitmap font characters, can I maintain image quality and spend time with increasing resolution? I was afraid my vision of a next-gen roguelike would begin to crumble and loose it's quality. So I needed scalable fonts, and with them a system for scaling a grid of characters with fixed size to an already existing rectangle with fixed aspect ratio. And with the motivation of bringing HD ASCII graphics to live, I found an actually interesting solution with can be applied to every dimension with and with admittedly medium amount of calculation. It's not as fast a case-by-case determination, but universal and n-dimensional. It's also a rather compact solution I can smoothly integrate into my current geometry system.
I'm not quite sure if I should share this. The key is to take a closer look at the aspect ratios, the rest is up to experimentation. It feels good to know about what I archieve. It is a personal milestone in convenience - I can finally use it like every other functionality in my engine. I'm at a point where I can solve every assignment by simply writing a few lines and minimal class code. I'm quite convinced that my engine becomes a serious tool for work and personal programming - I shall now call it by it's name. But which one? Imperial Toolkit sounds quite basic, doesn't it? Well, it isn't so basic at all. It's highly specialized to suite my needs. And since this blog is called Imperial Industries, it has to be called Imperial Toolkit - ITK. ITK. Hm. Sounds like GTK. This isn't a bad thing, though. Isn't it? All in all, still better than "lib" or "z-axis roguelike framework".