documenting

My colleagues brought me from the habit of explaining lots of things through comments into the habit of writing almost no comments in my code. Explaining a lot came from my 386 assembly years, where I'd have to write code that does the desired processing on the one side, and carefully detailed what I was trying to achieve in the comments section.

The new fashion is to go from
sprtrsp(spr1, spr2); // make the sprite more transparent
into
makeSpriteTransparent(newSprite, oldSprite);

As I'm applying this over the QuickGo class to better see whether I can structure that code better, I still stumble upon code chunks that remain pretty obscure. Why the hell am I doing those computation on the map size ? and why the test with those * 4 multiplications ?

Hopefully, seeing the widget in action with up to 4 slices of the 'School Rush' level made me understand myself again.

When I want to fit a large stripe of level or a tileset into something that's closer to a square, I tend to cut it in two and put the halves above one another. If that isn't enough yet, I repeat the process. In each step, I exactly halve the largest dimension but double the other. It only makes sense to do so if I'm going closer to a square by doing so, that is if width/2 >= height * 2 when the image was currently wider than high. That exactly converts to width >= height * 4.

When that condition is false, I could still keep processing it further, but by doing so, I'd make the picture less readable. It doesn't make sense to consider it once we have reached the perfect square of course (the sprite rendering the mini-map is always square), but if we end up with a 3x2 rectangle and consider going into 2x3 instead, then sticking to 3x2 remains more readable.