On Tue, Dec 14, 2010 at 09:37:20PM +0100, Johanna Ploog wrote:
> On 14 December 2010 20:53, Adam Borowski <kilob...@angband.pl> wrote:
> > We'd need to do this anyway for nettiles.
>
> What's the timeline for that?
Sadly, no idea.
> >> 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?
>
> Do you mean the tile name? Because I don't know what file you might be
> talking about. Knowing that the tile is part of dngn.png is unlikely
> to be helpful. :)
Of kors :)
> If you mean the stringified enum that also is used for vault
> definitions, how is that a crazy idea?
This stays unchanged, right?
> > 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.
>
> Why only then? Wouldn't that mean that you couldn't distinguish
> between the pair of them? (As you can see I haven't got a clue.)
As in flat hash tables -- you can either add one, or, to avoid large spills
(irrelevant for us), subsequent squares or a secondary hash.
But then, I realized that this may be an overkill, and it wouldn't be that
costly to produce a "palette" of tiles present on the level. It appears
that most levels have only 10ish distinct tiles, and hardly ever more than
20. Storing a list of that 10-20 names wouldn't be too bad.
> >> 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*.
> >
> > 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 ☺
>
> That's a convincing argument, indeed. However, I'm still hazy on the details.
>
> I guess what happens is the following:
> 1. On level load, we reinitialize the entire map with tile flavours
> for floor, wall, features (as is currently done on level generation).
> For this, we use this hash(level.seed, x, y). These values are stored
> in memory but are not written into the save file.
> 2. Some new tiles get added to trunk, a lot of enums are shifted around.
> 3. A saved game is loaded, and tile flavours are reinitialized as
> before and, though with different values, still matching floor, wall,
> etc.
Mostly, yeah. We still need to save tiles that have been explicitely
modified, but this way the rest (ie, everything on the level in a vast
majority of cases) can be tossed away.
--
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
