[crossfire] Getting more artists

[mwedel at sonic.net]

>
> Common questions that seem to come up in regards to new graphics:
>
> * Color count or color palette information

 Now days, it is really unlimited.  We are not doing any tricky palette
information.  At one point in the distant past, we had a limited set of
colors, simply because back in the day, most people only had 8 bit
displays.  Now days, 8 bit displays would be rare, but even then, the
client will do its own color matching - not great, but should work.

>
> * What exactly is the "Crossfire Perspective" on graphics and how that
> can be replicated or duplicated; the psuedo isometric and not quite
> top-down  perspective on graphics

 Yes - that needs to be sorted out.

 In the wishful thinking department, you'd almost want 3 image sets:

1) True flat - don't try to force a perspective on the monsters.  This
doesn't look as pretty, but is perhaps simpler to do and is more
consistent related to other objects.  Question in this case is where you
try to force perspective on other things, like buildings.  To some extent,
the classic image set falls into this category.

2) Proper isometric - sort of where some of the things are now. However,
in this mode, things should actually be drawn in an isomorphic
perspective, and not on the flat view we currently have.  IIRC, for
opengl, this is easy - just a simple call someplace to change the view
perspective - however, images and everything else is needed for it - some
could perhaps be taken from daimonin.  This isn't a view I really like,
but seems popular.

3) 3d models.  I'd think these could be rendered in either 2d or
isomorphic, depending on perspective used for rendering.  May even be able
to do true 3d, but IMO that changes things a lot (the game is designed a
lot right now in that you will see everything around you - a 3d games
really is designed to give a front view).

 But questions for this is what modeling language is used to store that 3d
data.  I'd also think that for it to really be useful, the client would
need to do the drawing of the models itself.

 IIRC, there are currently a few 3d models in place, but these are used to
generate static images.  That works, but can be trickier to deal with.

 OTOH, some of this depends on other changes.  If for example, the idea is
to used 3d models for animation (these points move in this method),
animation logic on the client probably needs a bit of changes, etc.


>
> * Animation of graphics and howto animate them and name the necessary
> files for proper animation

 I thought that is documented someplace.

>
> * How to easily test new graphics via local server or client

 The ideal case would be for the editor to do it somehow, but that is
trickier.

 This could be documented fairly easily, but does require person to have
local server.  this isn't that tricky on unix side, but I don't know if
it is easy for users to collect images/archetypes on windows or other
platforms.

>
> * The 32x32 base size vs why not something larger?

 I know some developers have stated that current image sizes are too
small.  We could certainly do something larger - doing 64x64 for base
size is simple enough, and a quick resize of all images into a 'large'
imageset could easily enough be done.  The problem here is really that
there is now 2 image sets to maintain.  OTOH, I'd think that in most
case, if things were drawn for the larger size and scaled down, it might
work OK.

 64x64 may be too large a size however, and 48x48 may be a better middle
ground, but more discussion would be needed on that.