[Freeciv-Dev] Re: baseline without cvs

[Andreas Kemnade <akemnade@xxxxxxxxxxx>]

Jennifer Glover writes:
 > Yeah, I ended up with a problem with the HBITMAP2BITMAP, because the
 > function GetBitmapBits is not available on WindowsCE.  So I wasn't
 > sure how to copy a bitmap.  That is why I replaced the bit buffer you
 > were keeping around with an HBITMAP.  Does FreeCiv really keep around
 > 1200 bitmaps?  That seems awfully excessive.  No wonder I am having
Count the calls of crop_sprite to check.
 > problems with the amount of run-time memory allocated!  Can you think
 > of a way to copy a bitmap's bits like what was originally happening in
 > HBITMAP2BITMAP without using GetBitmapBits?  Or even better, a way to
 > make FreeCiv a bit smarter about its use of bitmaps?  Maybe where it
 > only loads the tiles/units it is actually using? 
You can use GetDIBits. I haven't choosen that function because it is
too powerful. It can convert the bitmap bits and I don't want that
because I want to be able to create a HBITMAP in the fastest way
possible (without converting things back).

A way to save memory is to split the gfx files. But then we have to
change common code (the whole tilespec api including the stuff to read
tilespec files). What about putting more small gfx files into one (perhaps
like a current ar archive)? 
There were discussions about adding dynamically loading of gfx into
the tilespec api for eye-candy graphics.
What about using such thing even for the tiles?

To reduce the number of bitmaps you can leave the big bitmaps
untouched (don't split them). 
The win32 gtk client solves the problem in this way. But it has to
allocate HBITMAPs (internally used for GdkPixmaps) for the stuff from
tilespec_lookup_sprite_tags. And it does not save memory.

Some month ago I had access to a machine running Win2k. I looked at
the consumption of resources of the gui-gtk client and the gui-win32
client.

I cannot remember the exact values. The gui-gtk client uses still around
300-500 gdi objects and the gui-win32 client (using the HBITMAP2BITMAP
stuff) only around 60.

 > 
 > Yeah, another problem was the lack of a console app for PocketPC.  I
 > originally made stdin and stdout to be files' of my creation, but I
 > couldn't think of a good reason for this, except for mimicking a
 > console app.  I wanted a gui driven control, not command line, so I
 > ended up getting rid of this custom implementation of stdin/stdout.
 > 
The stdout output in the client is only useful for debugging.
Is crop_sprite *always* successful on WinCE (without running that
HBITMAP2BITMAP stuff)?  

Greetings
Andreas Kemnade