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

[James Nash]

Hi Kai,

Thanks for the answers!
I'm afraid I have some more questions though...

On 10 Apr 2008, at 10:38, Kai Sterker wrote:
> > 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

Aha! I knew I'd brought this up in the past but I couldn't find the  
mails.
So we settled on 41.8 degrees... it's all coming back to me now! The  
"giant scary eye" rings a bell too! ;-)

OK I'll work with that then. Thinking about it the 30 degree angle I  
was proposing in my last mail is a little too close to the ground - I  
think 41.8 will look more pleasing to the eye.

One more thing - is this angle fixed in the engine or is it  
configurable?

> just completed a page for the game designers doc on the Wiki :-).

Yep. I might have a go transferring my email (with the correct angle)  
to the wiki this weekend if that's OK with y'all.


> >  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 :-).

Just to be clear:
- PNM images are definitely out - it's all PNGs these days. Right?
- For RGB images will magenta pixels still turn transparent (I  
believe "keying" is the correct terminology for this approach)? And  
if so is this always the case or is it optional per image?
- Do we support PNGs with indexed colour too?


> - 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.

What's the purpose of that split into bottom and top parts? Does it  
affect the way things are drawn in front or behind each other?


> 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).

Right, we may need to revisit some of our Adonthell-specific  
conventions.

Also, even though graphics can be any size now there may be a case  
for having some tile size conventions for floors and walls. Otherwise  
we may have a hard time joining things up. For example if a floor  
texture is 30 pixels wide and a piece of wall is 50 pixels wide then  
they won't line up unless the width of our room is a multiple of 150  
pixels.


> - 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.

How would using an animation where each frame consists of n PNGs be  
different from using n animations?

Are there any limitations on how PNGs should be saved? (compression  
level and options)


> - 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

Interesting.

The image in your email shows triangular shapes too (like the barn  
roof). I think it would be useful to have this option in addition to  
cubes for things like roofs and slopes.

> 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.

It might be a good idea if there was a view where the vertical and  
horizontal sides of the boxes were shaded with different colours  
(maybe a lighter and darker shade of grey) so you can tell them apart  
more easily. It's fairly clear with the current map, but I can  
imagine this quickly becoming a confusing mess of lines when we have  
more complex maps and objects.

> - 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.

Sounds good.
Once I'm more familiar with how the gfx, mapobjects and maps work  
I'll try and come up with some ideas / suggestions / mock-ups for  
tools to create and edit them.

> 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).

OK, I'll take care to do that. Do the page authors get notified when  
stuff is added to the talk page? (Sorry, but I'm a MediaWiki newbie  
at the moment!)


Regards,
                        - James

--
Personal site:
http://cirrus.twiddles.com/