Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2001:
[Freeciv-Dev] Win32 client
Home

[Freeciv-Dev] Win32 client

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Win32 client
From: Andreas Kemnade <akemnade@xxxxxxxxxxx>
Date: Sun, 16 Sep 2001 13:54:34 +0200

Vasco Alexandre Da Silva Costa writes:
 > Now that the native Win32 client sources are in CVS i wonder: what tools
 > are you using to compile it?

I use gnu binutils and gcc. I don't use any additional tools for
creating dialogs. 


I mainly cross compile the stuff. But I also use the "normal" way with
the cygwin tools.

I use binutils version 2.9.4 and gcc version 2.95.2 
Binutils sources are from cygwin. I use plain gcc sources 
with an additional patch from 
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/gcc-2.95.2/patches/gcc-2.95.2-x86-win32-patches.zip

There were configured using:
./configure --target=i386-mingw32

Headers and libraries were from the same server. I use the msvcrt
stuff. 

To compile freeciv itself I set the CC, AR and RANLIB variables to
the right values.
Then
./configure --host=i386-mingw32 --build=i586-pc-linux-gnu
--enable-client=win32 (to avoid building the gtk one)
make

 
Then I test it using wine. Of course, I also test it in real windows 95.

-----------------------------------------------------------
The other way which I also try is:
Using the cygwin tools in a normal way. (more recent versions)

Then I can do:
export CC="gcc -mno-cygwin" (required to switch to mingw32 mode,
                             without it would use the unix emulation
                             from cygwin and builds freeciv in
                             a way Todd Goodman has done)

./configure
make


 > 
 > Do you   plan  to use GDI or DirectDraw for the graphics?
           ^^^^^^
Does this mean there is a bug which prevents you from seeing gfx? 

I'm using GDI for the graphics. It seems to be fast enough. 
Even with wine it is faster than the gtk client on real windows.
Of course, the same "number of bitmaps" problem as I have with the gtk
client appears. My workaround:
Windows has these two data types for bitmaps: BITMAP and HBITMAP.
Almost every Windows API function dialing with bitmaps uses HBITMAP.

But if you provide the memory for a BITMAP structure and a
buffer for the pixel data you can make Windows fill in the stuff.

If I want to draw a sprite I have to use the stuff from the BITMAP
struct and then I can create a HBITMAP from it. 

I hide this stuff from mapwin.c and I have a draw_sprite_part function
in graphics.c, which I use from everywhere outside graphics.c. I don't
access the elements of the sprite struct outside graphics.c. So I can
easily change my workaround. In the gtk client I had to touch almost
every gdk_draw_pixmap function to reduce the number of bitmaps windows
has to maintain. 

Gfx format:
Currently I use bmps. I have separated the mask from them in an extra
file. The mask file have a -mask in their name:

units.bmp      (bitmap)
units-mask.bmp (mask)

Using xpm without X is not very easy so I don't use it. 
I think I'll also support png before 1.13.0 to make converting
modpacks easier. I have some code in cvs to load png files but it is
disabled because it was not stable enough. Handling masks in png files
causes randomly crashes. I'll debug that. 


Greetings
Andreas Kemnade



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