Re: [Adonthell-devel] Fwd: [Adonthell-artwork] Another gfx question...

[Kai Sterker]

> From: James Nash <address@hidden>
>
>  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