next »

[Fallsburg]

Well, you would do something like:

1 | 2 | 4
8 | # | 16
32| 64| 128


Now, if you think about this, this means that you should need 256 different tiles, but luckily as shown in the article, you only need 47.  The tricky part comes from figuring out where the overlap is.  If anyone is interested, I can supply AS3 code to go from the tilesum (as I refer to the sum of all of the bitmasks) to the tile index (assuming that all the tiles are in one row, going from left-to-right, top-to-bottom as seen in the tilemap from the article).

[Eendhoorn]

But this would leave huge gaps in your tilesheet right? Since your only using 47 of the 256 spots in your tilesheet. That doesn't really seem like the way to go.

[Fallsburg]

Huh? No.  Not sure what to say other than the fact that you aren't getting it.

[Eendhoorn]

Well if you only need 47 tiles but the max value you can get is 256, then that would mean that you have 256 minus 47 free spots that you are not going to use :/
It could be that I'm not understanding correctly though.

[Fallsburg]

No, you just have 47 tiles.  As I said, there are 256 possibilities, but due to the nature of how it actually winds up looking, only 47 of those are unique.  So, you have a tilemap with 47 tiles.  That's it.

[BorisTheBrave]

Simply add up the values as fallsberg indicated, then look up the tile index in this table:

Code:

0 0
1 1
2 2
3 2
4 3
5 4
6 2
7 2
8 5
9 5
10 6
11 6
12 7
13 7
14 6
15 6
16 8
17 9
18 10
19 10
20 8
21 9
22 10
23 10
24 11
25 11
26 12
27 12
28 11
29 11
30 12
31 12
32 13
33 14
34 15
35 15
36 16
37 17
38 15
39 15
40 5
41 5
42 6
43 6
44 7
45 7
46 6
47 6
48 18
49 19
50 20
51 20
52 18
53 19
54 20
55 20
56 11
57 11
58 12
59 12
60 11
61 11
62 12
63 12
64 21
65 22
66 23
67 23
68 24
69 25
70 23
71 23
72 26
73 26
74 27
75 27
76 28
77 28
78 27
79 27
80 29
81 30
82 31
83 31
84 29
85 30
86 31
87 31
88 32
89 32
90 33
91 33
92 32
93 32
94 33
95 33
96 21
97 22
98 23
99 23
100 24
101 25
102 23
103 23
104 26
105 26
106 27
107 27
108 28
109 28
110 27
111 27
112 29
113 30
114 31
115 31
116 29
117 30
118 31
119 31
120 32
121 32
122 33
123 33
124 32
125 32
126 33
127 33
128 34
129 35
130 36
131 36
132 37
133 38
134 36
135 36
136 39
137 39
138 40
139 40
140 41
141 41
142 40
143 40
144 8
145 9
146 10
147 10
148 8
149 9
150 10
151 10
152 11
153 11
154 12
155 12
156 11
157 11
158 12
159 12
160 42
161 43
162 44
163 44
164 45
165 46
166 44
167 44
168 39
169 39
170 40
171 40
172 41
173 41
174 40
175 40
176 18
177 19
178 20
179 20
180 18
181 19
182 20
183 20
184 11
185 11
186 12
187 12
188 11
189 11
190 12
191 12
192 21
193 22
194 23
195 23
196 24
197 25
198 23
199 23
200 26
201 26
202 27
203 27
204 28
205 28
206 27
207 27
208 29
209 30
210 31
211 31
212 29
213 30
214 31
215 31
216 32
217 32
218 33
219 33
220 32
221 32
222 33
223 33
224 21
225 22
226 23
227 23
228 24
229 25
230 23
231 23
232 26
233 26
234 27
235 27
236 28
237 28
238 27
239 27
240 29
241 30
242 31
243 31
244 29
245 30
246 31
247 31
248 32
249 32
250 33
251 33
252 32
253 32
254 33
255 33

[Fallsburg]

Thank you boris.

[Eendhoorn]

f anyone is interested, I can supply AS3 code to go from the tilesum (as I refer to the sum of all of the bitmasks) to the tile index (assuming that all the tiles are in one row, going from left-to-right, top-to-bottom as seen in the tilemap from the article).

I've been looking into the 47 tiles based completion with a friend. And we understand everything except how Boris came up with the lookup table. So yeah, we're pretty curious how that convertion is handeled

[BorisTheBrave]

Ok, I don't actually remember how I did it either now   Magic, I suppose.

I think basically, for each solid corner, I changed it to empty unless both the adjacent tiles were solid, as that's the only time you get any choice in what the corner is. You're left with 47 combinations, which I renumbered. I might have done it manually though, not sure.

BTW, if you liked that, you might like the tool I released this week for creating blob tilesets.

https://github.com/BorisTheBrave/resynth-tiles/wiki/Tutorial

[Macunfadebo]

I don't have transitions in my game
it's kinda weird but I don't care

[Abraxas]

And the result is so indie.

[darkhog]

Question for Sam: How would you handle "autotiles" broken into 48 possible tiles, as RPG Maker does it:


Your system wouldn't work for tiles build from sides (to achieve more variety) as it only counts for 16 tile types.

[Dacke]

You mean that you have several versions of each type? So 4 different left-tiles, 4 different right-tiles etc.

Just compute the numbers like Sam showed. If you (for example) get number 7, just pick one of the left-tiles at random.

[darkhog]

Sam's solution only takes care for 16 tiles, whereas to make perfect autotile you need 47, like it was explained on second page of this thread.

I'm not thrilled about:

Code:

1  2  4
8  #  16
32 64 128

because it gives you too much cases to check against. I need something clean.

//edit: TL;DR: Sam's solution will take care of this:

Code:

____
|...
|...
|...

but not this (for example):

Code:

____
|..|
|..|
|..|

[Dacke]

Ah, I see what you mean.

You'll get 256 unique numbers, but many of them will map to the same tiles. So you'll just have to figure out which numbers should be remapped.

Then either do some clever bitwise stuff (if you find a pattern), or do something simple like:

Code:

if (n == 92 || n == 213 || n == 233) {
   n = 45;
}

[Crimsontide]

You could do it with less.  For 2D tiles you could get away with 'perfect' transitions with 15 tiles.

The technique is similar to the marching squares algorithm (aka, a 2D marching cubes).  Instead of drawing the tiles + the boundaries, draw your tiles at the intersection (ie. offset 1/2 a tile in the x/y direction) of the underlying map.  So if the underlying map is say 32x32, then you would draw 31x31 tiles.

So say were drawing the grass.  Each tile drawn samples/reads from its 4 corners.  Each of the 4 corners is either 'in' (is grass) or 'out' (not grass).  This gives us 16 possible cominations.  All 1's is a solid tile of grass no transitions.  All 0's is an empty tile.  Every other combination is some sort of transition.

All the tiles you would need will look something like:


So each tile type/layer would only need 15 unique tiles, and you have 'perfect' edges/transitions.  The offset would require a change in drawing logic/code, but player/game logic can still operate as it would (ie. players or enemies or what-have-you do not need to be offset or this applied in any way).

[darkhog]

hm... I think I'll just write autotile breaker and just place them by hand.

[Fallsburg]

Crimsontide, you are wrong.  You are only considering corners.  You need to consider corners and edges.


For examples (X is filled, O is empty)

OXO
XXX
OXO

and

XXX
XXX
XXX

Your algorithm will use the same tile for the middle tile, but the 47 tile solution will handle it correctly.

If people really, really, really want my ugly ass mapping of

1 | 2 | 4
8 | . | 16
32|64 |128
to the 47 tiles, I can produce it, but it is ugly as fuck.

[Crimsontide]

No you see Fallsburg you're not considering the offset.  Ok imagine your map looks something like this:

00010
01111
01222
11222

0 is ocean, 1 is sand, 2 is mountain.  In your version 20 tiles are drawn to the screen per terrain type.  In my version only 12 per terrain type.  

Now to keep things clear, lets call the tiles being drawn to screen rects, and the tiles in the underlying map tiles.  As you'll see the two are different, which is what makes the algorithm different.

So we have the map and now were going to draw it to screen.  Ocean is laid down first, no need for transitions or what-have-you since its the background/bottom.  Now we draw the first rect.  The first rect is the intersection of the tiles at coordinates (0,0), (1,0), (0,1), (1,1).  The tile values for this rect are 0, 0, 0, 1.  This corresponds to case 4, so we draw the sand texture at case 4.  The next rect to be drawn to the right then is the rect which intersects tiles (1,0), (2,0), (1,1), (2,1), with values 0, 0, 1, 1.  This would correspond to case 12.  The next tile to the right has coordinates (2,0), (3,0), (2,1), (3,1), with values 0, 1, 1, 1 which is case 14.

The case values for sand then drawn to the screen would be (in hex to keep formatting easy in text):

4CED
6B33
E900

The '4' rect straddles the first 4 map tiles.  The 'C' rect straddles the next 4 map tiles.  The '4' rect and the 'C' rect touch along their left and right edges respectively.  The '6' rect and the '4' rect touch along their bottom and top edges respectively.  Is this starting to make sense or perhaps a visual...

Or maybe consider this random image from google:

I'm not sure why there is an a and b, and ignore the Q's.  But imagine that the tiles in the map are the solid shaded boxes, and the rect being drawn to screen, is the box with a dotted edge.  Each drawn rect intersects 4 map tiles.  Because of this there are no edge cases to consider, only corner cases.  In fact the edge cases aren't even needed because they are already taken care of implicitly.

The only real draw back is that you 'lose' 1/2 a tile on each edge of the entire map, but this is really a negligible drawback.

[Fallsburg]

Ah, sorry misinterpreted the image (and didn't really read the post).

In that case, I guess the biggest problem is that you split up your tiles into quarters making larger patterns (on the scale of a full tile) impossible.  That's a minor "problem", but something to be aware of. Also, it assumes that tiles must be able to be split into quarters, again probably not a major concern, but something to be aware of.