[CF-Devel] The Art of ... Cf

[Michael Toennies]

Hi

This is a controversial mail. I will make same suggestions of changing the
arts in
size and color depth. It will effect the way, cf handles the the pictures
and communicate
with the client. Also, there a changings to the sound interface.

Also this is a little faq in pngs and gfx handling because here are many
people
who don't know it. So don't be affraid if you read things you know.

My suggestions are:

a.) goint to png pictures as default for the next client/server version
b.) using 24 bit color depth as default
c.) using of palette tables (see below)
d.) increase the pictures size of a tile to from 32x32 to 38x38
e.) include a real sfx interface

Why we should do it:

general:
The client is the game.
ok ok, i know what you want to say, but you must always remember:
The best server is nothing without a client.

A good game, and cf should be a good game needs booth sides of game design:

game play (server) <--------------- > game presentation (client)

game play is the way the game works, the rules, all the things you can do.
game presentation is the way, this is the user shown!

The god rule for games are: game play must be in balance with the
presentation.
If not, you got a lose in quality. That don't mean you need fancy 3D gfx 4D
sounds.
The keyword is balance.

to a.)
Png are in cf since many month. But there is no client out, using it really.
So, no artist are interested to do the art. And he is right. Why wasting
time
when no one can see it???

To say to a artist: "draw it for low, but don't espect to see it in the next
year"
isn't the way to get quality pictures...

For the png is a big library out, called pnglib and zlib, which does all
color and size
transformation the client needs. Also alpha & grayscales can easily be used.
So, include
pngs in future clients is a small effort when the png.c module for a client
is ready.

I just wrote it, i can change it as a "standard" module for all clients
written in C/c++.

xbm/xpm are usefull in the early 90s, now we have end of 2000 and we have
MUCH more
bandwith, MUCH more harddisk space, MUCH more performance. CF dont use them
at the
moment. So, it has a lose in game presentation. With little effort, we can
change this.

to b.)

Some info first, because i know that not everyone knows about the pngs:

24bit true color pictures? This is a bit confusing, but all png are in
24bit!
Also if the picture is in 16 colors (most pngs at this time are in 16 colors
because they
are transformed xpms) or in 256 colors (some are), the palette information
is all times
saved as 24bit. So all pngs included in cf are in true color yet! Thats, why
24bit is the native format for pngs.

So, if i read in a 16 colors png, i just convert it to real 24bit. thats
means, the color
palette entrys are changed to the real color of the palette. No color value
is in this
process converted or expanded. Then you can convert it to the color format
of the
used mashine or lets do it by a grafik system. In fact, it MUST also yet
transformed
from 24bit to native format, thats nothing special from the directx client.

In real 24 bit pngs, there is no palette, all pixels are safed as RGB 888
(8+8+8 bits).
The only difference is the size of the png, and this don't must be more than
with a
palette.

to c.)
Why using palettes? There a 2 reasons using palettes.

First, if you have a picture with <=16 or <=256 colors, you can generate a
palette.
In the png the palette is safed as 256 (or 16) * RGB 888 plus the
xlenght*ylength*8
(or 4 bit when 16 colors) pixel information. The png packs then this
information.

If you have a small amount of colors, you can safe size. So, its intelligent
to let
count your gfx programm the colors and if they are <=16 or <=256, use a
palette.

The 2nd BIG reason is the way, games using palettes.
If you ever played Ultima Online or Diablo, you know the monsters or the
Items (special
in UO) which comes in a so many colors but using the same bitmap. In UO you
can
dye cloaks for example.

This works with palettes. The bitmap is safed in memory not with his real
pixels. In the
memory stay the palette index info only (for a 256 palette bitmaps byte from
0-255 for example). Then, if you dye a cloak, you attach a different palette
to it.

DirectX and all other APIs like glide, opengl and so on have a special
routines to do
this (making paletted surfaces and attach palettes to it) and lets it draw
by hardware.

The old name for this is using LUT-tables, it is the same system (But using
old self
maked routines to do it, means to work in system memory or lock the video
ram, what
drop down the frame rate in big amounts).

For crossfire, we can do the same like in diablo - with 2 small tricks.

The goal is the diablo effect: sets of the same bitmaps in different colors.
Special monster with "special colors".

This is very fancy, safes A LOT of space, pictures and bandwith.
All we need is a byte for the palette info, if we need it.
Also, with a small trick, we can send standard palettes with the png
pictures.

How it works:
If the map data are send, the server sends the face IDs. So it works yet.

All what we have to do is using the last bit of the face value as a flag.
It is set, the next byte is a palette number index. if it not set, all is
normal,
no extra byte is send.

So, we have no more bandwith, no speed problem.

At the client we have a palette pointer array.

_palette *paletteptr[MAXPALETTES];

If the index is NULL, we must poll the server for palette.
We CAN draw the picture at this moment, because we had get the png with his
default
palette. The default palette is also a entry for paletteptr!

The trick is to use the transparent color. We always need one, and for a
paletted
picture we must set them. So, set them. Set then as default to RGB 000.
Now if you want the png as a normal, none paletted bitmap, leave the
transparent
color as 000.

If you want use it at paletted bitmap and the palette for paletteptr, change
the RGB
value to the index number of the paletteptr (means R is high byte, G mittle
and B low).
If a png comes in from the server in old way, just read it in. Control the
palette
and transparent value, set the palettesptr to the palette if the transparent
RGB is != 0
and draw it.

If the palette not read in, we must poll it, so we need a cmd SENDPAL num
and PALETTE
num from the server. But this is easy and they are read in only once and
only a few.

Now we can sen big animations like the dragons in one time and draw them in
hundreds
of colorset. Special monsters can be shown on the map as it.

This will boost the grafiks quality of CF in heaven.

to d.)

800x600 is the standard resolution for system at this time. They can drop
out it easily.

I find the map in the client to small. The size of 32x32 means 1024 pixels.
If we draw items, we have about 24x24 pixels left (some more perhaps). Thats
not
really much for a colorful map.

I had expand the map in the snap.jpg to 38x38. That means about 1444 pixels
per tile
141% off the size of the 32x32 pics.

I include 2 shields ripped from age of wonders (dont give this out to
public!!) to show
whats possible.

The size of the big versions of the shield is 38x37 and 37x34, so look for
yourself.
If you size them down (the small skull shield), you see the lose of quality.

There is a real difference between 32x32 and 38x38 tiles in quality, a MAJOR
difference,
but the way we can change it, is easy.

And when we want do it, then we must do it YET.
Many of the pngs must drawn or redrawn, we must include them yet also, so
lets do it know.

to e.)
The sound interface is very basic at the moment. What we need for nice
sounds are the position of the sound relativ to the map positon of the
player. Thats not so hard
to make. The server counts the action on a map all the time, all what you
have to do
is to generate all few seconds 1-3 sounds (if many happens on the map) plus
some
tricks.

With the xy position i can make 2D sound, means you hear it from left or
right or up/down.
Thats also a standard of gaming for years.

Also, the server can give some looping sounds. for example if are dreads on
the map, the
server sends one <SNDLOOP dreads> to the client. The client loops the sound
(a <grmpf> for example) with a random tick until the server sends a SNDSTOP
dreads or the player leaves the map.

Ok, i think kick on a nice conversation with this mail,
please lets talk about with one goal in our mind:
we love cf and want to make it a better game.

MichToen






-------------- next part --------------
A non-text attachment was scrubbed...
Name: snap.jpg
Type: image/jpeg
Size: 103239 bytes
Desc: not available
Url : 
     
     http://shadowknight.real-time.com/pipermail/crossfire/attachments/20001101/9d22bc62/snap.jpg