>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 _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel