<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 2 December 2017 at 04:02, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com" target="_blank">Bob@hamsterrepublic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><div>I think I agree. Bigger tilesets should be simpler than multiple tilesets on a layer.<br></div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><div>Agreed. The current structure is just an artifact of how it was implemented in the old asm allmodex code.<br></div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><div>That sounds good!<br></div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span class="gmail-"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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></div></blockquote><div><br></div><div>Oh, using tile IDs <span class="gmail-">8192-16383 for animated tiles instead of being flexible in the ID range would be a nuiscance for backcompat. As long as we allow tiles 160-255 to be mapped via the lookup table, all existing games will be unchanged.</span></div><div><span class="gmail-">But If tiles 160-255 are animated, how can you increase the tileset size in existing games?</span></div><div><span class="gmail-">I'm leaning towards always internally translating existing animated tiles up to 8192+, and adding a backcompat bit which makes the script commands continue to work on tiles 160-255 and which you need to turn off in order to be able to increase tileset size.</span></div><div><span class="gmail-">Few games will do any scripting that touches animated tiles, and mostly they will either be using hardcoded IDs for writemapblock (in which case their scripts will need updating) or they will use the animated tile script commands (which we can update).<br></span></div><div><span class="gmail-"><br></span></div><div><span class="gmail-"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span>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></div></blockquote><div><br></div><div>If we had 16 bit wallmaps, I would have used a bit for one-way walls instead of using a zone. It would have been far easier and would have worked much better (to get one way walls to act like other wall data when you're drawing walls, I'm actually going to have to internally translate them into wall bits in the map editor anyway). And I'm considering making read/writepassblock transparently treat it as a wall bit too, so possibly might just use upgrade() to translate it.<br></div><div>So it would be good to expand wallmaps to 16 bits in anticipation of the next time we have a use for them.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><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>
<br>______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.<wbr>org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" rel="noreferrer" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
<br></blockquote></div><br></div></div>