Matrix Games Forums

ORIGINAL: Shannon V. OKeets

We are getting close to tapping out the resources Windows has available for bitmaps. In anticipation of that problem arriving in the next 2 weeks, I have converted the individual unit bitmaps to pages of 100 each. This reduces the number of bitmap files for units from 2100+ down to 22. Here are some samples. Australians are first.

Great !
Maybe we won't have the "tapping out the resources Windows has available for bitmaps"problem then ?

ORIGINAL: trees

I never noticed the little white skull is smiling before.

Too much egg-nog.

ORIGINAL: Froonp

ORIGINAL: Shannon V. OKeets

We are getting close to tapping out the resources Windows has available for bitmaps. In anticipation of that problem arriving in the next 2 weeks, I have converted the individual unit bitmaps to pages of 100 each. This reduces the number of bitmap files for units from 2100+ down to 22. Here are some samples. Australians are first.

Great !
Maybe we won't have the "tapping out the resources Windows has available for bitmaps"problem then ?

Highly doubtful that we will dodge this bullet. As far as I can tell the specifics of what the limits are are undocumented. Preliminary tests I made say it should happen at between 60% and 80% of the coastal hexes loaded. Presently we are at 66% (3332 out of 5005). I believe part of the limitations are determined by the aggregate surface area of the bitmaps. If that is so, then the change I just made for how the unit bitmaps are stored will have no effect. However, there is a distinct possibility that part of the restrictions is on the sheer # of bitmaps, which I now do not expect to be a problem since I just freed up 2100 and that should be sufficient for all the remaining coastal bitmaps.

If (when?) the problem arises, I'll try to find out more about it, but there is little sense in going on what could turn out to be a long quest in anticipation of a problem that hasn't occurred yet.

Steve,
 
I would be honored to help do groundwork for that quest should it be necessary.
 
Just did some quick research on the bitmap issue.  Mixed news.
 
1) Moving to less but larger bitmaps should help in most cases.
 
2) The bitmaps may only be the straw that breaks the camel's back and not be the root cause and therefore the problem may arise again.
 
3) Raw size of bitmaps can also cause out of resource errors because certain device driver errors end up being reported as out of resources.
 
4) There are fairly simple ways around these problems.
 
A few key questions: 
 
Are you storing the bitmaps as resources or are you using a TImageList?
 
Are you autocreating your forms or creating and freeing them on the fly?
 
Are you doing anything special to ensure that you are creating DIBs (Device Independent Bitmaps)?
 
Do you have any explicit calls to SomeBitmap.ReleaseHandle?
 
I realize you are expecting that the problem is fixed and nothing else will be needed.  I wanted to post this while I was thinking about it just in case.
 
Have a great day and Merry Christmas!

ORIGINAL: SamuraiProgrammer

Steve,

I would be honored to help do groundwork for that quest should it be necessary.

Just did some quick research on the bitmap issue.  Mixed news.

1) Moving to less but larger bitmaps should help in most cases.

2) The bitmaps may only be the straw that breaks the camel's back and not be the root cause and therefore the problem may arise again.

3) Raw size of bitmaps can also cause out of resource errors because certain device driver errors end up being reported as out of resources.

4) There are fairly simple ways around these problems.

A few key questions: 

Are you storing the bitmaps as resources or are you using a TImageList?

Are you autocreating your forms or creating and freeing them on the fly?

Are you doing anything special to ensure that you are creating DIBs (Device Independent Bitmaps)?

Do you have any explicit calls to SomeBitmap.ReleaseHandle?

I realize you are expecting that the problem is fixed and nothing else will be needed.  I wanted to post this while I was thinking about it just in case.

Have a great day and Merry Christmas!

Great. I could use all the help I can get on this (should it arise).

Not using TImageList. I am not sure what you mean by 'resources' in this context.
Create and free forms on the fly.
Nothing special regarding DIBs (that I am aware of)
No calls to *.Releasehandle

I create and free temporary bitmaps all the time throughout the program code (and hopefully never forgetting to free them.).

The context for resources in the first question has to do with the ability to load graphics, strings, etc. into the executable at compile time to preclude them existing as files in the folder.  When this is done, they are generically called 'resources'.  TImageList does this for you but already combines the images into larger bitmaps.  I was trying to narrow the scope of the problem but those don't matter since you are not using either.
 
Got some leads, but have a few more questions:
 
Does the error occur when initially loading many multiple graphics or does it occur later when drawing or opening a form?
 
Do you have a loop that loads many graphics at once?  Are you calling Application.ProcessMessages in it?
 
Are you doing any drawing in threads?  Are any of these threads running concurrently?
 
Dean

ORIGINAL: SamuraiProgrammer

The context for resources in the first question has to do with the ability to load graphics, strings, etc. into the executable at compile time to preclude them existing as files in the folder.  When this is done, they are generically called 'resources'.  TImageList does this for you but already combines the images into larger bitmaps.  I was trying to narrow the scope of the problem but those don't matter since you are not using either.

Got some leads, but have a few more questions:

Does the error occur when initially loading many multiple graphics or does it occur later when drawing or opening a form?

Do you have a loop that loads many graphics at once?  Are you calling Application.ProcessMessages in it?

Are you doing any drawing in threads?  Are any of these threads running concurrently?

Dean

There are a large number of "resource strings" being used but none of them are very long. The basic goal currently concerning strings is to make them either resource strings or read them in from a file. Embedded strings within the code is being avoided (hopefully completely) so that a translation to another language is at least technically feasible.

I am not currently encountering the error concerning bitmap limitations in MWIF. For the European map (the first map segment) I had to shift the large bitmap Rob provided me a few pixels down and to the left. I also had to rescale it so each hex was precisely 136 by 152 pixels. The utility program I wrote to manipulate that large bitmap choked when I tried to create 2 full copies of it. Instead, I cut it in half and was able to process it in two pieces. So, that utility program had very few other demands on the operating system resources (e.g., no visible forms) and could read and write 1.5 European maps but not 2 European maps. This is the basis for my expectation of failure at 60% to 80% of the coastal bitmaps (using total surface area of the bitmaps). The error occurred on the creation of (possibly the attempt to write to?) the second bitmap (nothing was being displayed on the screen).

Yes there are several loops that load bitmaps in MWIF. The only ones of note are for the unit and for the coastal hex bitmaps and they do not make Application.ProcessMessage calls (they're very tightly focused on loading the bitmaps). The rivers and lake bitmaps I am handling with special encoding/decoding routines and 'drawing' them as overlays on the fly on top of the generated detailed map bitmap. At no time are the river/lake images stored as bitmaps.

Presently I am not running any extra threads, but will be doing so for NetPlay, PBEM, and the AIO/AIA. None of those will involve the use of bitmaps. NetPlay and PBEM will only use 2 IO ports (at most).

This is something Danny Thorpe (one of the guys who worked on the Delphi VCL for Borland) wrote.
 
'If you are doing an enormous amount of graphics work in a long running subroutine, you may need to insert an Application.ProcessMessages to allow VCL to release unneeded memory DC's.  We do 'garbage collection' on message processing, so if you're in a tight loop, the trash just piles up."
 
Without knowing the method you are using to scale the hexes, I am unsure that this is the problem, but it is very likely that DCs are being created and destroyed fast, hard, and repeatedly.
 
If there is no visible form (i.e. this is a console application), I am not sure how Application.Process messages will respond.  In a regular windows app, Application is nil until the main form is initialized.  This may also be part of the issue. I don't think console applications process messages in the same ways and this could be preventing the garbage collection from happening.
 
If there is the normal empty form (i.e. a very uninteresting windows application), then this might help.
 
I realize you have worked around the problem already, but I hate it when a possible problem is hanging over my head during development.
 
I hope this gives peace of mind.  Sorry if I have ended up being a drain on your time for no reason.
 
Keep up the great work!
 
Dean
 

ORIGINAL: SamuraiProgrammer
This is something Danny Thorpe (one of the guys who worked on the Delphi VCL for Borland) wrote.

'If you are doing an enormous amount of graphics work in a long running subroutine, you may need to insert an Application.ProcessMessages to allow VCL to release unneeded memory DC's.  We do 'garbage collection' on message processing, so if you're in a tight loop, the trash just piles up."

Without knowing the method you are using to scale the hexes, I am unsure that this is the problem, but it is very likely that DCs are being created and destroyed fast, hard, and repeatedly.

If there is no visible form (i.e. this is a console application), I am not sure how Application.Process messages will respond.  In a regular windows app, Application is nil until the main form is initialized.  This may also be part of the issue. I don't think console applications process messages in the same ways and this could be preventing the garbage collection from happening.

If there is the normal empty form (i.e. a very uninteresting windows application), then this might help.

I realize you have worked around the problem already, but I hate it when a possible problem is hanging over my head during development.

I hope this gives peace of mind.  Sorry if I have ended up being a drain on your time for no reason.

Keep up the great work!

Dean

No, no, not at all. Discussing this with someone is much better than those long-winded conversations I have with myself. I do talk things over with my wife, also a programmer (one of the more clever things I did in this life was to convince her to become a programmer 30 years ago - she makes lots of money) but she doesn't work on Window Applications.

"Heavy, heavy what hangs over?" doesn't bother me all that much. If it comes, it comes. It's always the tricky little bugs that at the time are attacking my ankles that drive me batty.

From what you wrote, I gather there is a possiblity this problem might not arise (still a very low probability, sigh).

Steve,
 
There are two formats of bitmap you can work with in GDI - DDB and DIB.  DDBs are faster, but can cause 'out of memory' errors.  DIBs can be slower to draw (because the device has to convert the pixel format before blitting), but should be limited only by available memory. 
 
The Delphi 'TBitmap' object has been through various rewrites in different versions of Delphi, and implements either DDB or DIB based on a both version and situation.  Are you using TBitmap?  I have no idea what the new Delphi does in terms of the underlying (DDB versus DIB) implementation of TBitmap.
 
In theory (ha!) if you can force Delphi to create DIBs you should have unlimited bitmaps to work with (up to available system memory), but if you're using DDBs then out of memory becomes far more likely/possible.

TBitmap has a property called HandleType which can be set to bmDIB or bmDDB.

ORIGINAL: cwie
Steve,

There are two formats of bitmap you can work with in GDI - DDB and DIB.  DDBs are faster, but can cause 'out of memory' errors.  DIBs can be slower to draw (because the device has to convert the pixel format before blitting), but should be limited only by available memory. 

The Delphi 'TBitmap' object has been through various rewrites in different versions of Delphi, and implements either DDB or DIB based on a both version and situation.  Are you using TBitmap?  I have no idea what the new Delphi does in terms of the underlying (DDB versus DIB) implementation of TBitmap.

In theory (ha!) if you can force Delphi to create DIBs you should have unlimited bitmaps to work with (up to available system memory), but if you're using DDBs then out of memory becomes far more likely/possible.

Thanks.

Boy, do I ever want to not have to figure this out. I am aware that there are 2 definitions of TBitmap, having run across a situation where the sequence in which the 'uses' files appeared causing problems. A before B invoked A's definition of TBitmap and the module would not compile. B before A invoked B's definition of TBitmap and all was well. (I might have those backwards with the last definition overriding the first - it wasn't clear to me).

And people wonder why programming takes so long. If and when this problem occurs, I guess I'll become a master at understanding the subtleties between the two (I've read some documentation on it in one of these 6 Delphi reference boooks I own).

I hate to be nit picky and I hope this won't ruin your depictions motif.  My favorite aircraft is the P38.  In your on screen depiction you can't see it's distinctive twin boom tail.  Anyway to tilt it just a little to show the twin tail just a little? I noticed you did it with that twin P51 monstrosity.

Also most of the P38L and P38L Late models were silver with blue or red spinners and markings.

All the rest are just perfect.  You have done a great job.  I hope it come out soon.

ORIGINAL: Hairog
I hate to be nit picky and I hope this won't ruin your depictions motif.  My favorite aircraft is the P38.  In your on screen depiction you can't see it's distinctive twin boom tail.  Anyway to tilt it just a little to show the twin tail just a little? I noticed you did it with that twin P51 monstrosity.

Also most of the P38L and P38L Late models were silver with blue or red spinners and markings.

All the rest are just perfect.  You have done a great job.  I hope it come out soon.

Telling me what you think is always good. If you don't, I won't know and I'll just continue on it blissful ignorance.

However, all the individual air unit bitmaps (and the naval ones too) are straight from the WIF FE cardboard counters. We are using the same graphics files that were used to print the counters (provided by Harry Rowland). I am not up for changing those bitmap graphics. They will be included in the game as individual bitmaps which any player can swap out with better ones. They are all 96 by 96 pixels in 24 bit color, though the available space for the combat unit image needs to be smaller to allow for the numbers in the corners.

Did you really look at all 1200+ air unit bitmap images? I only posted some of the 23 pages of unit bitmaps, but could post the rest if there is interest.

Something like this would be great.

http://farm1.static.flickr.com/142/3370 ... b2.jpg?v=0

Dang can't get it to show up. Follow link. To see it I guess.

Ooops just read your email. Sorry. You're doing a great job. Don't let me slow you down.[:)]

Did you really look at all 1200+ air unit bitmap images? I only posted some of the 23 pages of unit bitmaps, but could post the rest if there is interest.

I for one would be interested to see all the bitmaps for the aircraft (the ones so far look GREAT BTW)- but only if it would not be too much a pain in the behind [:)]

I need a MWIF Fix [:D]

ORIGINAL: Ballista

Did you really look at all 1200+ air unit bitmap images? I only posted some of the 23 pages of unit bitmaps, but could post the rest if there is interest.

I for one would be interested to see all the bitmaps for the aircraft (the ones so far look GREAT BTW)- but only if it would not be too much a pain in the behind [:)]

I need a MWIF Fix [:D]

I'll do some each day then.

Shown previously was Page 1 which contained the Australian air units and some of the US air units. Here is page 2.

Here is page 3, with the rest of the US carrier based air units plus their bombers and ATRs. At teh bottom are the NZ (I think) the red plane is not Japanese.