Oh I see my mistake with memset() now, and it's much much slower than the for loop too(edit: my computer is just slow right now). Is your assembly code even more optimized than the for loop?Is there any other code that could move onto a concurrently running thread?

@xboiI'll sink some time into this project since there seems to be some interest now...Hold off on any threading changes... there are still lots of bigger issues.

1. Does "in-game" Broodwar have any open SDlgDialog windows?

2. For Each SDlgDialog window GdiTransparentBlt color converts the same 640x480 from 8bpp to 32bpp each time... Would it be faster to color convert once then GdiTransparentBlt out to all the windows?

3. Would it be faster to GdiTransparentBlt only the changed portions of the screen instead of the entire screen to every window... Unfortunately the game locks the entire screen so we don't immediately know where changes occur. However, since we know every unchanged scan line will be all 0xFE bytes... it should be possible to do a quick hash of a scan line to know if anything on that line has changed... which would allow us to quickly determine a bounding rect around changes which we could then intersect with the window rects thus allowing us to move much fewer bytes around.

4. The only thing we can do for "ddraw only mode" is switch to uploading to video memory with a real API, not GDI. But that means when switching from "mixed mode gdi/ddraw" to "ddraw only" we need to clear any gdi stuff... can we just paint the main window with a NULL_BRUSH or do we have to destroy and re-create the main window?

3. Would it be faster to GdiTransparentBlt only the changed portions of the screen instead of the entire screen to every window... Unfortunately the game locks the entire screen so we don't immediately know where changes occur. However, since we know every unchanged scan line will be all 0xFE bytes... it should be possible to do a quick hash of a scan line to know if anything on that line has changed... which would allow us to quickly determine a bounding rect around changes which we could then intersect with the window rects thus allowing us to move much fewer bytes around.

Updating only parts of the screen is what modern video encoding libraries and game developers do nowadays so it should be faster. Maybe it's even faster to just check the first few bytes of a line for 0xFE bytes instead of hashing the whole line, what would go wrong if this assumption is incorrect?

4. The only thing we can do for "ddraw only mode" is switch to uploading to video memory with a real API, not GDI. But that means when switching from "mixed mode gdi/ddraw" to "ddraw only" we need to clear any gdi stuff... can we just paint the main window with a NULL_BRUSH or do we have to destroy and re-create the main window?

Are you suggesting to interpret the DirectDraw calls and use something like OpenGL or DirectX to draw to the screen instead?

2. use "rep stosd" instead. Since it's 1 CPU command, i think that's the fastest way to fill the array:mov eax, 0fefefefehmov ecx, 640*480lea di, pvBmpBitsrep stosd(i also didn't check that code, just an idea, syntax should be checked)

p.s. this may all be pointless... I've just ported the game to d3d9... it looks like gdi text only shows up over the game when it is windowed... So fullscreen d3d9 might be great, if I can copy gdi onto d3d instead of the other way around, I can ignore all this crap. I won't have much time to look into it for the rest of the week though.

edit:never-mind, I would still have black boxes around text if I did that

Only small problem i see is my desktop becomes visible briefly where all text is displayed when i click join/cancel in lobby. Not really a problem at all!

Windows 1064 - bitused fix 2

Bug2/3: if you hit print screen and get the dialog box the box is hidden and lobby is normal. But this will cause join / create to halt and enter to not send text from text box. So example scenario for me would be load war2, login, hit print screen, save box appears, then war2 minimizes because one drive wants to be default screenshot manager. So looks like something that forces war2 to minimize will break banner until next rotation and put the save dialog box behind the war2 window causing enter key and join / create to not work.... easy fix alt f4 one time or reload war2.