[Ohrrpgce] Desiderata for 16-bit Tilemaps

[James Paige]

On Fri, Dec 1, 2017 at 2:26 AM, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
>
> On 1 December 2017 at 20:08, 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'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.
>>
>> 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.
>>
>> 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.
>>
>> (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?)
>>
>> 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?)
>>
>> 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.
>>
>>
> Another thing: when we support larger (and hence variable sized) tilesets,
> you would have to define what the width of the tileset (in tiles) is when
> you create it, and thereafter enlarge it only by making it taller, because
> enlarging it to the right would change ID numbers.
> ...unless we were to scan through all tilemaps and update their ID numbers.
>
>
Yes, definitely. I like keeping tilemap width fixed at the time it is
created, and only allowing expansion vertically.

Also, suppose you had a 320x600 tileset. Perhaps it was an old tileset that
you have just been adding tiles to.

The map editor could reasonably display it at full window width when you
are picking tiles, that is no problem. Just show each tile in ID-number
order in whatever row-size fits the screen.

When editing tile animations, you would still need to see it at 320x600
because the up/down/left/right motions depend on the 2D-dimentional layout
of the tiles.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20171201/6af139d2/attachment-0001.html>