Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2000:
[Freeciv-Dev] Windows COM client
Home

[Freeciv-Dev] Windows COM client

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Arlo Belshee" <arlo.belshee@xxxxxxxxxxxxxx>
Cc: "Freeciv dev" <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Windows COM client
From: Andreas Kemnade <akemnade@xxxxxxxxxxx>
Date: Tue, 21 Nov 2000 19:36:10 +0100 (CET)

Arlo Belshee writes:
 > 
 > I am looking to create (another) native Windows port of FreeCiv (client
 > first). I have been meaning to do this for about 18 months now, but have
 > been continually stopped by one thing: the current codebase. In particular,
 > the current code is a massive wall of plain C, without obvious components or
 > structure: there is no way to break it down into digestable pieces. When I
 > wanted to figure out the networking protocol between client and server (26
 > months ago, when I was looking into creating a client-side AI), I ended up
 > having to understand the whole system (much of which I didn't intend to use)
 > and gave up in disgust without ever getting started.
 > 
I don't think the freeciv code is so bad. I'm creating a native
windows port of freeciv now (without gtk). I think the code is easy
enough to understand. The gui-stubs client and the gtk client are
quite helpful.  


 > 
 > So now I would like to program the Windows client. For this, I'd like to use
 > a simple multi-threaded component architecture, using Visual Basic for the
 > GUI, C++ to write certain GUI components (like the map and backside
 > drawing), and C++ for most of the back-end. However, this is a great
 > division from the direction dictated by the current codebase. My intention
 > would be to program something entirely new that integrates with existin
 > systems but is more flexible and extensible. I don't know this audience: are
 > you receptive to such a change in direction? This definately goes against
 > the way that things have been done, so what are the reasons that you used to
 > choose to do it this way? I can construct several arguments for an alternate
 > approach, and would be happy to if asked (some interesting new directions
 > for the project); I want to make sure that we choose to do this correctly.

Freeciv would certainly lost its portability because VB is windows specific.
There are much things in the client which are done in a general way. 
After I had ported update_map_canvas I was surprised that the map was
shown correctly. Units were drawn. And also special terrains. I see no
sense in doing such a big change.

Greetings
Andreas Kemnade



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