As I tried to clean up the warnings, I am finding myself tying the game to the lower level library in ways I don't like. I'm beginning to emulate what some functions are expecting at the cost of future enhancement. For example, one of the reasons the game screenshots seem so small is because it's literally running in a 320x200 window. While I can "zoom" the final display at a higher resolution, that will impact what the mouse input routines are expecting. I want the game running at a higher resolution anyway, but there is so much that is hard-coded into the game. Glancing at the source code there 518 buttons that have locations set in a huge button struct. That's not including dynamic locations like lists or sprite placement.I'm planning on expanding the graphic fidelity, and I have two ways I want to try this...
First, my original idea of defining the display from 0 to 1 on the X and Y access. That will make the game display unlocked for any aspect ratio. This would kind of be a mess as the game itself does not have much in the way of vector graphics. All the the bitmaps will be stretched into whatever the game would feel appropriate.
My other idea is to keep the underlying "grid" at 320x200, and overlay the high resolution graphics on top. I would treat each "pixel" on the 320x200 grid as a "cell" However I have now come to another conundrum. 320x200 is 16:10 and I would rather it be at 16x9. What would be the new "Native" resolution?
Doing some quick math here.
320x200 expanded by...
... 360% is 1152x720
... 400% is 1280x800 (nice and round)
... 540% is 1728x1080
So maybe "native" is 1280x800 and then I can stretch depending on the player's preference? Going "down" to 720 will afford me a little anti-aliasing. Maybe because the background is black, that might afford me a little leeway that no one is going not notice the black bars on the side.
Hmm. Oh well, back to documentation. I included a new animated GIF showing the 1Ch thread running. I now have animated blinkys and and decorations.