In an effort to simplify some code and fix the texture corruption bug I merged grd3dbmpman back into the regular bmpman. I made a few changes along the way to I want to explain things and make sure it's not going to mess anyone up. For any set of changes that were better in grd3dbmpman or bmpman I used the better version if possible.

- all bm_* functions are the default name now and reside in bmpman.cpp

- new gr_bm_* functions that are API specific will reside in grd3dbmpman and gropenglbmpman. These are not standalone functions and are designed to work from within the repsective bm_* function, ie. bm_lock() will have a call to gr_bm_lock() to mess with the image files themselves.

- several functions from grd3dtexture were moved into grd3dbmpman since that's the only place they are used. Includes d3d_lock_d3dx_types(), d3d_make_texture(), and d3d_read_header_d3dx().

- bm_load() checks if a file exists, sets up a bm_bitmaps[] entry and then reads the file header. Checking if the file exists calls cfopen() on that file and checking the header call cfopen() again. That's something of a waste so now CFILE *img_cfp will get passed around (NULL by default) which should reduce the amount of time searching the HD for a file during initial startup.

- the header check for D3D will, for JPG TGA & DDS, read the entire file into memory and then get the header info. There is already working code to read just the header itself for TGA and DDS files that is used with OpenGL so I make use of it now for D3D as well. JPG is the only thing that's still passed to D3DX to get the header.

- D3D will now account for memory like OGL does, in the "BMP:" part of the HUD message in debug builds. Also, user bitmaps are properly figured into this memory usage as well so it's a more accurate account of what's getting used.

- though not technically part of bmpman I've increased COUNT_ESTIMATE to 2311 in freespace.cpp. The increased number of textures that we use make the old number inadequate. This will hopefully give a more accurate rendering of the loading ani and help prevent the number of complaints about it sitting at full for a long period of time. That number could really be higher but where it's set still works well when you aren't using any new data over the basic FS2 stuff. This make the loading ani take a little longer to move to the right but the actual mission load itself isn't taking any longer.

The rest of the changes are just normal cleanup type stuff in bmpman and the obvious changes to get the above to work. As I've been testing it I've seen a noticeable speed increase during certain loading operations and have experienced no texture corruption or missing textures in any mission. A new build with these and other changes will be posted shortly.

Sweet.

I didn't test much yet, but I managed to get corruption on ANI load in the techroom. It seems to happen later, but still happens.

I'll test more later

I didn't test much yet, but I managed to get corruption on ANI load in the techroom. It seems to happen later, but still happens.

Yeah I was finally able to trigger a problem as well. It happened once, in a mission, and seemed to fix itself by the time the mission was half over. My usual test is to load three large missions in succession and it past that test for the first time so I was hoping things got fixed. If you manage to come up with a definite trigger to make this happen I'd like to know about it. It should be a bit easier to debug with the merged code but a starting point always helps.

Here's what I did:

Look at various ships (heavy ANI use) in the techroom - with older builds I'd have experienced corruption there already, but this time it was fine - went in-game for a mission - went back to the techroom, kept browsing through the ships again.

Then it happened

I haven't been able to trigger it again yet but then I haven't tried very hard either. When I get some more time I'll use your method and try again to track this problem down. Don't suppose you remember off the top of your head which mission you played?