> From: James Nash <[EMAIL PROTECTED]> > > I'm forwarding this to the developer list (it was only on artwork so far) > incase ppl didn't see it. > I think some of this may be related to Kai's recent thoughts on the current > map implementation, since that discusses the rendering of maps.
Regarding the angle, we had the following discussion in 2003: http://lists.nongnu.org/archive/html/adonthell-artwork/2003-06/msg00005.html (linked from the map gfx task on the Wiki: http://adonthell.berlios.de/doc/index.php/Tasks:Map_Graphics). The values where slightly different back then, but it looks like you've just completed a page for the game designers doc on the Wiki :-). > Basically, I'd like an overview of how the in-game gfx work in 0.4 and what > can and cannot be done. I need the info to help me design some map gfx but > also want to update the artists' documentation on the wiki since it looks a > bit out of date. (As I start making some gfx I could perhaps do some > tutorials for other Adonthell artists too) Here are your answers (and again apologies for not catching issues with my emails earlier): - Transparency and Translucency. We currently support PNG images with or without alpha, as you already found out. In theory, you could do everything with RGBA images, but the old way is supported as well. It might be more efficient, but without any benchmarks to prove or falsify this claim this is just speculation on my part. If you look at the images included in 0.4 alpha 2, you'll find both cases. So whatever you prefer is the right thing to use right now :-). - Tiles Graphics can be any size, but there is currently some limitations for objects that have both height and depth. Those should be split into a bottom and a top part. Anything not terribly high or deep should be okay though, i.e. the crate from your example. Maybe this will lead to an engine that does the splitting automatically, given the gfx and its internal model. Originally, we said doors should be 80 pixels high. But seeing how NG is human and elves are supposed to be taller, I think we may have to increase this value, lest they bump their head against the door frame. (Given the pixel-precise collision detection, anything taller than a door opening would not be able to enter). - Map objects Currently, all map objects are "sprites" that are composed of 1 ... n animations with 1 ... n frames each. I am still in favour of the idea that a frame could consist of individual PNGs (in which case the gfx cache really comes into play, as it would be more likely that the same image is part of multiple objects). It's not implemented yet, however and probably needs an editor to compose a frame first. - The new pseudo-3D stuff The 3D model for an object is a pretty rough approximation of its shape (since it only needs to be good enough for collision detection). The idea is to start with a cube, then move its corners to match the object shape. If one cube is not enough to represent complex object, additional cubes can be added. Internally, the resulting shape is converted into a mesh of triangles that then is fed into the collision detection routine. Some examples that demonstrate the idea can be found in the image attached here: http://lists.nongnu.org/archive/html/adonthell-devel/2007-08/msg00013.html So what you see when pressing 'b' in the current demo is not the actual mesh (maybe that is what should be shown) but a bounding box that encloses the actual mesh. Objects on the map can intersect without problems. The collision detection algorithm will always detect the closest collision. - Tools. Not much work done yet, but most of the required tools have a task listed on the Wiki. My current plan is to start on some of the tools after I am finished with the map view part of the engine (as this is something the map editor will depend upon). In contrast to v0.3, editors should use GTK+, so a nice, easy-to-use GUI should not be as much of a problem. I do hope that the modular implementation of Adonthell's engine and the independence from a certain gfx backend should aid in the creation of our editors, as a lot of code can be directly reused by linking in the respective shared libs. Hope that helps a little bit. Please ask for more details where needed. This might also be a good opportunity to improve the quality of some of the Wiki entries. See for example the Map Module article: http://adonthell.berlios.de/doc/index.php/Architecture:Map_Module I think this is generally true of many of the Wiki pages: they are written mostly by somebody who knew what he was writing about, so they might omit basic information that would be required for others to understand. If you encounter something like that, leave a remark on the talk page, so that missing information can be supplied. (That's usually easier than trying to research the information). Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel