readme.graphics terrain documentation help

Can you help improve your favourite game? Hardcore C mages, talented artists, and players with any level of experience are welcome!
User avatar
GriffonSpade
Elite
Posts: 578
Joined: Mon Apr 29, 2013 4:41 pm

readme.graphics terrain documentation help

Post by GriffonSpade »

Guys, this piece of documentation from graphics.readme is MASSIVELY obsolete, and outright wrong in several areas. Some of this just isn't documented or even used anywhere at all that I can see, and is just too complicated or specific to intuit. Can we get a fix?
1) Layer entries aren't even in the examples [l0,l1,l2]
2) sprite_type entries are still listed as cell_type
3) "corner" sprite_type is still listed as "rect"
4) Hex requirements aren't mentioned, for example, in matched sprites(where they need n0ne0e0s0sw0w0 or n0e0se0s0w0nw0 formats)
5) No mention of the formats for anything other than unmatched sprites, full sprites matching to their own type, and corner sprites matching to their own type.
Missing Match Synaxes:
a. whole sprite with different match_with and match_type (This one missing in particular is giving me fits since I want to use it. I would be thankful if someone left that information here)
b. whole sprite with match_with and multiple different match_type
c. corner sprite_type with different match_with and match_type (a6b formerly used this for ice shelf matching. format is t.lx.coast_cell_y_z_z_z where x is layer number, y is the corner [u,d,l,r], and z is either the match_with or match_type [anything that is not match_type is automatically considered match_with])
d. corner sprite_type with match_with and multiple different match_type (freeland uses this. format is t.lx.cellgroup_y_z_z_z where x is layer number, y is the terrain's match type, and z is the terrain being matched, either the match type or any of the match with entries; this works somewhat oddly, with the 'anchor' being the bottom corner of the given sprite, then drawing the side corners of the tiles to the bottom-left and bottom-right, and finally the top corner of the cell below; this would require that all the sprites matched with any are matched this way with each other; it's very complicated but gives good tile border blending, since it's actually predrawn on tiles)

Also as a note, the 'iso corners' of hex tilesets don't really 'need' to use the middle value, since they only connect with 2 other tiles there [but assumably are still needed for some reason; just note that you don't need separate sprites for them]

The rest of the file is pretty outdated and full of errors as well, but I don't see any possible way of figuring /these/ things out except to see an extant example or have them explained here.
Here's the section in particular I'm speaking of:

Terrain sprites
---------------
base sprite : If the terrain has no match type or is layered, a
base sprite is needed. This sprite has tag
"t.<terrain>1" (e.g., "t.grassland1"). More than
one such sprite may be given ("t.grassland2", etc.)
in which case one will be chosen at random for each
tile.
matched sprites : If the terrain has a match type or is layered, a
set of matched sprites is needed. This consists of
16 sprites with tags "t.<terrain>_n<V>e<V>s<V>w<V>"
(e.g., "t.hills_n0e0s1w0". Each direcional value
<V> is either 0 or 1. Note that the directions are
in map coordinates, so n (north) in iso-view is
northeast on the mapview. (Note this only applies
for cell_type "single".)
cell sprites : For matched terrains that have cell_type "rect",
32 different sprites are needed. Each sprite is
a rectangle corresponding to one cell, and there are
8 different sprites per cell. Each sprite has
a name like "t.ocean_cell_u110" where "ocean" is the
terrain, "u" means up (north on the map) and
110 indicates which of the adjacent tiles are
mismatched. For instance u110 means

/\
/B \
/\ 1/\
/ A\/C \
\1 /\ 0/
\/D \/
\ /
\/

a matching terrain exists at C but not at A or B. In
this case D is the current tile.

Examples:

; This specifies a civ2-like grassland tile. A single sprite
; t.grassland is needed; it will be drawn blended.
[terrain_grassland]
blend_layer = 1
num_layers = 1
layer0_match_type = 0

; This specifies a civ1-like mountain tile. 16 sprites
; t.mountains_n0s0e0w0 ... t.mountains_n1s1e1w1 are needed. One of them
; will be drawn to match the adjacent tiles. Assuming only mountains
; has this match_type, adjacent mountains will match.
[terrain_mountains]
blend_layer = 0
num_layers = 1
layer0_match_type = 7

; This specifies a civ2-like hills tile. A base sprite t.hills will be
; needed, plus 16 matching sprites. The base sprite will be drawn,
; dithered with adjacent base sprites, and the matching sprite will be
; drawn on top. (In most civ2 tilesets the base sprite is the grassland
; sprite).
[terrain_hills]
blend_layer = 1
num_layers = 2
layer0_match_type = 0
layer1_match_type = 8

; This specifies a civ2-like ocean tile. Ocean is drawn via a cell-based
; system as explained above.
[terrain_ocean]
blend_layer = 1
num_layers = 1
layer0_match_type = 6
layer0_cell_type = "rect"

User avatar
JTN
Elite
Posts: 473
Joined: Wed Jan 30, 2013 12:15 am

Re: readme.graphics terrain documentation help

Post by JTN »

Yes, this badly needs an update. I don't know how anyone figures out how to do tilesets...
I've been sporadically working on an update to this doc for some time. It's going slowly because I don't understand the tileset stuff at all, so I'm having to reverse engineer it all.
User avatar
dunnoob
Elite
Posts: 327
Joined: Mon Dec 23, 2013 3:13 am
Location: Hamburg
Contact:

Re: readme.graphics terrain documentation help

Post by dunnoob »

I'm having to reverse engineer it all.
Ugh. Some details I recall from my own reverse engineering experiments:

The undocumented cellgroup is a hardwired (iso, not hex) hack to handle all land-coastal-deep cases as seen in Amplio(2) ocean.png, notably it covers very rare land-deep, but not completely unlikely glacier-deep corners.

The various hills, jungles, forests, mountains Amplio(2) matches are apparently all unnecessary, just enumerating the say, 14 jungles, to get a random jungle would be more straight forward.

It's hard to figure out which tags are apparently required (= crash or unplayable if not defined) or not really required (= unused, can point to a dummy tile), IIRC some unused tags must be defined, and OTOH some defined tags are both unused and not required.

If I ever get around to work on map2oil I'll drop the cellgroup business together with oceans.png, re-engineering a working Amplio2 is pointless, but getting an improved minimal Amplio could be fun.
User avatar
GriffonSpade
Elite
Posts: 578
Joined: Mon Apr 29, 2013 4:41 pm

Re: readme.graphics terrain documentation help

Post by GriffonSpade »

JTN wrote:I don't know how anyone figures out how to do tilesets...
Copy and adapt, my friend. Find an example where someone else did it and reverse engineer the syntax, though it may take some mental gymnastics and a lot of experience to fully understand it.

It's where I picked up the example d. (from freeland) and c. (from amplio2 ice shelf). What baffles me is that a. and c. even HAVE separate syntax(from the same type-with versions). Why should it matter if the tile is matched with differing terrain? They're still only matched to a single tile, so all other tiles are unmatched.
User avatar
GriffonSpade
Elite
Posts: 578
Joined: Mon Apr 29, 2013 4:41 pm

Re: readme.graphics terrain documentation help

Post by GriffonSpade »

Uh, hey, I just noticed something. Amplio lakes don't get Glacier Ice Shelf drawn onto it like ocean and deep ocean? Is this deliberate?

Also, more on the Cellgroup, it seems that it is set up like this: t.lx.cellgroup_a_b_c_d

. V
. > <
. A

. a
. d b
. c

a is is the top tile's bottom corner (V)
b is the right tile's left corner (<)
c is the bottom tile's top corner (A)
d is the left tile's right corner (>)

...And now I just realized that it isn't drawn simply like that, because I marked all the 'land' parts of the image and deleted the land terrain's graphics (full transparent then) it's not showing any over the land parts. This makes my brain hurt.

This suggests it's actually reading each corner individually, then assessing the 3 corners of other tiles next it, then picking the appropriate corner. This means that anywhere a terrain is mentioned, and also uses this matching scheme, it is ALSO used. That means that even though freeland has a bunch of files, everywhere that arctic, for example, is mentioned that is USED by arctic terrain! It's rather staggeringly complex. It's simultaneously very impressive, and utterly daunting to attempt to use or even alter. Just building one terrain at a time is hard enough, building all of them at the same time is just scary. Peter Arbor's work is damned impressive. Mindbending and huge filesize, but damned impressive.

So it essentially tracks every possible match up for each of the four corners with any combination of neighboring match_type. Each and every single one of them that is mentioned in the list of matches is actually used by that match_type. (Provided it uses the matching scheme. Amplio2 land, for example, does not, so those could be replaced with monochrome lozenges to reduce file size[this is why it already has the ocean blending tiles from the main terrain file for them, replacing them with 50% green tiles only reduces the tile size by 12kb])
dunnoob wrote: The various hills, jungles, forests, mountains Amplio(2) matches are apparently all unnecessary, just enumerating the say, 14 jungles, to get a random jungle would be more straight forward.
These are not random in Amplio2[not counting the underlying background, which is just a simple non-random flat tile], these are full tile match ups. Which sprite it picks depends on the surrounding tiles, specifically they match up to their own types (jungles and forests to jungles and forests, hills and mountains to hills and mountains). Pretty much the backbone of most tilesets use these matches to make like-terrains 'flow' and fit together, rather than having independent stand-alone tiles. For this type, you need a full set of directions, ie one of each combination. So if you have 4 directions, that's 16 different ones needed, while hex has 6 directions, so that needs 4 times as many(64) tile references.[the 16 basic ones without the extra directions, plus with one extra direction, plus with the other extra direction, then plus with both extra directions] (Though I personally just use the basic 4 in a6b, then just have all the ones with the extra directions or not point to the same tile. Making a full set of 64 interlocking tiles would be a HUGE file. Using amplio2's hills and just using multiple per tile works out nicely. Mostly. Have a slight issue, only notable in XU, where weird terrains tab into and behind hills from other mountain types. Not sure how I'm gonna fix it, either with using another layer and just drawing it as part of the hills or maybe a transparency filter where it more quickly becomes transparent.)

As an aside, it seems layer 1 of amplio2 has "mountains" listed as one of the match_type's, even though mountains themselves use "hills".
User avatar
dunnoob
Elite
Posts: 327
Joined: Mon Dec 23, 2013 3:13 am
Location: Hamburg
Contact:

Re: readme.graphics terrain documentation help

Post by dunnoob »

GriffonSpade wrote:I just noticed something. Amplio lakes don't get Glacier Ice Shelf drawn onto it like ocean and deep ocean? Is this deliberate?
I think it's a bug, the missing stuff actually exists in water.png, it just needs corresponding tags, rough idea copied from map2oil (the cell and layer numbers won't match what you have):

Code: Select all

...            
            12, 0, "t.l2.coast_cell_u_w_w_w"
            12, 0, "t.l2.coast_cell_d_w_w_w"
            12, 0, "t.l2.coast_cell_l_w_w_w"
            12, 0, "t.l2.coast_cell_r_w_w_w"
            12, 0, "t.l2.lake_cell_u_w_w_w"
            12, 0, "t.l2.lake_cell_d_w_w_w"
            12, 0, "t.l2.lake_cell_l_w_w_w"
            12, 0, "t.l2.lake_cell_r_w_w_w"
            12, 0, "t.l2.floor_cell_u_w_w_w"
            12, 0, "t.l2.floor_cell_d_w_w_w"
            12, 0, "t.l2.floor_cell_l_w_w_w"
            12, 0, "t.l2.floor_cell_r_w_w_w"
            12, 1, "t.l2.coast_cell_u_i_w_w"
            12, 1, "t.l2.lake_cell_u_i_w_w"
            12, 1, "t.l2.floor_cell_u_i_w_w"
...
            15, 0, "t.l2.coast_cell_l_i_i_w"
            15, 0, "t.l2.lake_cell_l_i_i_w"
            15, 0, "t.l2.floor_cell_l_i_i_w" 
...                                                                            
Everything in the ice-cliff rows gets three tags (coast, lake, floor), one empty cell gets 4*3 tags (coast, lake, floor in four directions up, down, left, right). I use l (land), i (ice) and w (water) for ice matches in this layer.
This makes my brain hurt.
Simplified, as soon as a terrain type participates in some matching for the given layer (0, 1, or 2), it cannot participate in another matching for the same layer. The cellgroup matching contains land, shallow, and floor; that's everything excluding lake, glacier, and inaccessible.
it seems layer 1 of amplio2 has "mountains" listed as one of the match_type's, even though mountains themselves use "hills".
Yes, it makes no sense, another snippet from map2oil including the comments + questions:

Code: Select all

[layer0]
match_types        = "shallow", "deep", "land"

; s shallow        is ocean or lake (t.l0.cellgroup_* or t.l0.lake_*)
; d deep           is deep ocean    (t.l0.cellgroup_*)
; l land           is anything else excl. glacier
;   ice            glaciers matched as shallow (frozen water)

[layer1]
match_types        = "shallow", "deep", "land"

; s shallow        is coastal ocean (t.l1.coast_*), no t.l1.lake_*
; d deep           is deep ocean    (t.l1.floor_*)
; l land           is anything else excl. glacier
;   ice            glaciers matched as shallow (same idea as in layer0)
;   water          replaced by shallow, Map2oil has "w" only in layer2

[layer2]
match_types        = "water", "ice", "mountains", "hills", "forest"

; i ice            for glaciers, ice cliffs with oceans and lakes
; w water          for t.l2.coast_*, t.l2.floor_*, or t.l2.lake_*
; m mountains      for mountains (not for hills as in Amplio2)
; h hills          for hills (not for mountains as in Amplio2)
; f forest         for forest _AND_ jungle, see terrain2.spec                                               
Also see Amplio, various not yet reported bugs corresponding to features I don't yet grok. And sorry, I really don't see where and how the existing forests, jungles, hills, or mountains might be designed for any kind of matching.
User avatar
GriffonSpade
Elite
Posts: 578
Joined: Mon Apr 29, 2013 4:41 pm

Re: readme.graphics terrain documentation help

Post by GriffonSpade »

I think it's a bug, the missing stuff actually exists in water.png
Well, it would be the same exact stuff that coast and floor use in water.png, so that doesn't really mean much. It could've been a design choice.
Simplified, as soon as a terrain type participates in some matching for the given layer (0, 1, or 2), it cannot participate in another matching for the same layer. The cellgroup matching contains land, shallow, and floor; that's everything excluding lake, glacier, and inaccessible.
Freeland does this with SIX terrains. The biggest thing that makes my head hurt is the idea of trying to mentally keep track of what's needed and how to organize that sort of thing. Quite literal exponential expansion here.
Also see Amplio, various not yet reported bugs corresponding to features I don't yet grok. And sorry, I really don't see where and how the existing forests, jungles, hills, or mountains might be designed for any kind of matching.
Erm, I'm not sure how you don't see it? The hills and mountains especially ONLY work at all, ever, if they are matched, otherwise there would be 'stairs to nowhere' effects all over the place. The forests and jungles just have 'projecting' features in directions they connect in. There's actually no randomness to them whatsoever, they always use the exact same sprites to connect in a given set of directions. (Play with the editor in GTK2 and you'll find out really quickly)
User avatar
GriffonSpade
Elite
Posts: 578
Joined: Mon Apr 29, 2013 4:41 pm

Re: readme.graphics terrain documentation help

Post by GriffonSpade »

From that Amplio page, I'd like to point out a few things:
Amplio had match types for mountains, hills, and forest. Amplio2 uses bigger mountains (nice) matched with mountains and (oddly) hills. Amplio2 also matches hills with hills and mountains.
'oddly' probably isn't a good word. Perhaps something more like 'distinctively' instead?
This was likely a design choice, and honestly a good one: Foothills lead up to mountains after all, they're not truly separate from mountains in real life. For most tileset, the problem is getting the dang things to match well when you do that.
These jungles are matched with jungles and forests, likewise the 16 forests are matched with forests and jungles. It's not obvious why forests and jungles are matched at all, for a better random effect it would be simpler to enumerate the 16 forests and 14 jungles without matching
As I said in the last post, it's mostly a matter of 'projection'. You basically don't want a bunch of trees projecting over a terrain that doesn't have any trees, you want to trees to stay a bit away from them to prevent any confusion. Effectively, it's a design choice to do it this way rather than a fully random one. It tends to result in nice flowing foliated areas that don't spill out onto non-foliated terrain.

In A6B, I only actually used 4 different versions for foliage: one with no spillover, one with west spillover, one with north spillover, and one with both north and west spillover.

Actually, looking at it, while the jungles COULD be done to flow like this, they aren't. They're all in random order. That's rather odd. There are also only 6 truly distinct ones here, others are just copies or slightly displaced copies. I see no particular reason why the jungles couldn't just be random enumerations, then. On the other hand, I might see about whipping up a bit better set with what's here for proper projection, and put up something in art and tilesets if I am at all successful.
The forests, however, DO (generally) abide by the projection thing.
Maybe an enumeration would be also good enough for hills and mountains, the GTK2 2.4 client can handle this. (Maybe older clients didn't support this, and the various match types for forest/hills/jungle/mountains were a workaround for a missing feature).
Also as per last post, this simply wouldn't work at all for hills and mountains. These terrains' sprites have 'male' overlying connectors for north and west connections, and 'female' underlying connectors for south and east connections. Effectively, male connectors overlap terrains in those directions, and female ones are hollow and they stick together like bridges. If you try to use them randomly, it will look very, very wrong. In fact, doing that yourself to see actually wouldn't be hard to do. Just comment out amplio2's match_with, and then go to hills.spec and copy-paste these entries into it. (Only changes the various matched entries into simple enumeration, I made these changes in under 2 minutes. Mountains would be even worse.)

Code: Select all

 0,  0, "t.l1.hills1"
 0,  1, "t.l1.hills2"
 0,  2, "t.l1.hills3"
 0,  3, "t.l1.hills4"

 1,  0, "t.l1.hills5"
 1,  1, "t.l1.hills6"
 1,  2, "t.l1.hills7"
 1,  3, "t.l1.hills8"

 2,  0, "t.l1.hills9"
 2,  1, "t.l1.hills10"
 2,  2, "t.l1.hills11"
 2,  3, "t.l1.hills12"

 3,  0, "t.l1.hills13"
 3,  1, "t.l1.hills14"
 3,  2, "t.l1.hills15"
 3,  3, "t.l1.hills16"
Amplio2 uses a nuke based on the old trident tileset nuke.
Actually, Amplio2 has its own unique nuke at this point. As far as I know, it's not 'based' on trident's.
cazfi
Elite
Posts: 3093
Joined: Tue Jan 29, 2013 6:54 pm

Re: readme.graphics terrain documentation help

Post by cazfi »

Nuke blast of both Trident and Amplio2 was last updated 2013 (first release with new gfx was 2.4.1)
User avatar
JTN
Elite
Posts: 473
Joined: Wed Jan 30, 2013 12:15 am

Re: readme.graphics terrain documentation help

Post by JTN »

JTN wrote:I've been sporadically working on an update to this doc for some time. It's going slowly because I don't understand the tileset stuff at all, so I'm having to reverse engineer it all.
Since it's not doing anyone any good buried in my git, here's my half-finished WIP, as-is (circa February).

Beware that it may contain misunderstandings, and is surely incomplete, and probably still has old stuff that needs cleared out.

It's written for trunk. I think it's good for 2.6. Details won't apply to 2.5, but I expect general concepts will.

Any corrections welcome.
Attachments
54254ed-README.graphics-WIP.txt
jtn's work-in-progress update to doc/README.graphics, warts and all
(28.52 KiB) Downloaded 273 times
Post Reply