Hey, so I guess this is a continuation post from my previous post, and all the dwarf fortress style fun I had with changing the zoom.
When I was making this game, I had to take a moment and think about just how I was going about rendering things to the screen. I’m not talking about the what and how, but the where. I had always planned on having multiple resolutions available for the game, and thus the this problem arises: placing an object at (100, 100) when the resolution is 800x600 is quite a different place then placing an object at (100, 100) with a resolution of 1024x768. It might seem like the same location, both being placed 100 pixels from the top left corner, however if you think of it in % distance instead of pixels, it ends up being 12.5% and 9.7% respectively. Beginning to see the problem?
So I’ve thought up multiple ways around it, the first being a brute force, I-would-fire-you-if-you-did-this approach. Basically, whenever I would draw anything, I would use a switch statement and change the pixels based on what resolution it is currently set at. Please don’t ever do that. This is just an example as to a possible approach. I’m serious. Don’t. Anyone that sees your code will vomit uncontrollably.
The second approach would be to create my own helper functions and pass every draw call in as a % of the screen instead of a pixel location. for example, a 32x32 object that I want placed at (100, 100) in a 800x600 resolution, I would pass a rectangle a position (12.5%, 12.5%) with width and height (4%, 4%). Basically all the helper function would do is multiply those percentages by the current screen resolution, and then send the pixel locations to a draw call. This is a great way to do GUI’s and menu’s, however begins to get messy when you have a character moving at say, (573, 429). Depending on the location you could run into floating point errors, or something. I don’t know, but it can be annoying if your player is at (14.8643%, 67.429%).
Finally, the third approach (and the one I use in my game) is to assume that your screen is always in one resolution (800x600) and anything anyone tells you is a filthy filthy lie. Similar to the approach above, this would require you to make your own helper functions. The program would save a ratio between the assumed screen size and the actual screen size. For example, if your assuming your resolution is (800x600) and your drawing in a (1024x768) window, the ratio would be (1.28, 1.28). And so when the helper function takes in a draw call for (100, 100, 32, 32), it would multiply that out to (128, 128, 41, 41) and pass it to the draw call.
Anyways, it’s been 5 paragraphs so far and I’ve just gotten through the introduction, so onto the problem. Originally, my game assumed the screen size would always be (800x600). I am using 16x16 pixel tiles, which would mean that at that resolution, I could fit 50x37.5 tiles on screen at once. The problem arose when I wanted to make everything bigger, resulting in 40x30 tiles, keeping in mind I am still using the same 16x16 pixel tiles. This comes out to filling a 640x480 portion of the screen, which not quite 800x600, so I’d need to scale it… which.. well is going to be a pain. I’m left with two options, either rewrite my code so I assume a 640x480 resolution, or hack something together that applies a 640x480 resolution for levels and 800x600 for everything else. I chose the latter.
Basically, I have a boolean which determines if the game is running with a 800x600 screen size or a 640x480, and flip it when required. For instance, when drawing the level, it draws the ground, players, objects, npcs, well, everything but the HUD in 640x480, and then swaps back to 800x600 when drawing the HUD. This isn’t anywhere near ideal, and is basically attributed to a lack of planning when making my rendering system, but it works for the most part.
Anyways, that’s about it for my adventures through resolutions. I really think I’m not getting it, like how do companies that make games with many resolutions with many aspect ratios do it? Maybe this is about as easy as it gets. I’ll be making a post about some of the new additions in the Demo, but for now I should really be paying attention to the class I have been in for the past 30 minutes.