On Tue, Apr 1, 2008 at 5:20 PM, Kai Sterker <[EMAIL PROTECTED]> 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 _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel