War2 graphics for Win Vista/7/8/8.1/10/2012 fixed

[aqrit]

its erasing 307200 bytes ( 76800 dwords ), is this the problem with how your using memset?

anyways... this would probably beat out the library function anyways.

Code: [Select]

__asm{
mov eax, pvBmpBits
pcmpeqw xmm0,xmm0
psllw xmm0,1
packsswb xmm0,xmm0
mov ecx, 640*480/128
lbl_loop:
movntdq 0[eax], xmm0;
movntdq 16[eax], xmm0;
movntdq 32[eax], xmm0;
movntdq 48[eax], xmm0;
movntdq 64[eax], xmm0;
movntdq 80[eax], xmm0;
movntdq 96[eax], xmm0;
movntdq 112[eax], xmm0;
add eax,128
dec ecx
jnz lbl_loop
}
It could be done on a separate thread because we don't need the surface again until the next dd->Lock call.

[xboi209]

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?

[aqrit]

@xboi
I'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?

[xboi209]

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

I have no idea, and don't know how to check. My best guess is probably yes when you click on the menu button.

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?

Not a graphics programmer, but to check if anything is faster, you would profile the code.

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?

[iL]

if this code: "for( i = 0; i < 640 * 480 / 4; i++ ) p [ i ] = 0xFEFEFEFE;" is a bottleneck, then here's my not so experienced opinion about optimizations:
1. never use p [ i ]. You lose performance on each cycle of the loop. Use *p instead.
this code:
p = (DWORD*) pvBmpBits;
for( i = 0; i < 640 * 480 / 4; i++ ) p [ i ] = 0xFEFEFEFE;
need to be changed to something like:
for(p= (DWORD*) pvBmpBits + 640 * 480 - 1; p < (DWORD*) pvBmpBits ; p--) *p = 0xFEFEFEFE;
(fix the syntax if wrong, i didn't check that)

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

[aqrit]

@iL
everything you posted would all compile to the same code

I checked earlier today and

Code: [Select]

for( i = 0; i < 640 * 480 / 4; i++ ) p [ i ] = 0xFEFEFEFE;compiles to 

Code: [Select]

mov eax, 0xfefefefeh
mov ecx, 640*480/4
lea edi, pvBmpBits
rep stosd or w/e

IMO the sse2 code that I posted is as fast as it gets.

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

[GaNzTheLegend]

Tested on 8.1 and it seems to work perfectly.

[EviL~Ryu]

Tested on 8.1 and it seems to work perfectly.

Bitchin!

Now you probably coming out of retirement [emoji16]




Sent from my Motorola DynaTAC 8000X using Tapatalk

[Delete mine too]

Cool works great!!!

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 10
64 - bit
used 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.

[EviL~Ryu]

Visible desktop occurs when tab in and out of war2.


Sent from my Motorola DynaTAC 8000X using Tapatalk

[EviL~Ryu]

Fixable by joining or creating a game though


Sent from my Motorola DynaTAC 8000X using Tapatalk

[Delete mine too]

It's on after I clicked join or cancel it bugs out for me for a second or so. Alt tab seemed fine for me.

[EviL~Ryu]

Hmm probably because I got more than one monitor running at the same time?

Sent from my Motorola DynaTAC 8000X using Tapatalk

[Delete mine too]

Could be i have my standdard laptop screen with duplicate settings to my 55 inch NEC monitor lol

[EviL~Ryu]

Could be i have my standdard laptop screen with duplicate settings to my 55 inch NEC monitor lol

55" really? Lol

I still have a old 13" 4:3 NEC that I use for my home server [emoji14].




Sent from my Motorola DynaTAC 8000X using Tapatalk