Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mr Crabman]

So according to one of the artists of the upcoming Steam version, styles of wall like this old mockup for the Steam tileset illustrates:



Are impossible at the moment for code/rendering reasons, as currently natural tiles and constructions textures can't extend over their usual 32x32, so the wall can't "extend upwards" and cover what's behind it (like the dwarf, and the sword on the ground in the above image). Even if the wall doesn't extend up into the above tile, but merely were to be like 3/4 style like these other images:





It would still not work out well for the same reason, because then what happens when water or lava flows against the wall? The water texture would have to appear partway up the wall so that it doesn't look impossibly shallow, or like it's on a lower Z-level to the wall.

So the suggestion is basically, assuming it isn't overly impractical/inefficient (which I can easily imagine it may be), to modify the rendering code so that the tiles can extend and cover other tiles/sprites so walls in this style could be done, either for vanilla, or for other tilesets.

[DwarfStar]

Just to clarify your suggestion, do you mean only just that the tiles can extend outside of their square? Because the screenshot also demonstrates a 2.5d rendering idea, where each Z level is offset by a half a square in Y. Are you suggesting the 2.5d rendering idea, or do you just want some tiles to be able to be "tall" and hang over the tile in the Y space above them?

Technically, the biggest problem I can imagine with extending beyond the square region is texture memory. With all tiles 32x32, they can be packed tightly and very easily in a texture. Would you make all tiles 48x32, with their top edge mostly unused? That would require 50% more texture memory, most of which would be all zero for most tiles. Or if you want the tiles to be arbitrarily sized, then you have a tricky problem packing them into texture without wasting space. Also you'd need data for each tile telling what size it is, where its upper left corner is, and so on. I don't know whether a 50% increase in texture memory would be a huge problem for DF or not, but at the very least it would increase loading times.

[Mr Crabman]

Just to clarify your suggestion, do you mean only just that the tiles can extend outside of their square? Because the screenshot also demonstrates a 2.5d rendering idea, where each Z level is offset by a half a square in Y. Are you suggesting the 2.5d rendering idea, or do you just want some tiles to be able to be "tall" and hang over the tile in the Y space above them?

Oh, I see what you mean, I somehow hadn't even noticed that was being rendered that way.

I think it would depend mostly on whether the desired visual effect could actually work without it, which it seems like it actually might not (hard to be sure because of the grid being used instead of real textures), because otherwise the textures might not line up/transition correctly.

Then again, the ramps are using the normal grid/no offset, so I'm not sure how that would work out.

Technically, the biggest problem I can imagine with extending beyond the square region is texture memory. With all tiles 32x32, they can be packed tightly and very easily in a texture. Would you make all tiles 48x32, with their top edge mostly unused? That would require 50% more texture memory, most of which would be all zero for most tiles. Or if you want the tiles to be arbitrarily sized, then you have a tricky problem packing them into texture without wasting space. Also you'd need data for each tile telling what size it is, where its upper left corner is, and so on. I don't know whether a 50% increase in texture memory would be a huge problem for DF or not, but at the very least it would increase loading times.

You're right about these concerns; this may even be why the 2.5d view was even used in that image, as the textures would still be 32x32, just positioned differently.

Of these 2 options, the arbitrary size would probably make more sense because having 33% of all tile texture space being useless but still loaded into memory is probably not a good idea.

[DwarfStar]

It would be really interesting to know if they went anywhere else with the 2.5d approach, and what if anything is steering them in the other direction. I could imagine problems with multi-z rendering where the southmost wall of a room might obscure the room’s contents. But that could be solved with some kind of “cutaway” view. Trying to picture a tree rendered in 2.5d, it might look kinda stretched out, so maybe they just decided the game overall looked better with the 2d top down view.