[Adonthell-devel] Back to the drawing board

[Kai Sterker]

>From a previous mail

> [3] grouping of multiple images into a single object
>
> 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 (its exact
> position would be determined by the model coordinates and the relative
> position inside the frame.

While sounding like a good idea initially, I now think it isn't, for
multiple reasons:

1) Increased code complexity

Before, an animation was a "drawable" object that could simply be
drawn on screen. Nice and elegant. Now outside objects need to get at
internal parts of the animation, shuffle them around before each of
them can be drawn individually.

2) Increased data complexity

Suddenly we would have to work in 3D space with flat images, otherwise
we couldn't figure out the proper drawing order of the part of an
animation. While I have an idea how this could be handled in an editor
(by using a sideways projection to allow users to distinguish between
height and depth), it's still ugly at best.

3) It will not work in all cases anyway

On use for it would have been the character and its shadow. However,
the shadow must always remain at ground level while the character
might be airborne. So we would have to have a different place to keep
track of the character shadow.


All this together really makes me wonder if there is a better way of
grouping objects (or if we shouldn't do this at all). Maybe grouping
could be done at map-editor level, but on engine level we'd always
have separate objects.

Or we do grouping a model level (so that a composite map object can
have a single bounding box) making object storage and retrieval more
efficient. For drawing or collision detection, it would still be split
into its separate components. I still think this would not fit the
example of a character and its shadow (which is more like a parent <->
child relationship).


I will have to think about this some more. I will also have to change
some of the code I've written so far. Any ideas how this could be
handled are welcome, though.

Kai