Complete.Org: Mailing Lists: Archives: freeciv-dev: September 1999:
[Freeciv-Dev] Re: Merged the both tech patches a little bit
Home

[Freeciv-Dev] Re: Merged the both tech patches a little bit

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: David Pfitzner <dwp@xxxxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Merged the both tech patches a little bit
From: sebauer@xxxxxxxxxxx (Sebastian Bauer)
Date: Mon, 06 Sep 1999 12:22:16 +0100

Hello David

> You mean in the player struct, have an array of number of
> techs known for each tech flag, and update on load and
> when player gains a new tech?  Should be doable.  Not 
> sure if need to worry about what happens on the client...

Yes, that was the thing why I was concerned. But no need to
be I think ;-)
We could move this (optimized) function out of common into
server/plrhand.c
The unoptimized (which works always) should be moved somewhere
into client gui independ code. Actually the client doesn't call
this function anywhy very often.

But as the first step we could always do it so like the
unit stuff. The speed gain between it is now and this
method is very big. It is not so big between this and
my proposed method (and this method is a little bit
more complicated)

>> It better should be changed to:
>> -  return unit_types[id].flags & (1<<flag);
>> +  return (unit_types[id].flags & (1<<flag))?TRUE:FALSE;
>> But I actually don't know if it makes problems
>> (e.g. if a caller assumes that the flag is on the correct
>> place)
> I think this is what it should be.  

I, too ;-)

> #define BOOL(x) ((x) ? 1 : 0)
> #define BOOL(x) ((x) ? TRUE : FALSE)
> #define BOOL(x) (!!(x))
> #define BOOL(x) (1-!(x))

Defining BOOL would probably makes problems in the amiga code
because BOOL is defined in the amiga includes (as a typedef
to short). Could you rename it to MAKE_BOOL?

How you define doesn't matter, probably the first or second
is easier to read.

>> I think it if there are not more than e.g. 4 units with
>> the same flag it's not annoying. If there are more than
>> 4 units with the same flag we can still fall back (within
>> this function) to use other textes (e.g. your last suggestion
>> would be easy to implement in this function).
> Yep, sounds good.

Ok, but not in my first version of the patch ;-)
(It is mentioned as TODO)

bye,
Sebastian Bauer


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