Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2000:
[Freeciv-Dev] Re: OO model for Freeciv?

[Freeciv-Dev] Re: OO model for Freeciv?

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Cameron Morland <cjmorland@xxxxxxxxxxxx>
Cc: Falk Hueffner <falk.hueffner@xxxxxxxxxxxxxxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: OO model for Freeciv?
From: Tomasz Wegrzanowski <maniek@xxxxxxxx>
Date: Sun, 30 Apr 2000 17:43:34 +0200

On Sun, Apr 30, 2000 at 09:45:03AM -0400, Cameron Morland wrote:
> On 30 Apr 2000, Falk Hueffner wrote:
> > Well, nevertheless I think we should stick to C :-) It's just that the
> > arguments here seem silly. For example, execution speed is pretty
> > irrelevant for FreeCiv IMHO, as long as it isn't twice as slow or
> > something.
> I must disagree, myself. Sid's Civ on DOS was nice on a 286, and crazily
> fast on a 386. I have a Sparc 2, and FreeCiv is acceptably fast with a
> normal map, and painfully slow with a large one. Making it significantly
> slower would make it unplayable for me. If Sid can do it with a 286, we
> should be able to do it with a slow Sparc. You can, of course, tell me I
> ought to upgrade. But this is not a good way of encouraging new users; one
> way to get people to start using Linux is to say "got a spare 386? I'll
> set up a sandbox for you to play with it a bit." So requiring a recent
> machine is IMHO a mistake.

CivI run nice on 386, but :
1) it used 64kB VGA graphics, freeciv is usually run
   at 1 MB (800x600x16bit) or better graphics
2) it was used on single-task environment,
   therefore used 100% of resources available
3) more stuf was hard-coded, so optimized on compile-time
4) it didn't need complex client-server sync, in civI,
   you only needed to call and execute a function, in freeciv :
   call, pack, send, recv, unpack, execute, answer, pack, send,
   recv, unpack, update, or something

But freeciv can be made faster
my suggestions :
- put all reusable stuff (like displaying gtk map) to shared libraries
  little modules are easier to optimize, and if some other project will
  reuse them, there would be big chance that these libs get more manpower
  on optimalizations
- use remote procedure calls and shared memory to simplify and speed-up
  client-server interaction

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