Page 1 of 3

Hex tileset needs very large y offsets, problems ensue

Posted: Tue Nov 12, 2013 5:44 pm
by Treefingers
So I'm making a new tileset. 128px for the first version (then I'll see about scaling it down to 96, 64, and 32). But I'm having issues with the y offsets (i.e. for unit and shield gfx), specifically that they need to be far larger than I'd expect them to be. For my 128px version it's around 160px, meaning that with a 0 offset, the unit graphics are all completely outside and above the base tile graphic.

That's if I use graphics that are cut close to the visible pixels. (At this point, I'm just linking to unit PNGs from existing sets.) I can also use very tall images with a big transparent space at the top. But that (1) leads to sloppy tile resources, and (2) doesn't solve the real problem: the support/garrison section of the city management window gets absurdly tall to make room for the unit images. To be clear, the images aren't themselves large, the game just seems to include either the offset (if I use offsets) or the extra pixels (if I pad the images) as part of the unit's total height.

Making things worse, I only seem able to move the unit and shield by using an offset property, but not the action/rank icons or HP bars. To get those to line up visually, I'm forced to use the tall image option for at least those graphics. So there's no way to know whether moving everything with offsets would solve the problem.

Looking at some of the non-hex iso sets (e.g. amplio), y offsets for even the larger sets are closer to around 8--16px. But even a smaller hex tileset like hex2t has an offset of around 60px, which is 50% larger than its tile widths, has garrison/support views that are taller than they need to be, and uses order/rank graphics that are much larger than just the visible pixels. Based on this, I'm guessing that my own set suffers from the same placement issues (perhaps even a proper bug?) but they are more pronounced because I'm making much larger base tiles.

tl;dr:

When making a large (128px) hex tileset, I get garrison/support views that are ridiculously large (added whitespace, not stretched images). And I cannot solve this by changing y offsets. Also consider that if my offsets are set to 0, the unit graphics sit well above (completely outside) the tile graphic.

If I have time, I'll get around to taking some screenies and doing a little more testing.

Re: Hex tileset needs very large y offsets, problems ensue

Posted: Tue Nov 12, 2013 6:28 pm
by Treefingers
amplio2: Margins around unit graphics are tight
amplio2: Margins around unit graphics are tight
freeciv - offset example - amplio2 01.png (5.06 KiB) Viewed 10663 times
hex2t: Margins are off; panels are larger than amplio2, even though the images are smaller
hex2t: Margins are off; panels are larger than amplio2, even though the images are smaller
freeciv - offset example - hex2t 01.png (5.74 KiB) Viewed 10663 times
my set: using amplio2 graphics as-is but with my set's dimensions; y offset around 32px
my set: using amplio2 graphics as-is but with my set's dimensions; y offset around 32px
freeciv - offset example - mine 01.png (7.9 KiB) Viewed 10663 times
my set: same as before except with y offsets that place the unit images properly on the tile
my set: same as before except with y offsets that place the unit images properly on the tile
freeciv - offset example - mine 02.png (6.35 KiB) Viewed 10663 times
The reason my own HP bar is so off is that I made a normal-size image on the assumption that it could be shift with an offset. To move it down, I'll have to put them at the bottom of an image that is tall enough to have that huge amount of whitespace above the visible pixels. Also notice that there is a huge amount of whitespace below the unit, even though there is no image padding or anything else to justify this.

Re: Hex tileset needs very large y offsets, problems ensue

Posted: Tue Nov 12, 2013 9:04 pm
by HanduMan
What are the dimensions of your set? What does 128px refer to? Both width and height? The height shoud be much smaller than than the width. For Amplio the ratio is 1:2.

And if youre making a hex set then you should define a proper value for hex_side also. I don't remember how to make it 'proper' but you could paly around with those first.

I once made a tileset that was to be the first ever truly isometric hex set. No such tileset has ever been released and mine also is falling into oblivion... but I've still got the unfinished files. And this is how some of the settings are:

Code: Select all

; Basic tile sizes:
normal_tile_width  = 128
normal_tile_height = 34
small_tile_width   = 15
small_tile_height  = 20

; Basic tile style.
is_isometric = 0
is_hex = 1
hex_side = 30
Note that to make an isometric hex set we need to define is_isometric = 0 :roll:

Code: Select all

; offset the flags by this amount when drawing units
unit_flag_offset_x = 36
unit_flag_offset_y = 8	
city_flag_offset_x = 2
city_flag_offset_y = 9

; offset the units by this amount when drawing units
unit_offset_x = 32
unit_offset_y = 0
The y offsets are quite small. Or were you referring to these?

And this is how it looks:
ScreenShot150.jpg
Hmm... some extra whitespace below the units & of course wide gaps between them horizontally. But at least they are not falling to the bottom...

Re: Hex tileset needs very large y offsets, problems ensue

Posted: Wed Nov 13, 2013 6:43 pm
by Treefingers
Thanks for the input.

First, I realize I didn't post a map screen, which might clarify some things, so here's what I've got so far. No fancy graphics until I've got the metrics figured out. But obviously things tile pretty nicely and my connectables are connecting properly. Some things need a little vertical nudge. Unit and unit_flag y offset is 160px, which puts the units where they should be. City flag is 32 y offset, and citybar y offset is 0, giving an idea of just how far off low values put the graphics (the city is built on the northern hill tile).
freeciv - offset testing 02.png
Basic tile graphic dimensions are 128px wide by 160px. My tilespec has:

Code: Select all

normal_tile_width = 128
normal_tile_height = 188
hex_side = 64
is_isometric = 1
is_hex = 1
"normal_tile_height" is 188 because the wiki says
The dimension of the bounding box of the hexagonal tile will be equal to the normal dimension minus the hex_side. For instance normal dimensions of 64x32 with a hex_side of 16 for an iso-hex tileset will give hexagons of size 48x32.
64px is the height of my hex sides, and 124px is the height that gets me correct tiling, so "normal_tile_height" should be 188px, right? But maybe there's a bug or wiki error evident here.

I tried messing around with "normal_tile_height" and "hex_side". Changing "hex_side" (tried 0, 32, 64, 128) has no effect that I can notice, except that if it's 0, I start getting missing image resource errors :| . Changing "normal_tile_height" causes vertical overlap or gaps as expected, and actually does affect the height of the supported/present panels (smaller number = shorter panels), but has no effect on the distance between the HP bar and the unit image. The HP/unit distance is also still there in the supported/present panels so that when the panels are shorter, the unit graphic is hidden outside the panel's bounds with the HP bar still visible near the top. "hex_side" still has no effect on any of this, so I gotta say I'm not convinced it actually does anything :? .
Visible HP bar, shorter "present" units panel, no visible unit graphic, normal_tile_height=64
Visible HP bar, shorter "present" units panel, no visible unit graphic, normal_tile_height=64
freeciv - offset testing 01.png (33.59 KiB) Viewed 10648 times
Tile orientation is as in hex2t (points at top and bottom; vertical sides), so it's a non-iso hex as far as I know. So though you say it should be smaller vertically (as amplio2 is), hex2t isn't (since its hexagons are taller than wide) and the visible base of my own tiles has a nearly square bounding box since I'm foreshortening it a little for some perspective. For mine, the extra vertical space is to leave room for tall features (forest, mountain, city) to extend above the base tile.

I've been using the hex2t settings as a reference since it's a complete non-iso hex set. So I actually have "is_isometric=1" (I second the :roll: ) since that's what hex2t was using. I haven't had any problems with pathing so I assumed this was fine. I did have pathing issues when I switched to "is_isometric=0", so I just put it back.

And finally, yes, those are the offsets I was talking about. But you're showing an iso hex set there, which I suppose may not have this problem.

Hope this helps.

Re: Hex tileset needs very large y offsets, problems ensue

Posted: Wed Nov 13, 2013 10:17 pm
by HanduMan
My mistake, sorry. I was automatically thinking about isometric tileset because there were amplio units involved. I remember having some kind of extra white space issues with the city dialog on my tileset but I'm sorry to say that I have completely forgotten how they were solved.

Isometric and non-isometric tilesets may well be totally different things and also I've come to understand that freeciv was not made for hex tiles. It's a square world, my friend! :P

Maybe it's not the .tilespec file you should be tampering with. You are using unit (and related) graphics designed for smaller tiles. Maybe you should look for the answer there? Make the grids in the unit graphics files larger to match your tile size?

One thing cought my eye in your text:
Treefingers wrote:For mine, the extra vertical space is to leave room for tall features (forest, mountain, city) to extend above the base tile.
The question is: why? If it is a non-isometric tileset then why would you want to spread anything out of the tule bounds? The isometric/non-isometric is basically a viewpoint issue. With the non-isometric set the viewer is positioned directly over the map so everything should stay inside the tile boundaries and the presented view should be kind of a flattened image. Unless you are plannning some kind of fish eye effect where the trees spread equally over all bounds?

Re: Hex tileset needs very large y offsets, problems ensue

Posted: Wed Nov 13, 2013 11:04 pm
by Treefingers
If it is a non-isometric tileset then why would you want to spread anything out of the tule bounds?
Well, because even though the game distinguishes them as iso and non-iso, for hex tiles it's also a matter of which way the hexagon sits. I don't specifically want a non-isometric view, I want the hexagons sitting as I currently have them. I think they look a lot better in what freeciv calls the non-iso orientation (it also happens to be what civ5 uses, and that's definitely not top-down 2d). And as far as gameplay is concerned, I think it makes more sense to move horizontally in a straight line rather than vertically. :|

Regardless, its a matter of 32 pixels, and probably doesn't even need to be that many. It's not what's making the difference. So it looks to me, since the insane offset gets proportionally worse with bigger tiles, that large non-iso hex tilesets simply aren't feasible at this point. And all it would take to fix things is to give the HP/rank/order icons a proper offset property (or let them share the unit's) and make sure the city management GUI is sized properly. Even better, give each image spec grid its own offset, at least for images that appear on the map.

And I certainly accept that iso and non-iso sets may have some core differences. But what I'm dealing with doesn't really make sense as one of those. It feels more like a bug. I can't imagine why it would be useful to set the offset origin so far from the actual tile, especially in an ostensibly non-iso view. And I can't imagine why there would be no way to adjust some unit/city graphics with offsets, but not others. And I can't imagine why it makes sense to stretch the city management window so much bigger than it needs to be. :?

So many times I try to add some graphic pizazz to a program I like using but looks very dated, and so many times I run into something stupid like this that forces me to set the project aside (see LMMS for another example). Dammit devs, throw artists a bone and they'll make your programs beautiful. Keep the roadblocks up and they'll just move on. :cry:

Re: Hex tileset needs very large y offsets, problems ensue

Posted: Thu Nov 14, 2013 5:48 am
by cazfi
Have you tried to define "unit_width" and "unit_height" (defaulting to values derived from "normal_tile_width"/"normal_tile_height") separately? That feature was originally added for supporting units bigger than normal tile height, but maybe it could be used for making them smaller too.

Re: Hex tileset needs very large y offsets, problems ensue

Posted: Thu Nov 14, 2013 4:48 pm
by HanduMan
cazfi wrote:Have you tried to define "unit_width" and "unit_height" (defaulting to values derived from "normal_tile_width"/"normal_tile_height") separately? That feature was originally added for supporting units bigger than normal tile height, but maybe it could be used for making them smaller too.
How nice it would have been if someone would have documented this in the wiki.

If someone is going to do it, they should also correct what is said about is_isometrcic and is_hex in the booleans section. (Or fix the bug in the SW but that might cause some troubles somewhere.)

Re: Hex tileset needs very large y offsets, problems ensue

Posted: Thu Nov 14, 2013 5:30 pm
by cazfi
HanduMan wrote:If someone is going to do it, they should also correct what is said about is_isometrcic and is_hex in the booleans section.
Dear someone / HanduMan, please enlighten us about what's wrong there, preferable by updating the wiki.

Re: Hex tileset needs very large y offsets, problems ensue

Posted: Thu Nov 14, 2013 5:33 pm
by cazfi
HanduMan wrote:How nice it would have been if someone would have documented this in the wiki.
In this particular case lack of documentation has been intentional, as it's rather experimental feature. Documenting a feature sort of implies that it's supposed to work...