On 14 December 2010 20:53, Adam Borowski <kilob...@angband.pl> wrote: > On Tue, Dec 14, 2010 at 05:17:20PM +0100, Johanna Ploog wrote: >> 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.
What's the timeline for that? >> 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. :) If you mean the stringified enum that also is used for vault definitions, how is that a crazy idea? > 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 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. Sounds great! :D How about you handle storing the seed and setting up a nifty hash, and I make sure that the tiles version makes good use of them? > This would mean that only explicitely specified tiles would have to be saved > -- be it that by the filename or a crc of it. Yes. Shouldn't happen too often... still, crc is probably better - some of the vaults modify a lot of floor tiles (e.g. forest_paths, some temples), and storing all these as strings strikes me as redundant. Johanna ------------------------------------------------------------------------------ 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
