Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets
Home

[Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Petr Baudis <pasky@xxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets
From: Andrew Sutton <ansutton@xxxxxxx>
Date: Sun, 2 Dec 2001 18:28:08 -0500

On Sunday 02 December 2001 02:00 pm, Petr Baudis wrote:
> i didn't write any actuall programming example for it. obviously you need
> to test it.

no, but any time you use pointers to open yourself to the possiblity of 
dereferncing a null ptr. it happens to the best of us.

> > oh... don't forget, your tile is now 160 bytes. assuming a map of only 32
> > by 32, that comes to a total of... 160 KB. and that's for a small map.
> > using c++, you'd lose all the function pointers (reduce to 64 bytes).
>
> uh, who says each tile will have own copy of structure with handlers?

pointers as members of a structure DO occupy memory consumption - even 
function pointers. a total of 5 ptrs, that's 4 bytes per pointer = 20. oops i 
was thinking bits and multiplying bytes ;) let me redo the math. 20 * 1024 <- 
32^2) = 20 KB for the map. so, every 32 bit field you add to the tile will 
jump the number by 4 K (e.g. a 6th ptr would yield 6 * 4 * 24 == 24 KB).

> 4 byte waste. we are not in 70s. that is for 80*40 totally empty map 12kb
> waste. not so fatal imho. anyway this was actually only *example* ;p.

no, but keep in mind, 32 by 32 is a pretty small map. i'm not really sure 
what the largest map size is, but lets say it's pretty big (128 * 128). now, 
all of a sudden you're not talking about 70's memory consumption anymore. 5 * 
4 * 128^2 == 320 K.

its just a feature of exponential growth based on the map size... you will 
get very, very large maps. if you're talking about a map 256 by 256 (which i 
assume is pretty large), the map size jumps to 1.2 MB.

> > the current proposal isn't to put units into different modules... just
> > capabilties. the unit is still a single class. the unit _will_ have to
> > know how to cope with capabilities, but again, it has to in freeciv1. add
> > a new capability, the ai has to learn it.
>
> how?

well, unless the ai is automatically smart enough to learn about unit 
capabilities without having to explicitly tell it about them there's going to 
have to be some kind of ai change. of course, if we were smart enough to 
write an ai that was capable of using unit capabilities without any support 
from us, we probably wouldn't have to work so hard on it.

> this would be nice. still i think doing this in C w/o major rewrite is
> possible.  if you don't think so, go ahead, fork another project doing that
> and see how successful you will be, it's quite possible you will beat us
> and we will join you later. however i don't see any core developers
> amazingly raising their head and concentring around you with happy crying,
> so i think you won't success with converting this project to c++. obviously
> i can be quite wrong here too.

that's okay. that's why it's just talk right now. i'm trying to flesh out 
requirements of the system. i've looked at the freeciv1 code and you can't 
modularize it without a major rewrite. that's why there's talk about so much 
change. there's just things that could be better done from a clean slate and 
rather than jump in and start coding, i'd like to take the time to understand 
what this issues are and how best to address them.

besides. this isn't just a conversion. it's a complete rewrite. i realize 
that alot of people are resistant to change and i also realize that some 
developers are unhappy with the current state of the code/cvs/etc. this is a 
chance to wipe the slate clean and make some changes in the freeciv 
development process.

if it turns out that there isn't significant interest, then i'll drop the 
subject and let freeciv continue on its merry wayward development path. there 
does seem to be enough interest so we'll see how this turns out.

andy


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