RE: Modding unit bitmaps

RE: Modding unit bitmaps (Full Version)

All Forums >> [New Releases from Matrix Games] >> World in Flames

Message

Froonp -> RE: Modding unit bitmaps (12/20/2006 1:15:58 PM)
quote: 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 ?

mlees -> RE: Modding unit bitmaps (12/20/2006 5:22:28 PM)
quote: ORIGINAL: trees I never noticed the little white skull is smiling before. Too much egg-nog.

Shannon V. OKeets -> RE: Modding unit bitmaps (12/20/2006 6:50:01 PM)
quote: ORIGINAL: Froonp quote: 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.

SamuraiProgrmmr -> RE: Modding unit bitmaps (12/20/2006 7:33:50 PM)
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!

Shannon V. OKeets -> RE: Modding unit bitmaps (12/20/2006 7:56:34 PM)
quote: 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.).

SamuraiProgrmmr -> RE: Modding unit bitmaps (12/20/2006 8:18:12 PM)
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

Shannon V. OKeets -> RE: Modding unit bitmaps (12/20/2006 8:51:02 PM)
quote: 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).

SamuraiProgrmmr -> RE: Modding unit bitmaps (12/20/2006 9:48:46 PM)
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

Shannon V. OKeets -> RE: Modding unit bitmaps (12/20/2006 10:31:47 PM)
quote: 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).

TemKarl -> RE: Modding unit bitmaps (12/20/2006 11:44:40 PM)
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.

SamuraiProgrmmr -> RE: Modding unit bitmaps (12/21/2006 12:09:29 AM)
TBitmap has a property called HandleType which can be set to bmDIB or bmDDB.

Shannon V. OKeets -> RE: Modding unit bitmaps (12/21/2006 1:03:38 AM)
quote: 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).

Hairog -> RE: Modding unit bitmaps (12/29/2006 7:07:51 AM)
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.

Shannon V. OKeets -> RE: Modding unit bitmaps (12/29/2006 7:33:28 AM)
quote: 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.

Hairog -> RE: Modding unit bitmaps (12/29/2006 8:02:04 AM)
Something like this would be great. http://farm1.static.flickr.com/142/337053029_6d2f094ab2.jpg?v=0 Dang can't get it to show up. Follow link. To see it I guess.

Hairog -> RE: Modding unit bitmaps (12/29/2006 8:07:05 AM)
Ooops just read your email. Sorry. You're doing a great job. Don't let me slow you down.[:)]

Ballista -> RE: Modding unit bitmaps (12/29/2006 8:16:00 PM)
quote: 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]

Shannon V. OKeets -> RE: Modding unit bitmaps (12/29/2006 9:45:21 PM)
quote: ORIGINAL: Ballista quote: 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.

Shannon V. OKeets -> RE: Modding unit bitmaps (12/30/2006 12:29:09 AM)
Shown previously was Page 1 which contained the Australian air units and some of the US air units. Here is page 2. [image]local://upfiles/16701/F2E2C566AF8640539051253BCD5064B4.jpg[/image]

Shannon V. OKeets -> RE: Modding unit bitmaps (12/30/2006 12:31:24 AM)
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. [image]local://upfiles/16701/3C624118AD264A228A941D2B962807A9.jpg[/image]

Shannon V. OKeets -> RE: Modding unit bitmaps (12/30/2006 12:33:59 AM)
3rd and last in the series. Here is page 4, which contains the rest of the Japanese air units. I had shown page 5 previously (it has about half the Japanese planes). The unit in the top left is not US (I think it is Brazilian). [image]local://upfiles/16701/458CAF328FB64EBC8813615C58A0CCE9.jpg[/image]

Froonp -> RE: Modding unit bitmaps (12/30/2006 12:52:19 AM)
quote: ORIGINAL: Shannon V. OKeets 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. Not the NZ ones, but the Canadian. The red one is the Mexican Air Force.

rtamesis -> Bitmaps vs vectors (12/30/2006 6:50:13 AM)
Wouldn't vector-based graphics be a better choice rather than bitmap graphics in the situation where you have to zoom in and out and maintain crisp images and in terms of memory?[&:]

Shannon V. OKeets -> RE: Bitmaps vs vectors (12/30/2006 10:54:26 AM)
quote: ORIGINAL: rtamesis Wouldn't vector-based graphics be a better choice rather than bitmap graphics in the situation where you have to zoom in and out and maintain crisp images and in terms of memory?[&:] I don't know. CWIF used bitmap images exclusively for the units and map which included zooming and scrolling both. Conversion of all that existing code to run using another format never even entered my head for consideration. I did look into DirectX (vector based?) as a possibility for the graphics and found several good reasons to not use it for this application.

amwild -> RE: Bitmaps vs vectors (12/30/2006 2:38:14 PM)
quote: ORIGINAL: Shannon V. OKeets quote: ORIGINAL: rtamesis Wouldn't vector-based graphics be a better choice rather than bitmap graphics in the situation where you have to zoom in and out and maintain crisp images and in terms of memory?[&:] I don't know. CWIF used bitmap images exclusively for the units and map which included zooming and scrolling both. Conversion of all that existing code to run using another format never even entered my head for consideration. I did look into DirectX (vector based?) as a possibility for the graphics and found several good reasons to not use it for this application. I believe that WMF files - a vectored format - has native support in Windows. "All" that would be required is to convert the bitmaps to vectored images, and there are programs available that can do that. That, and test the wmf files to ensure that they actually work... Considering all the work already done, I don't really envision this happening, though.

Shannon V. OKeets -> RE: Bitmaps vs vectors (12/30/2006 5:24:46 PM)
page 6 of the counters - the USSR air force. [image]local://upfiles/16701/42DA8E79A965441A891E89446216176D.jpg[/image]

Shannon V. OKeets -> RE: Bitmaps vs vectors (12/30/2006 5:26:38 PM)
Page 7, the last of the USSR planes and the British fighters and carrier based air units. [image]local://upfiles/16701/F60D955033154A258A3FD2AFFF8EDBA2.jpg[/image]

Shannon V. OKeets -> RE: Bitmaps vs vectors (12/30/2006 5:29:49 PM)
3rd and last in the series. More Brtish carrier based air and their naval air, plus the start of their land based bombers. As I recall, most of these naval air units required a lot of repositioning to get them to fit within the frame and still leave room for the numbers. [image]local://upfiles/16701/E9EB005882404763AFF56846BEB48CE5.jpg[/image]

Ballista -> RE: Bitmaps vs vectors (12/30/2006 11:53:00 PM)
Ahhh Beautiful ! Now I've had my WIF FIX. Thanks Steve [:)] BTW Everyone have a Safe and Happy New Year !!!!!

Shannon V. OKeets -> RE: Bitmaps vs vectors (12/31/2006 8:36:29 PM)
Another trio of Air Unit Bitmap pages. This is page 10 (Page 9 had been shown previously). This page starts with teh German carrieri based air units, followed by the navao air, land based bombers, and lastly the start of the ATRs. [image]local://upfiles/16701/C37E705B0A5A489FB0C3C2E360502F57.jpg[/image]

Page: << < prev 27 28 [29] 30 31 next > >>

Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

2.0625