[Ohrrpgce] Desiderata for 16-bit Tilemaps

[James Paige]

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

>
>
> 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).
>
>
>
That sounds like a good plan. The backcompat bit for writemapblock seems
like a reasonably solution.


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

Okay, I am convinced. I didn't want them expanded for no reason but being
able to use them for one-way walls is a perfectly good reason. :)


>
>> 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
>>
>>
>
> _______________________________________________
> 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/20171201/a98b005b/attachment.html>