Here's the original idea:
http://lists.gnu.org/archive/html/adonthell-devel/2009-08/msg00013.html
The question is, how can we implement the second suggestion in the
thread above? Here are the specific problems to solve:
1. How do we find the correct render zone? What is our refenerce
point? What to do about overlapping zones?
2. Assuming we have our zone (will it only be one?), how to
efficiently discard everything below/above?
3. Should we actually discard anything below the zone?
Input on these questions welcome. Mine's below:
1. To find the correct render zone, we'll need a reference point.
Originally, I suggested that the mapview itself would provide the
reference point. So for a normal mapview schedule, the reference point
equals the position of the player character. That should be fine, but
I see one problem: when walking upstairs, the upper floor should come
into view as soon as the character's head pops through the ceiling.
But the view is always centered on the character's feet. So from the
mapview schedule, we must be able to specify a z-offset for the
reference point.
With the reference point, we can now find all the zones containing
this point. The case where there is now zone is the simplest.
Rendering occurs just like it does now. If we only have on zone, it's
fairly easy too. We can make one pass over the objects inside the view
and do:
for every object:
if object below or above zone: # --> candidate for removal
if object is not east or south or west or north of zone
discard object
The problem is, what happens if we get multiple zones back? Can we
simply execute the algorithm above for every zone? That means, the
smallest zone would decide which objects are visible. Or should we
rather display an object if it is in one zone at least:
for every object:
discard = true
for every zone:
if object below or above zone: # --> candidate for removal
if object is not east or south or west or north of zone
discard &= true
if not discard: break
if discard:
discard object
With this algortihm, only objects are discarded that are not in any
zone. If we'd sort zones by decreasing size before applying the
algorithm, we could possibly improve performance as it would be more
likely that an object is contained in a large zone, saving us the
check of smaller zones in that case.
All this code would be part of the mapview and filter the list of
visible objects before it is passed to the renderer.
This should answer points 1 and 2 sufficiently.
As for point 3: Not rendering what is below a zone might improve
performance, but it might also look strange, if stairs leading down
suddenly disappear because they will be below the floor of the current
zone. So on second thought, I believe it makes no sense. We'd be
better off to implement hidden surface removal in the renderer
instead.
So the only thing that render zones will do is pop off the roof when
entering the interior of a cave or building. Should be simple enough
to implement in a naive way, with room for future optimization.
Thoughts? Comments?
Kai
P.S: For mapedit, we'd probably need a way to disable render zones
while editing. Instead it would be nice to generally limit rendering
to a certain height level. That way, it would be possible to edit
interiors or underground structures with more ease, even before
defining render zones.
The mapview could provide a switch for that and internally create a
render zone the size of the map, capped at the height specified by
mapedit. Then the algorithm above could be applied as well.
_______________________________________________
Adonthell-devel mailing list
Adonthell-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/adonthell-devel
