Re: [Adonthell-devel] map structure

[Kai Sterker]

On Sat, 6 Jul 2002 20:42:13 +0200 Alexandre Courbot wrote:

> Waste's Edge map is only 3222 bytes because it's compressed with gzip.
> In a usable form, it already takes much, much more! :)

True. But as disk access would be the most crucial operation, it's
important that there isn't much data to read from disk. Unzipping
shouldn't be a problem. And if it takes a few 100K in memory afterwards
doesn't matter much. 

  
> Most modern operating system offer a powerful caching system, but of
> course what takes the more time in mapobjects loading is image
> decoding. So having our own cache system would be an excellent idea.
>
> The interesting thing about mapobjects, especially on the server side,
> is that terrain occupation is separated from graphics. That to enable
> a server to run without useless graphics. So I guess we can keep many
> mapobjects in memory in the case of a server, which would be great
> considering the much more important requirements.

That's good.


> I'm against using another thread. There are good reasons to think that
> the map that will be loaded uses the same mapobjects as the one next
> to it, plus maybe a few ones. So loading shouldn't hurt much. Using a
> thread won't help anyway, as the player couldn't progress as long as
> the map isn't completely loaded, so the result would be the same! It
> would be dangerous otherwise. Imagine a player that moves very (very!)
> fast, he could arrive at the new map area before it is completely
> loaded. I prefer to play on security here.

You're right. Using another thread probably causes more problems than it
solves. 

> We'd need a global coordinate system, sure. But maybe the maps
> themselves could use relative coordinates, while every map has a
> global coordinate - that way coordinates would be translated. Don't
> know if this could be useful however! :)

Might help to save a bit of space. As the map areas are rather small, 8
bit would be enough for local coordinates. That'd be the only benefit I
can think of. There could be others though ... 

> Yes, but there's something that worries me a little bit here: what if
> a mapobject is split between two maps? I guess we can handle this
> correctly, provided the two maps are always loaded when the map object
> is used (and this will probably always be the case). Need further
> thoughts anyway.

That shouldn't happen. Inmidst the map, the player will never reach the
edge of the part that is kept in memory. And no objects would overlap
the actual edge of the map, I guess.


> Mmm not exactly. Every square a mapobject is on has a reference to it
> and his relative position from the square. But well, there is
> certainly a clean way to handle this.

Ah, okay. That makes it somewhat more difficult. 


> > Map structure in memory:
> > Again I assume that the map in memory is some sort of array of
> > maptiles. That of course means that as new areas are loaded and old
> > ones are removed, there needs to be a way to insert new areas at the
> > proper positions. That probably involves some moving around of array
> > content. However, that should be pretty fast, as the array wouldn't
> > be large.
> 
> How about the map file structure? You proposed to split it into
> multiple files, but since they have no reason to exist without others
> (as they are a whole), maybe it would be better to save the whole map
> into a single, indexed file for fast access to map parts. This could
> even be slightly faster, as you wouldn't need to open/close files all
> the time.

Sure, that would also work. The index could be loaded once and kept in
memory, so accessing the proper part of the file would be fast. You
could even keep the file open all the time. However, the file can't be
compressed then. (To read byte n you'd need to decompress all the n-1
bytes before). However, the individual mapareas could be compressed in
memory before writing them to the file. Or we could simply store it
uncompressed.  
 
> Great! I'm reading through my image synthesis lessons, which contain
> interesting information for 3D collisions and rendering. So even
> though these two parts are map related, we have no chance to conflict!
> :)

Good. That'll be something interesting to work on. :)

Kai