<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 30, 2017 at 11:08 PM, Ralph Versteegen <span dir="ltr"><<a href="mailto:teeemcee@gmail.com" target="_blank">teeemcee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We want to move to (at least) 16 bits per tile, to enable larger tilesets.<br>This will also allow and require the tile animation system to be upgraded as<br>well, so the question is how should we make use of 16 bits of tile space?<br><br>(Features like parallax and using backdrops as map layers are<br>separate from this question, though involve replacing other parts of the map<br>file format. Non-20x20 tiles is also completely separate.)<br><br>We could even support using multiple tilesets per map layer, though you would<br>have to specify which ones you want. But after originally being keen on that<br>years ago, it now sounds like too much complexity.<br><br></div></blockquote><div><br></div><div>I think I agree. Bigger tilesets should be simpler than multiple tilesets on a layer.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm not a fan of the animation ranges of the tile animation patterns. It's<br>very wasteful, since only a few of those tiles are likely to be animated,<br>while the rest are garbage, and when you try to use the tile picker to pick<br>an animated tile, you have a lot of painful to look at garbage animated tiles<br>to ignore.  The wastefulness is also the reason that we're limited to just 2<br>patterns and 160 tiles.<br><br></div></blockquote><div><br></div><div>Agreed. The current structure is just an artifact of how it was implemented in the old asm allmodex code.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Instead, I propose using an extra layer of indirection between tile IDs and<br>animation patterns, in the form of a palette of animated tiles.  Tile<br>animation patterns would be the same, except that you will no longer define a<br>range for them. Instead, each pattern can be applied to any tile, and there<br>no longer needs to be a limit on number of patterns.<br></div></blockquote><div><br></div><div>That sounds good!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You could say which tiles in the tileset can be animated with which pattern,<br>and those animated tiles get added as *additional* tiles to the tileset.<br>These could be shown in the tileset editor right below the static tiles Then<br>in the map editor you can pick those animated tiles direct from the tileset,<br>or continue to press 1, 2, 3, etc. to turn a tile into the animated version.<br>If you try to turn a tile into an animated one but it's not yet in the<br>tileset, you could be prompted to add it. It should also be possible to<br>delete an animated tile, leading to unallocated gaps.<br></div></blockquote><div><br></div><div>Okay, I think I follow so far. That sounds like it would be cleaner, and could keep compatibility with existing  animations in older games.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">(This leads to some questions: in case you want to swap tilesets, should you<br>be able to reorder, copy, and delete animated tiles, so that you can cause<br>their ID numbers to be the same in different tilesets? Should unallocated<br>animated tiles be shown, so that you can copy into them? Should writeblock be<br>allowed to write unallocated tile IDs?)<br></div></blockquote><div><br></div><div>Maybe yes to all of those?</div><div><br></div><div>I feel like writeblock to turn animation off and on as well as the other tile animation related scripting commands are going to present the biggest compatibility challenge.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>We could also reserve some space for future use. I don't know yet what that<br>might be... multiple tilesets per layer? visual filters?<br><br>I'm thinking something like:<br>0-8191 : regular tiles (max tileset size)<br>8192-16383 : animated tiles<br>16384-65535 : unallocated<br>And a lookup table of 8192 animated tiles, with tile ID and pattern ID for each.<br>(8192 should be enough for anybody.... right?)<br></div></blockquote><div><br></div><div>Hehe! Famous last words! But it should be just fine for our purposes. An embarrassment of riches for people used to being limited to 160 tiles.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>Also, for consistency we might as well upgrade passmaps and foemaps to 16bit<br>at the same time. Making use of the extra wall bits for angled or partial walls<br>is a much more difficult question.<br></div></blockquote><div><br></div>I don't think "consistency" is a good reason for 16 bit foemaps and passmaps. We shouldn't change those until we have a feature that needs it.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I guess allowing more than 255 formation sets is a solid reason to change the passmap..<br></div><br></div></div>