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

[xboi209]

Any progress aqrit?

[aqrit]

not really ;-/

but here is the build with d3d
http://www.bitpatch.com/downloads/war2_ddraw_test3.zip

it adds an alt+enter shortcut to flip between windowed and fullscreen views.
edit: alt+enter seems to crash currently if used on the battle.net screen
edit: it is also missing one of the kludges to redraw the screen ... so yeah WIP

I put the source up on github, just in case anyone wants to help.
https://github.com/aqrit/war2_ddraw

[iL]

Here's another problem reported from newbie: a notebook (he didn't call a model), resolution 1366х786 , win 8.1.
He got fresh war2 at 1/4 of screen, also your ddraw.dll didn't resolve the problem.
But another project called ddhack10 helped him.

At the same time ddhack10 is unplayable as known, but maybe there's something to get from that project and to add to war2_ddraw_test to ToSceen?

Also, to everyone: please, notify us if you have the same problem with war2_ddraw_test2. Need to have a system to test.

[xboi209]

Here's another problem reported from newbie: a notebook (he didn't call a model), resolution 1366х786 , win 8.1.
He got fresh war2 at 1/4 of screen, also your ddraw.dll didn't resolve the problem.
But another project called ddhack10 helped him.

At the same time ddhack10 is unplayable as known, but maybe there's something to get from that project and to add to war2_ddraw_test to ToSceen?

Also, to everyone: please, notify us if you have the same problem with war2_ddraw_test2. Need to have a system to test.

He needs to configure the scaling options for his graphics card. There's instructions on Google for this.

[iL]

He needs to configure the scaling options for his graphics card. There's instructions on Google for this.

But why did ddhack10 helped him?
Why 95% videocards are configured already and 5% have to be configured manually?

Which graphics card causes a problem?

Honestly, i'd prefer to add proper configuration for graphics cards during the installation process (or to ddraw). Otherwise we will lose some % of non-experienced users with such problem on war2-only. But need to understand the problem in details to add such config to installer...

[xboi209]

Intel: http://teamwindows8.com/2012/11/how-to-run-full-screen-games-in-windows-8/
Nvidia: http://us.battle.net/en/forum/topic/18300189156
AMD: http://support.amd.com/en-us/kb-articles/Pages/UnableToSetGPUScaling.aspx

A lot of graphics cards are smart enough to automatically lower the resolution and either scale the game to fullscreen or leave black bars on the sides to maintain aspect ratio.

[tk[as]]

there is currently no fix to scale windows 10 full screen

ive looked

[xboi209]

there is currently no fix to scale windows 10 full screen

ive looked

The issue is not due to the OS, but instead your graphics card settings.

[EviL~Ryu]

there is currently no fix to scale windows 10 full screen

ive looked

The issue is not due to the OS, but instead your graphics card settings.

Sent from my Motorola DynaTAC 8000X using Tapatalk

[EviL~Ryu]

there is currently no fix to scale windows 10 full screen

ive looked

Ur a dumbass, [emoji29]


Sent from my Motorola DynaTAC 8000X using Tapatalk

[iL]

Intel: http://teamwindows8.com/2012/11/how-to-run-full-screen-games-in-windows-8/
Nvidia: http://us.battle.net/en/forum/topic/18300189156
AMD: http://support.amd.com/en-us/kb-articles/Pages/UnableToSetGPUScaling.aspx

A lot of graphics cards are smart enough to automatically lower the resolution and either scale the game to fullscreen or leave black bars on the sides to maintain aspect ratio.

Thanks, looks like a good point to start my research for that.
But I'm not about to write instructions for users, i'm about to just start the game and get it fullscreened.
Ordinary players just want to play and don't want to config anything...

The question is why ddhack10 fixes that issue, maybe it's easy to add some additional code to switch the resolution if current way didn't act?
If it's not, i'll look at some possible checks during installation or launching process...

[aqrit]

The new code on github calls ChangeDisplaySettings() directly. If the user's device doesn't support 640x480 resolution then they will have to play in windowed mode. Scaling the ddraw graphics to fit the screen is trivial. Scaling the mouse input should be fairly easy. However, scaling the child and sibling windows on the battle.net screens will probably be very hard, this is not something I plan to do.

the current todo list for a stable version:
use d3d shader to color convert.
alt+enter on battle.net screen. (windows getting resized on WM_DISPLAYCHANGE???) done (?)
upon prntscr detection, set "import_gdi_bits = TRUE" for a few frames. done (?)
implement "wait for vsync" and "get vsync status". optional.

[xboi209]

I just compiled your latest commit and it seems like there's still a performance issue. It's as if a few frames are dropped at times

[aqrit]

thanks for testing xboi.
I just pushed a commit that might help:
while "in-game", GdiFlush doesn't need to be called at all...
so calling it every frame was probably an expensive mistake.

also... I've not sure if mca64Launcher stuff would conflict with my stuff
so please be clear if you're using or not using that.

[xboi209]

Not using any other tools when testing. So your latest commit cleared up the stutter but there's still an overall lag added, very noticeable when you scroll the screen. It's acceptable when playing on custom maps for fun but is still unacceptable for serious gameplay. It also breaks Korean font somewhere but don't worry about that right now.

- The unlock function averages 980 microseconds per call from a data set of 23,849 calls.
- The set_palette function averages 880 microseconds per call from a data set of 13,911 calls.

I just checked the unlock function and it seems that if (SDlgDialog_count == 0) is always true from my testing so I decided to go profile this for statement located inside that if statement:

for (int i = 0; i < 480; i++) // for each scanline
         color_convert(&dib_bits[i * 640], bmi.palette, (DWORD*)(((BYTE*)rc.pBits) + (rc.Pitch * i)), 640 / 4);

and it averages 320 microseconds for the entire loop from a data set of 59,404 calls.

Could you write some pseudo code or even C++ code for color_convert() so that I could understand it? I'm still interested in moving code onto multiple threads.