liquidwar-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [liquidwar-user] Danish version


From: Christian Mauduit
Subject: Re: [liquidwar-user] Danish version
Date: Sun, 2 Nov 2003 18:22:12 +0100
User-agent: Mutt/1.3.28i

Hi,

On Tue, Oct 28, 2003 at 07:14:05PM +0000, Kasper Hviid wrote:
> Hello! I have now made langdk.c It can be downloaded here:
> http://levels.2v1.cz/langdk.c
OK, I've downloaded it and it has been commited into CVS.

> I guess that LW_LANGEN_DATA should be replaced by LW_LANGDK_DATA, but 
> programming is not my stuff. I have only altered the text.
No problem, LANGEN has indeed been replaced by LANGDK, but I could do
this part myself without any trouble 8-)

> The Gnu General Public License I use is an unofficial translation, made by 
> Christian Hansen.
OK, perfect.

> Question: The documentation of liquid war says that the textures should be 
> in 255 colors, since LW would convert them to 32 bit colors. Is there any 
> purpose of converting 255 colors to 32 bit? Another thing is that the game 
> dont seem to to accept more than 32 colors. And what is vbitmap?
Short answer: LW is crappy enough not to be able to handle anything else
than 256 colors "paletted" bitmaps, and it reduces this number of colors
to 32, which is, well, "very few" indeed.

Long answer: LW was first developped in 1995. LW5 was released in 1998,
so logically its developpement had to start before. Even in commercial
"professionnal" games at that time it was not unusual to have 256 colors
support only. Truecolor really came after, helped by DirectX AFAIK.
So at that time there was no "easy" way to deal with Truecolor (ie
16-bit or 32-bit video modes) in a standard and efficient manner.
Allegro provided this support anyway but still it was a little clumsy to
use it, and I still prefered the good old 256 colors paletted mode,
which is standard on any VGA card, and VGA is IMHO the last video
standard at a hardware level. 

So a good reason to use 256 colors mode was that it had a better
technical support than truecolor modes (at that time).

Another reason is that *if* the hardware really uses this 256 colors mode
(under DOS with VGA graphics this is the case) then display is really
faster (although less beautifull) than in any truecolor mode. That was
at least really true back in 1998.

So another reason to use 256 colors mode was performance.

Now once I had chosen to use 256 colors mode, I had to face a choice:
either choose a palette and stick to it (this is what DOOM or QUAKE1
did) or reserve "some portions" of the palette for various things. I
chose the latter. So in LW, colors from 0 to 31 are for the menus, 32 to
63 are for one texture (foreground), 64 to 95 are for another texture
(background), and some colors are reserved for the "fighters". It was
easier to handle this way, and 32 colors textures do not look *that*
ugly.

Now for various reasons involving the format of my .tex files, the fact
that LW's code is awfully ugly and barely maintainable, and that LW5 is
really tied to the fact that it uses a 256 colors mode, it's nearly
impossible to change that without a complete rewrite...

This is a shame since most users now run LW on truecolor displays, in
high resolutions, and the performance or quality of support of the 256
color mode is no more a valid argument. On the contrary, it happens that
today it totally super sucks that LW is programmed this way 8-/

So, well, truecolor mode is for Liquid War 6, definitely. There's no way
to hack better color support in Liquid War 5, believe me.

> Could we have the "corner menu" (Back, Play, Quit and Main) to be displayed 
> when the user gets an error message? Or maybe only the "Back"-button? Its a 
> bit clumsy to use the keyboard to get the message away, and then being 
> teleported to the main menu.
mmm, I see, will see what I can do, I have no idea wether it's difficult
to change, yet.

> Maybe there should be a question mark (?) to the left of the buttons? When 
> the user clicks the (?), he gets a description of what the button will do. 
> The documentation already have a good description of the different buttons 
> in the menu.
Not a bad idea. Old LW releases used to have a help button on every
screen, but the help was empty and/or not accurate and however noone
ever read it. I removed this button and now there's the "Play" button
instead.

> It would probably not be necessary to describe obvious stuff, like the main 
> menu. If someone dont understand what "play" does, he surely wont 
> understand an explanation. It should more be for buttons like "Curser X1" 
> or "No rps limit"
Yep, those buttons are perfectly ununderstandable, something must be
done. I'll try to hack some "question mark" solution as you mentionned.
Might be feasible.

FYI, I'm also preparing support for a "use default texture" option which
will allow all your maps to have their right textures used by default,
but still allow players to force the use of their own textures.

One side effect is that I needed to add a new button, and it needs to be
translated 8-)

Here's the new part:

LW_LANGEN_DATA[LW_LANG_STRING_LEVEL_USEDEFAULTTEXTURE] = "Use default texture";
LW_LANGEN_DATA[LW_LANG_STRING_LEVEL_ON] = "On";
LW_LANGEN_DATA[LW_LANG_STRING_LEVEL_OFF] = "Off";

BTW, if someone speaking German could help me with the German
translation, that would be cool too 8-)

Last point: I'd like to know if you're a UNIX or Windows user - maybe
you already told me but I forgot - for if you're a Windows user, I'll
try to provide a binary so that you can check that the translation is
working. If you're under UNIX, getting the latest CVS source tree and
compiling it will hopefully work without my help.

Thanks again for your maps and translation Kasper!

Have a nice day,

Christian.

-- 
Christian Mauduit <address@hidden>     __/\__ ___
                                        \~/ ~/(`_ \   ___
http://www.ufoot.org/                   /_o _\   \ \_/ _ \_
http://www.ufoot.org/gnupg.pub            \/      \___/ \__)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]