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

[ksterker]

Von: James Nash <address@hidden>

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

It's not even in there :-). Since the rendering is entirely 2D, there's no need 
for angles or such. 

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

Please do so :-).


> Just to be clear:
> - PNM images are definitely out - it's all PNGs these days. Right?

Right.

> - For RGB images will magenta pixels still turn transparent?

Yes.
 
> And if so is this always the case or is it optional per image?

Yes, as is the per-image alpha for RGB images.

Only unlike v0.3, where we had our custom image format, now it's PNG for the 
actual image and XML for the metadata. This is to prevent the situations where 
it's hard to get to the actual images to modify or reuse them. (Although there 
is a script in the v0.4 test folder that can extract the images from most v0.3 
objects).

> - Do we support PNGs with indexed colour too?

No. Or not yet. Would that be of advantage? (Possibly smaller file size?)

> > - Tiles

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

Yes, this is the only reason. The rendering as it works right now draws from 
left to right, top to bottom. To avoid clipping, it draws flat objects once it 
reaches the position of that objects top left corner. It draws vertical objects 
once it reaches their bottom right corner. That works out pretty nicely. But if 
an object has both height and depth, there is no right way to draw it. That's 
why you will notice clipping issues with the character shadow in the demo 
(where tile borders match grid lines). Since character and shadow are one 
image, the shadow is not drawn like a flat tile, which it should to work 
without clipping). Since I am working on the renderer (still thinking rather 
than coding, though), this might get resolved in a different way. For now I 
wouldn't worry too much about it, as we can easily split gfx when required.


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

Exactly. Internally, the engine still has a 40x40 grid to position objects 
(although they can have an offset, so in effect there are no limits to object 
placement). So maybe 40x40 (or multiples of that) would be a good format for 
our tiles.

In the current demo, I have both 40x40 and 60x60 ground tiles. The cliff wall 
is 80x80. The diagonal cliff wall 40x120. 


> > - Map objects

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

The only difference I can think of right now would be when placing stuff on the 
map. In one case, you'll place one (complex) object, in the other case you 
place n simple objects on top of each other.

Take your bushes for example. You could have an animation for the trunk and one 
for the leaves. If you want a bush with leaves you need to place the trunk and 
the matching leaves. 

Or you could have a bush without leaves and one with leaves. They share the 
same image for the trunk, so its just as efficient as the first approach, but a 
bit more convenient to map editors.


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

No.


> > - The new pseudo-3D stuff

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

Just define a "cube" where one side has zero width. Voila, a triangular shape.

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

Good idea.


> > - Tools.

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

That would be very helpful.
 

> OK, I'll take care to do that. Do the page authors get notified 
> when stuff is added to the talk page?

Not sure. The way our Wiki is currently set up definitely not. But there will 
be an entry in the list of recent changes and I guess most Wiki authors monitor 
that page (or the corresponding RSS feed).

In the worst case, it'll take a while before a comment to the talk page is 
noticed, but at least it is recorded.

Kai