[Ohrrpgce] Desiderata for 16-bit Tilemaps

[Ralph Versteegen]

On 2 December 2017 at 04:02, James Paige <Bob at hamsterrepublic.com> wrote:

>
> On Thu, Nov 30, 2017 at 11:08 PM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>> We want to move to (at least) 16 bits per tile, to enable larger tilesets.
>> This will also allow and require the tile animation system to be upgraded
>> as
>> well, so the question is how should we make use of 16 bits of tile space?
>>
>> (Features like parallax and using backdrops as map layers are
>> separate from this question, though involve replacing other parts of the
>> map
>> file format. Non-20x20 tiles is also completely separate.)
>>
>> We could even support using multiple tilesets per map layer, though you
>> would
>> have to specify which ones you want. But after originally being keen on
>> that
>> years ago, it now sounds like too much complexity.
>>
>>
> I think I agree. Bigger tilesets should be simpler than multiple tilesets
> on a layer.
>
>
>> I'm not a fan of the animation ranges of the tile animation patterns. It's
>> very wasteful, since only a few of those tiles are likely to be animated,
>> while the rest are garbage, and when you try to use the tile picker to
>> pick
>> an animated tile, you have a lot of painful to look at garbage animated
>> tiles
>> to ignore.  The wastefulness is also the reason that we're limited to
>> just 2
>> patterns and 160 tiles.
>>
>>
> Agreed. The current structure is just an artifact of how it was
> implemented in the old asm allmodex code.
>
>
>> Instead, I propose using an extra layer of indirection between tile IDs
>> and
>> animation patterns, in the form of a palette of animated tiles.  Tile
>> animation patterns would be the same, except that you will no longer
>> define a
>> range for them. Instead, each pattern can be applied to any tile, and
>> there
>> no longer needs to be a limit on number of patterns.
>>
>
> That sounds good!
>
>
>> You could say which tiles in the tileset can be animated with which
>> pattern,
>> and those animated tiles get added as *additional* tiles to the tileset.
>> These could be shown in the tileset editor right below the static tiles
>> Then
>> in the map editor you can pick those animated tiles direct from the
>> tileset,
>> or continue to press 1, 2, 3, etc. to turn a tile into the animated
>> version.
>> If you try to turn a tile into an animated one but it's not yet in the
>> tileset, you could be prompted to add it. It should also be possible to
>> delete an animated tile, leading to unallocated gaps.
>>
>
> Okay, I think I follow so far. That sounds like it would be cleaner, and
> could keep compatibility with existing  animations in older games.
>
>
>
>> (This leads to some questions: in case you want to swap tilesets, should
>> you
>> be able to reorder, copy, and delete animated tiles, so that you can cause
>> their ID numbers to be the same in different tilesets? Should unallocated
>> animated tiles be shown, so that you can copy into them? Should
>> writeblock be
>> allowed to write unallocated tile IDs?)
>>
>
> Maybe yes to all of those?
>
> 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.
>

Oh, using tile IDs 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.
But If tiles 160-255 are animated, how can you increase the tileset size in
existing games?
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.
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).



>
>>
>> We could also reserve some space for future use. I don't know yet what
>> that
>> might be... multiple tilesets per layer? visual filters?
>>
>> I'm thinking something like:
>> 0-8191 : regular tiles (max tileset size)
>> 8192-16383 : animated tiles
>> 16384-65535 : unallocated
>> And a lookup table of 8192 animated tiles, with tile ID and pattern ID
>> for each.
>> (8192 should be enough for anybody.... right?)
>>
>
> 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.
>
>
>>
>> Also, for consistency we might as well upgrade passmaps and foemaps to
>> 16bit
>> at the same time. Making use of the extra wall bits for angled or partial
>> walls
>> is a much more difficult question.
>>
>
> 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.
>

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.
So it would be good to expand wallmaps to 16 bits in anticipation of the
next time we have a use for them.

>
> I guess allowing more than 255 formation sets is a solid reason to change
> the passmap..
>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20171202/4330a6d0/attachment.html>