[Ohrrpgce] Desiderata for 16-bit Tilemaps

[Ralph Versteegen]

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

>
> 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.
>

Doing the fixup automatically is doable (but wouldn't fix your scripts);
but it's extra work to implement, so can be put off until later/never.

>
> 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.
>

That doesn't sound like a good idea; it would break the ability to copy a
block of tiles off the tileset.


> 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.
>

I think it's very rare that tile animations go over the tileset edge, so it
doesn't matter if could resize your tileset to the right and cause them to
break - even if they did, you would just fix them.

Relatedly, it's way too much trouble to create tile animations. Maybe we
could have a "simple mode" which is just "loop X tiles to the right, Y
ticks per tile". Alternatively, that could be a new two-parameter op code
(I plan to add such an op code to sprite animations).


>
>
>
> _______________________________________________
> 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/3ff60c37/attachment-0001.html>