Here's the question: If one uses, say, 8x14 font with half 32x32 graphics, other half being, say, 12x24 : what should the code do?
Or the other way around: 32x24 font, 16x16 and 8x12 graphics. and some 48x54 ones just for fun.
The biggest problem with all this is that game icons are, by necessity, pixelart. This means that any resizing other than upscaling them by increments of 2 is a murder on the piece of work that they are- seriously decreasing not only their looks but most of all their readability.
Sometimes decreasing them by 2x will work for a general overview and that's it. However, text and clear symbols can usually be downscaled with less of an impact, though it will also never look as good as the original.
Not to mention, the second situation is bloody unlikely- since the interface NEEDS to have 80 tiles horizontally, that would require a resolution of 2560...
An additional general rule: the aspect ratio of EVERY tile (tileset and graphics) must ALWAYS be mantained.
Due to those problems, I believe separating the worldview zoom from the menus is the only way to go. Any playing around with stretching and zooming is useless as long as most users can use 16px tiles at best (if I'm not mistaken, the most popular horizontal resolution is still 1280).
Once/IF that's taken care of, an optimum for me would be:
-situation 1 is: keep the menus with the original fontsize and for the worldview choose the largest of tiles (32x32), stretch the base tileset by a maximum fitting increment of 2x (in this case= once, because that will yield 16x24) and CENTER them, and keep the second set of graphic as is and also center them.
-situation 2: check your maximum resolution and keep decreasing the base tilest by increments of 2 until it fits- so in my case= just once, which results in 16x12 tiles. If your horizontal resolution is 1920 you can leave it be.
Now we've got a problem with the graphics: the basic view would indeed use the largest- 48x54 tiles, and stretch/center the others to 48x48 and 36x48 respectively.
But now that we're using tiles that big, one should be able to keep zooming out (STILL by increments of 2) until they reach the smallest tilesize of the set.
So the next zoomout will yield: 24x27, 16x16 and 8x12. Now we've come to a dumb situation because the tileset author decided to use a weird tile size- we can't divide 27 by two. I guess it's up to you to decide how to downscale it, let's say this results in 12x14, 8x8 and 8x12. Now we need to zoomout once again to make it fit the smallest original tiles (8x12) but the second one is good enough already. So the result of the last zoomout will be 6x12, 8x8 and 8x12.
I'm pretty sure that was not at all clear, in which case let me know. I'm also pretty sure all this is very hard to do and you'll want to look for another method, in which case also let me know and I'll try to think of more general rules without worrying about even scaling and readability so much.
EDIT: another thing! when stretching tiles by increments of 2, it's optimal to use the nearest neighbour method- tiles are designed to look best with it. All other stretches/squeezes should use some hq/SaI/etc. algorithm (don't remember which one you're using right now).
Author
Topic: [PRINT_MODE:SHADER] (Read 89591 times)