[Adonthell-devel] Re: Flaws in the current map implementation

[Kai Sterker]

On Tue, Apr 1, 2008 at 5:20 PM, Kai Sterker <address@hidden> wrote:

More thinking out loud ... but feel free to throw your ideas into the mix.

>  Also, the part where it all comes together (area::thing_manager) does
>  not easily mix objects with and without gfx and its not really
>  possible to load the gfx of an object once it becomes required by a
>  map view (or unload it again later).
[...]
>  Another idea could be to have a default empty renderer, that only
>  waits for the first call to its draw method to instantiate the real
>  render which loads the sprite and draws it. The cleanup would still
>  have to be done by the mapview though.

When trying to figure out, how the map view could possibly free up
unused sprites, an old idea suddenly came back. Split the map into
zones and use them to cache sprites. Once a number of zones have been
visited, start cleaning up the oldest, thus freeing all sprites used
in that zone.

Then, on top of that another issue occurred to me. I had naively
implemented the map view in the same fashion as in the v0.3 engine.
The problem here is that objects will be visible in the view, even
though their base tile (triggering the rendering) is outside the view.
We can catch that, as all tiles covered by the object have a reference
to it. So we know it is there, figure out whether its base tile is
outside the view and draw it accordingly. Some overhead, but working
reasonable well, I guess. At least for v0.3, where objects where
always resting on the ground. Now, we have objects "floating" in the
air, however. This means, the object could be in the view, but the
tiles occupied by the object might not ... there is no way the view
could possibly know that it needs to render this object. How do we
solve that?

Back comes the zone idea. Maybe we can combine the two problems and
find a common solution. What if we construct all zones as we add
objects to the map? In contrast to the actual map that contains the
real position of objects (for collision detection, path finding,
etc.), each zone would contain the position where objects have to be
rendered. As objects come into view, their associated sprite can be
loaded, and as zones get "stale", sprites used in that zone can be
freed again. Moreover, the renderer can simply draw whats there
without having to worry about objects overlapping borders of the view.

Any disadvantages? Two representation of the map that need to be kept
in sync, as objects are placed or removed (think items) or characters
and creatures move about. Not such a big deal, if both are kept by
inside the area class, transparent to the outside world.

As an additional advantage, it would also offer a nice way to handle
non-solid objects (as discussed in this thread:
http://lists.nongnu.org/archive/html/adonthell-devel/2007-12/msg00003.html).
Simply do not add them to the "physical" map structure, only to the
rendering zones.

We'd also be free to decide which data structure would be best for
rendering. The grid makes sense for path finding and collision
detection, but maybe there's something more suitable to render
objects.


Have to think about all this some more (vacation is really a good
opportunity for that) ... but it looks like a step in the right
direction to me.

Kai