FPS drop when targeting large craft with 60FPS

[bguthrie1]

The FPS drop only occurs when using 60FPS. I am not using Jeremy's time hook but my own 60FPS hook. 30FPS mode would be fine of course. The issue only occurs when targeting something that is a container or larger.

I have RefreshLimit set to off and PresentSleepTime is not used.

I have uploaded a CPU profile of the issue. https://1drv.ms/u/s!AoEpIrw6LOkUjbcXobFFREagGK7xyQ

[rdoeffinger]

I used xwahacker (not yet release version) to patch the FPS limit, my vsync limit of 60 fps is reached consistently on my system.
Unfortunately without debug symbols the profile is not so useful, and as CPU usage is only averaged across all cores it's impossible to tell if there is any kind of CPU limit at all.
I've attached the latest DLL AND the pdb file for debug symbols ddraw_with_pdb.zip
(or you can compile yourself using VisualStudio community 2017), maybe you can somehow get a diagsession file with which includes function names using that?

[rdoeffinger]

Might also help, and likely easier to test: how does resolution influence things? Both desktop resolution and resolution set in-game or with XWAHacker?

[rdoeffinger]

I made a quick hack with which my i3-6006U laptop (integrated graphics only) can render 1080p at 50 fps or more.
If your computer doesn't manage a smooth 60 fps with that I am tempted to blame your computer...
It will require some additional work though (e.g. it only supports the default scaling mode so far), and I am not sure if it's an issue that it will raise the minimum requirements to a DirectX 10 graphics card (previously 9.3 was enough).
I also don't know if might reduce graphics quality a bit, might cause a bit of a red tint in some cases like around HUD edges.
I pushed it to the rendermainoptim branch.
Download:
optim.zip

[bguthrie1]

Resolution is set with xwahacker and desktop resolution is the same.

I'm doing some additional tests with 1.5.6 and 1.5.1 and it seems the issue doesn't pop up anymore...

I did do a lot of changes to my XWA install however including the pilot config so I'm trying to backtrack and see what was causing it in the first place. I will also test the version you uploaded and get a diag file if I can reproduce the issue again.

[bguthrie1]

Here is my dxdiag.
DxDiag.txt

I'm starting to believe that it is my computer. Though I have a Intel Core i7 CPU with a NVIDIA GeForce GTX 770, an issue that my computer sometimes has is that it can get hot and when that happens, the CPU clock speed scales back. If I tested Jeremy's ddraw under cool conditions and yours under hot conditions, it will skew the results. I don't recall the temperature the day when I made the tests. So I think my computer is to blame for this. I apologize for not taking this into account in the first place. If the issue does pop up again, I will take account of these variables and let you know.

Edit: What made me think there was some sort of issue was the fact that it would stay exactly 50fps instead of fluctuating, but until I receive the issue again I’m going to assume the issue is with my computer.

[rdoeffinger]

Ok. I will drop my optimization for now, but if someone finds a nice case where it helps (e.g. very high resolutions, 120 Hz with a powerful GPU but weak CPU) and can confirm no relevant negative effects please post here and I might pick it up again.

[JeremyAnsel]

In RenderMain, instead of creating a new texture, we can take advantage of the fact that the width and height are either the display resolution (set with XWA Hacker) or 640x480. The 640x480 texture can be created in OnSizeChanged, with the other texture (display resolution)

See JeremyAnsel/xwa_ddraw_d3d11@c388dbc

[rdoeffinger]

I was worried there might be issues because the user might not have set the resolution with XWAHacker, or have set it to something other than the screen resolution (e.g. to avoid the height > 1200 crash).
For my fork, there might also be other resolutions involved for the older games in the series.
So I kind of thought just using a generic cache might be best...

[JeremyAnsel]

I agree. I've changed my code. It didn't work well with cutscenes.

[JeremyAnsel]

It seems that 16-bpp textures are not supported on feature level 10.0 on Windows 7. They are supported on feature level 9.1.

See http://www.xwaupgrade.com/phpBB3/viewtopic.php?p=156674#p156674

[rdoeffinger]

What I can see from the documentation you need Direct3D 11.1 hardware for 565 support.
EDIT: documentation is here: https://docs.microsoft.com/en-us/previous-versions//ff471325(v=vs.85)
Does Windows 7 not support 11.1 in general, or was that just on older hardware?
I admit I hadn't expected that.
It is still a solvable problem IF anyone considers it worth their time, either by detecting format support and falling back to the assembler code, OR by using e.g. R16_UINT format and doing the conversion and interpolation in the shader.

[JeremyAnsel]

I've updated my version to use 16-bpp textures when available.

[rdoeffinger]

EDIT: Please ignore, I'll add a new comment with updated information.
Hmm... I think your change to add RENDERMAIN_COLORKEY_00 isn't quite correct.
While the rendering at first might be correct, the problem is that in the Lock() function that buffer is returned to the application. And if black is not replaced with magic 20 before, it's not possible to know which parts the application drew something black into and which parts it left untouched.
I don't know where it might be reproducible in XWA, but in XvT it is very obvious since large parts of the cockpit and HUD are now transparent instead of black.

[rdoeffinger]

(btw my code contains a SSE optimization of that "replace all black by 0x2000" loop if you aren't aware)

[rdoeffinger]

It might not matter for your code as you mostly disable blending, but if you look at the 16 bit -> 32-bit conversion code and also the alpha check in the texture, you see we ended up with a system where alpha 1.0 means "transparent" and 0.0 means "opaque".
However the newly added shaders for colorkey set alpha to 1.0, which makes things look very weird with my code. So I changed it to 0.0.