[Ohrrpgce] Desiderata for 16-bit Tilemaps

James Paige Bob at hamsterrepublic.com
Fri Dec 1 07:02:51 PST 2017


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.


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

I guess allowing more than 255 formation sets is a solid reason to change
the passmap..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20171201/14b97999/attachment.html>


More information about the Ohrrpgce mailing list