Larger hex size

Post by **freim** » March 7th, 2006, 1:25 pm

I'm playing around with a larger hex size (96x96). I was hoping the code would allow for this, but I'm getting all sorts of glitches. The hexes don't seem to match up correct (they have the exact same shape as the old one, only larger) and multihex/overlay get corrupted.

I wanted to see if the code handled it, but obviously there are some issues. Quite possibly I didn't do all the necessary changes. I changed the following:

Code: Select all

image.cpp:      const int tile_size = 96;
display.cpp:    const int DefaultZoom = 96;
builder.cpp:    const int terrain_builder::rule_image::TILEWIDTH = 96;

Units got scaled so I ran:

Code: Select all

for i in *.png; do convert -bordercolor none -border 12 $i tmp/$i; done

which just padded them with transparent so they got the right size.

I changed the grassland variants and a village to 96x96 to test:

-> What i might be working on · Post by **Eleazar** » March 7th, 2006, 1:57 pm

i cringe at the thought of redoing everything, (nor do i see why we should).
But if conveniently possible the engine should support multiple hex sizes for the sake of future verions or branches. (though only 1 hex size at a time)

Post by **freim** » March 7th, 2006, 2:01 pm

Eleazar wrote:i cringe at the thought of redoing everything, (nor do i see why we should).
But if conveniently possible the engine should support multiple hex sizes for the sake of future verions or branches. (though only 1 hex size at a time)

I don't propose we redo everything. I just did it for my own sake because I was curious and wanted to see how it turned out and if the terrain engine could cope with it. I have some thoughts why I think a larger size might be good, but I don't really want to start a huge debate over that. I just want to see if these rendering glitches can be sorted out.

Anyway, a lot can be converted quite easily. The units should not be changed imo, so I just padded them. The terrain I can change quite easily in a week or so.

Edit: After some more testing I discovered that the black pixels at the hex edge are not because the hexes aren't aligned. The black pixels actually get drawn on top of the tiles for some reason. I think this might be related to the zoom bug where you see the same thing.

JW · Post by JW » March 7th, 2006, 2:38 pm

I think it would be nice to have larger hexes as it would allow larger, more detailed units and terrains.

...of course there is a problem that all the art currently done for the game is for the current hex size. Also, art is hard to come by in general...

Post by **Darth Fool** » March 7th, 2006, 3:52 pm

JW wrote:I think it would be nice to have larger hexes as it would allow larger, more detailed units and terrains.

...of course there is a problem that all the art currently done for the game is for the current hex size. Also, art is hard to come by in general...

AHHH!!! creeping biggerism!

But, yeah, the engine should be able to handle it properly. This reminds me of artifacts I have seen when in zoomed mode. It would be good to have this fixed.

Disto · Post by **Disto** » March 7th, 2006, 4:51 pm

I'd be funky if the engine could switch up to something like this for higher resolutions.

toms · Post by **toms** » March 7th, 2006, 6:00 pm

Why?

If we really need this, we maybe could make villages to villages and stop them beeing houses?

Post by **torangan** » March 7th, 2006, 6:09 pm

IIUC the idea is to expand terrain and especially things like villages - not units. Wesnoth got way too much units and animations by now to make this an even slightly sensible move. The only possible exemeption might eventually be to allow weapons to stick out or for very large monsters like a dragon to expand beyond the usual limits.

Post by **freim** » March 7th, 2006, 6:15 pm

toms wrote:Why?

Because I wanted to. Now stop nagging about it. I'm not proposing that this should be changed in trunk, I'm just doing it for myself and I feel absolutely no obligation to justify what I spend my spare time doing.

The point of this thread is to get some feedback from the others devs, so we can try to figure out these rendering glitches and fix some bugs.

Post by **freim** » March 7th, 2006, 6:56 pm

What I've gathered so far from changing the tilesize to 96x96:

* Units and terrain (including transitions) get scaled up if not resized (seemingly without any gfx glitches)
* Padding units with transparent to draw them unscaled worked without a hitch, placement was also correct even though I didn't change a constant which seemed to have something do with unit placement (builder.cpp: const int terrain_builder::rule_image::UNITPOS = 36 + 18;)
* Terrain tiles get rendering artifacts at their edges. This seems to be the same problem as with zooming, although it happens at default zoom which indicate it's not a problem with the scaling algorithm. The black pixels seem to be drawn on top of the hexes, so it's not a problem with the hexes not fitting together.
* The black pixels at the hex edges dissapear when you scroll around.
* I suspect that the overlay and multihex code make some assumptions about hex size since I get a lot of corruption with these. This happens with both gfx that has been resized and those that has not. Multihex and overlay does not get scaled up like normal terrain and units.
* Movement and attack animations seems to work flawlessly.

Post by **freim** » March 10th, 2006, 2:54 pm

I've found a solution for the glitches. As I wrote on the mlist:

"Ok, so the get_unmasked function in image.cpp applies a mask to re-cut scaled tiles to a given mask defined by:

std::string terrain_mask_image = "terrain/alphamask.png";

When I changed this png to 96x96 the glitches disappeared (including the overlay ones). I couldn't see any apparent glitches on any zoom lvl after this, but I suspect there could still be problems.

Sirp suggested that the mask maybe should be created programatically instead in case the scaling somehow messes it up.

mask_surface and scale_surface is somewhat beyond me though, so thats it for my part I guess."

As I said above I still think there are some subtile errors in the way the mask is scaled, as the 72x72 tiles which get scaled up now get glitches while the 96x96 ones work flawlessly.