On Sun, Jun 8, 2008 at 11:59 AM, Kai Sterker <[EMAIL PROTECTED]> 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 _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel