[Adonthell-devel] Re: Ancient treasures (?) and more ...

[Kai Sterker]

On Sun, Jun 8, 2008 at 11:59 AM, Kai Sterker <address@hidden> wrote:

> Whether it's really treasure or junk needs to be decided yet. But I'll
> go and look over what could be salvaged and put up on the Wiki as time
> allows.

The only one of these that's probably still valid is the coding style guide:

    
http://cvs.savannah.gnu.org/viewvc/adonthell-0.3/doc/devel/prog_rules.dxt?revision=1.1&root=adonthell&view=markup

Might fit here:
http://adonthell.berlios.de/doc/index.php/Development:Getting_Started
Other than that, stuff is outdated or already on the Wiki in some form.


> Aside from that, today I'll start with an overhaul of the rendering
> stuff. Issues I want to resolve are described in the second half of
> that email (more or less):
>
>   http://lists.nongnu.org/archive/html/adonthell-devel/2008-04/msg00000.html

No real progress yet, apart from some design ideas I'd like to share.
Here's a list of requirements I have for the renderer so far:

[1] one renderer per object
[2] discard gfx when no longer used
[3] grouping of multiple images into a single object
[4] removing multiple inheritance
[5] rendering without if/else
[6] splitting of gfx during rendering phase.

The details for each of those are:

[1] one renderer instance

We have a 1:1 relation between object and sprite. So far, the
placeable_model_gfx class took care of setting the correct animation
and starting/stopping animation playback. Since we want to get rid of
the multiple inheritance that comes with that, we need a new place to
set the proper animation and to control animation playback. With that
out of the way, one renderer instance could be used to draw stuff. We
could have different renderer implementations (for debugging, for map
editing, etc ...) that can be set in the map view.


[2] discard gfx when no longer used

Once objects get out of view, their gfx should be discarded (i.e. the
reference count in the animation cache decreased). The issue with that
is that so far, the map has its own cache of objects, so that the gfx
of each are loaded only once. I wouldn't change that, as it saves a
lot of effort when it comes to playing animations. Since there is only
one animation instance in memory, regardless of how many instances are
displayed on the map, there is much less overhead.

A compromise here might be to use zones for the map cache, so that
objects might be in memory several times (but not as often as they are
displayed on the map) and then purge entire zones as they get out of
view. The problem with that approach is that animations (like a water
tile) might be out of sync in different zones, giving a weird effect
at zone borders.

The other possibility would be to purge objects only when switching
maps (which might not happen very often, depending on how we handle
interiors and such).


[3] grouping of multiple images into a single object

Examples where this is useful are character and its shadow, the grass
James is working on, which is composed of multiple layers, objects
that have both vertical and horizontal elements (like the diagonal
cliff wall in the current demo) and possibly others. The idea is to
group gfx to make life easier for map makers, but do not split the
internal objects to keep the polygon count low (faster collision
detection) and decrease the number of objects on the world (faster
octree traversals). For rendering, each image will be handled
separately, as rendering order differs for flat and vertical objects
and because other sprites might intersect.

The logical place to keep the multiple images seems to be the
animation_frame. It would probably need a logical size, a list of
images with their respective position and a flag that specifies if an
image is horizontal or vertical. As a preparation for rendering, each
part of a frame would be placed in the render queue (it's exact
position would be determined by the model coordinates and the relative
position inside the frame. Then the queue gets sorted and finally
everything is rendered to screen.

The problem here might be a possible conflict with [1]. If drawing
gets down to draw individual images (instead of complete map objects),
drawing wireframes or editor hints might not work as planned. Also, we
still need to make sure that model bounding boxes properly enclose
objects (like the high grass). We may need a non-solid flag to exclude
bounding boxes from collision detection while still ensuring that
objects are rendered correctly. So the high grass might have a solid
box that represents the ground and a non-solid box that encloses the
vertical extent of the grass.


I would also collect some statistics for each frame: the ratio of
total pixels rendered to the number of pixels in the map view. If that
gets too big, we might consider implementing some filter that
(partially) removes objects which will later be obscured by other
objects.


[4] removing multiple inheritance

That basically means getting rid of all the ..._with_gfx classes and
moving their content to other objects. For now, I think the following
design seems feasible:

character_with_gfx: the shadow becomes a separate image added to each
frame of the animation. The drawing moves to the renderer.

object_with_gfx: the drawing moves to the renderer.

placeable_gfx: what was the purpose of that anyway?

placeable_model_gfx: we need an object for keeping models and their
sprites in sync. Maybe at this level we could also solve the issue of
unique objects (like chests, doors, etc.) that cannot share the same
sprite and objects like ground tiles and such that can (and should)
share the same sprite. The sprite modeling methods (which are
commented anyway) need to move to the sprite class itself.

That means, we need at least two new classes, a renderer and a
placeable_sprite that is the glue between placeables and sprites.

(And we should really rename the animation class to sprite, because
that's what it really is!)


[5] rendering without if/else

Getting rid of multiple inheritance should also get rid of the ugly
switch statement in the map view.


[6] splitting of gfx during rendering phase.

Another thing that needs to happen before sticking stuff into the
rendering queue: check for overlap of flat, non-solid objects with
vertical solid objects and cut the non-solid objects into pieces that
are put separately into the rendering queue. The non-solid flag could
be calculated for the complete model (i.e. are all its bboxes
non-solid), the vertical-flag is part of individual images.

Also see here: 
http://lists.nongnu.org/archive/html/adonthell-devel/2008-04/msg00014.html


I'll now get to work and try to draw up some kind of class model and a
sequence diagram that would cover the above (maybe without [2], as I
think that needs some thoughts yet). In the meantime, comments and
suggestion are welcome.

Kai