[CF-Devel] The Art of ... Cf
Michael Toennies
mtx93 at informatik.uni-bremen.de
Wed Nov 1 00:37:15 CST 2000
>
-----Original Message-----
>
From:
crossfire-devel-admin at lists.real-time.com
>
[mailto:
crossfire-devel-admin at lists.real-time.com
]On Behalf Of Mark
>
Wedel
>
Sent: Wednesday, November 01, 2000 3:03 AM
>
To: Crossfire-Devel
>
Subject: Re: [CF-Devel] The Art of ... Cf
>
>
>
Michael Toennies wrote:
>
>
>
> 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
>
>
I'm just going to respond to the points quickly and not go into long
>
discussions:
>
>
A) png default for client:
>
the X11 and gtk client support png just fine. All the user has
>
to do is run
>
with -png. I am going to do some work to make it easier to make
>
png the defautl
>
client (basically have a value in config.h for default image
>
type, and if set to
>
png, it does the right thing with respect to image sizes and the
>
like. It may
>
be reasonable the if the client compiled in with png support
>
(found the png
>
library) use png as the default.
The point is, that the move from xpm to png must a action of the whole
dev team. At this time, xpm are the default grafik and png are only
a unfinished extension. But waiting for a finished png set and a change
then will never work. Then we have the xpms also in 2 years.
Also, to support all these grafik sets and files waste time and power.
There is no real argument to support the xbms. Thats nonsense.
They should be dropped at first.
>
B,C) 24 bit depth & palette tables: the png images are the
>
format they are in
>
right now because that is basically how they got converted. If
>
another png
>
format is better, that is fine.
Yes, they are perfect because we can handle with it 256 index palettes
with 24bit RGB values and all kind of true color pictures and low costs. And
this will fit
the grafik support for a long time. Also making a xxx 32bit true color
client in the year 200x
will work fine with these pngs, so we should have no problem then. Also
fancy thing like alpha channels
etc. are included in this pngs, if we want use them, we must nothing
rewrite.
>
Paletted images is a nice idea. I would imagine that for
>
simplicity, you would
>
have to have some general color schemes (different shades of
>
blue, grey, green,
>
etc) or a base rgb value. It would take some bandwith for map
>
updates - right
>
now, all that is sent there is the image number, so any palette
>
information adds
>
a little bit of space, but I agree, probably not too bad. Also,
>
a palette field
>
would need to be added to the objects so you know what palette
>
each object has.
Think more general about the palettes. The server defines a sets of xx
256 standard palettes which have (only for example) 128 draw colors and
128 color space colors.
so, the first 12 palettes are used for buildings. So the first 128 colors of
them should have a set
of brown and grey for stones. the color space for example has a set of red &
green for the first one.
the 2nd palette has orange and blue in it and so on.
Now a artist make a draws a building with the first palette. grey stones,
green windows and a red top.
this is then the default palette for this picture. It is included in the
picture, so the client always
get a palette to every picture. With the transparent color trick i describe,
you can save in the palette
the information which palette number is it.
Now the client reads the picture in the normal way, stores the palette and
draw the picture.
In a different town, the server drops in the map commando the face nr. of
the building and set the
last bit of the face, showing that the next value is a palette number. The
client read it in, and
draws the picture with the new palette, for example the 2nd.
Now the building has in the other town blue windows and a orange roof.
In fact, the more on bandwith should be very small. Of course you need a
command for retrive a palette
you just don't now, but you really do it only 1 time you ever get connect to
the server.
The great thing is that you can mark with this the "special monsters". For
the scorn quests for example
you must kill the kobold and orc chief. You can't identify them by looking
on the map - they look like
the others. And getting the name of the suckers is not so easy when you
fight and move. With palettes
pictures, you simply set him to a different palette, where his armor is red
instead of blue or something.
For the user, its like you has a different drawn picture. Like i say,
allmost all actuell 2D games,
from diablo, UO, age of empires and so on use this technique.
>
D) Picture size bigger: More personal preferance for improvement is to
>
increase the size of the game window from 13x13 tiles to
>
something like 17x17 or
>
19x19. For 32 pixel sized images, that is a change of 416 to 608
>
if we presume
>
19x19. That doesn't exclude making images bigger, but I haven't
>
seen that be a
>
major issue. And one problem with bigger icons is inventory
>
lists - the bigger
>
the icon, the less inventory that can be listed.
>
>
However, a lot of the current png images are just blown up 24x24
>
xpm's, so a
>
lot of image cleanup can be done.
Well, making the the map bigger, kills the 38 pngs. then you should use
15x15 in 32x32 or 13x13
in 34x34. The point is, that around pixel of 35x35 is a critical area. If
you have a smaller tile,
your pixels and with it your details go fast down. Beyond it, you got much
more pixel for much more
details.
Thats because one pixel in y and x more or not is not strictly linear. 70x70
pixels are not 2 times more
then 35x35 of course. Its the factor 4. I work some times as professional
game writer and i had thsi dis-
cussion with some artist who telling me just this facts.
Also if you render, tiles beyond 35x35 has a big lose in details every pixel
you go down.
Thats of course if you use 800x600 or more as resolution. You got then this
"real" effect.
Thats why diablo for example has big tiles and figures. They need them the
"real" effect.
>
E) Sound effects: The sound effects has been around for a long
>
time as it is
>
now, and really needs to be redone. The objects themselves
>
really need to have
>
sound effect information (right now, all sound effects are
>
basically hard coded
>
into the source). That works OK for some, but having it in
>
objects would be
>
better.
>
>
It also makes it more complicated, because some objects would
>
have different
>
sounds depending on their state. But you won't get any argument
>
from me that
>
sound affects are out of date and a bit primative.
>
_______________________________________________
>
crossfire-devel mailing list
>
crossfire-devel at lists.real-time.com
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
>
More information about the crossfire
mailing list