On Tue, Dec 14, 2010 at 05:17:20PM +0100, Johanna Ploog wrote:
> On 14 December 2010 15:48, Adam Borowski <kilob...@angband.pl> wrote:
> > This behaviour is a bug that trashes vaults. In particular, the Cigotuvi's
> > Wizlab turns into a random dungeon level, all features with custom tiles get
> > rendered into their base, and so on.
>
> That's an entirely different issue, and I don't think it's as big as
> of a problem as the one Raphael mentioned. After all, how often do you
> actually switch between console and tiles for non-debug purposes? The
> levels ending up all black was a bug that badly needed fixing, wizlabs
> looking not as great as they should is a nuisance, but not remotely as
> bad.
We'd need to do this anyway for nettiles.
> On the other hand, we do add new dungeon tiles on a semi-regular
> basis, so invalidation of already existing levels happens quite often.
>
> Storing tiles strings (instead of numbers) would fix both of these
> issues, but would bloat the save file nastily.
Here's a crazy idea: what about instead saving a hash of the filename? It
doesn't have to be long, 32 bits (like crc32) would be okay. With 32 bits,
clashes are possible but unlikely -- due to the birthday paradox you can
expect one clash with 64K tiles, we have a tiny fraction of that. It
wouldn't be a perfect solution but only the clashed tiles could break, and
only when you remove or add one of that specific pair.
> As an alternative, Adam's thoughts on deciding tiles deterministically
> would solve the tiles shifts. The dungeon might still look different
> whenever new tiles get added, but at least it would be guaranteed to
> look *sane*. The tricky part would be to come up with an algorithm
> that does not produce weird artefacts in the look of the dungeon, with
> a variety of tile sets of different weights and numbers.
About any good hash would be ok. For example, any cryptographically strong
hash must be good -- but the requirement is far, far less strict.
If this is unclear, here's a sample hash:
* on level generation, save a seed
* h(seed,x,y) is x+y*GXM th iteration of MT19937 for the seed
I guess you can see why this wouldn't produce artefacts weirder than we have
now ☺
This would mean that only explicitely specified tiles would have to be saved
-- be it that by the filename or a crc of it.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Crawl-ref-discuss mailing list
Crawl-ref-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
