elishacloud
Bad framerate and pacing in Project IGI in Proton/Wine
Game: Project IGI Applied Game Patches: https://github.com/BlanknameES/IGIPatch/ dxwrapper version: v1.4.7900.25 (dx7.games.zip) OS: CachyOS Wine/Proton version: GE-Proton 10-25 CPU/GPU: Ryzen 3 3250U/Radeon Vega 3
Issue: The game has horrible framerate when playing
dxwrapper log: dxwrapper-igi.log
You could try using the latest build and enabling the UseShadowBackbuffer. This can significantly improve the performance for some games, dependence on what it is doing. If that doesn't work then I can give you the profiling build to see which calls are causing the most slowdowns.
Here is the latest build: dxwrapper.zip
just tried the latest build with UseShadowBackBuffer
it still has slow downs ~~also idk if this is related but if i try rebinding keys in the game settings page, the newly entered keys appear as NumLock no matter what~~ its unrelated
New Log: dxwrapper-igi.log
Ok, here is the profiling build. Please use this an then upload the log file once you have experienced the low frame rate issue: dxwrapper.zip
It appears that each frame takes around 110ms. That is less than 10 frames per second.
I see hundreds of calls per-frame to Lock the vertex buffer and then to draw, like this:
212 23:25:33.211 m_IDirect3DVertexBufferX::Lock (00FFBED0) hr = DD_OK Timing = 0ms
212 23:25:33.211 m_IDirect3DDeviceX::DrawPrimitiveVB (00FF9548) hr = DD_OK Timing = 0ms
Most calls take less than 1ms, but it only takes 3 or 4 of these pairs to take 1ms. This means the pair takes a quarter of a ms. I believe the issue is related to locking the vertex buffer because I can see places in the log where hundreds of draws are called without locking the buffer and they are much faster.
There are a few reasons why this call might be slow:
- It is possible that these are converting from LVERTEX, which requires manually manipulating each vertex. Note: I'm not sure if the game uses LVERTEX.
- When locking a buffer the whole buffer is locked even if only a small amount of the buffer is modified. If the buffer is in video memory then the whole buffer needs to be transferred from system to video memory, which is very slow, even if the draw call only uses a small part of the buffer.
- It looks like the game uses a single buffer for everything so it is quite possible that the buffer is very large, causing the slowdown. Other older games, like Star Trek Armada do this same thing.
- For every call to Lock the video driver might be setting a system lock, which is also expensive.
Try this build. I added a new option for DdrawNoDrawBufferSysLock which might help you in this case. Also I enabled ForceSystemMemVertexCache which might help if this game has a large vertex buffer that keeps getting locked.
The below features are enabled in this build's ini file:
[Compatibility]
Dd7to9 = 1
[Dd7to9]
DdrawUseShadowSurface = 1
DdrawNoDrawBufferSysLock = 1
[d3d9]
ForceMixedVertexProcessing = 1
ForceSystemMemVertexCache = 1
GraphicsHybridAdapter = 1
Here is the new build: dxwrapper.zip
game is generally faster now but it still has some issues especially when looking at distance
Thanks. I see that the vertex buffer is very large:
196 03:32:52.724 m_IDirect3DVertexBufferX::CreateD3D9VertexBuffer Create vertex buffer: DD_OK Size: 1877800 Usage: 0x208 FVF: 0x212 Pool: 0x0{16,0x10000,0x212,46945}
In this case there are 46,945 vertices in this buffer. The size is over 1.8 MBs. That is a lot of data to upload to video memory 100's of times per-frame.
How does the game run without dxwrapper? I am trying to understand how much of the slowdown is related to dxwrapper and how much is related to the game design.
The game runs pretty well with ~~some~~ many geometry errors and vertex explosions on WineD3D without dxwrapper
I still have some memory of playing the game on Windows way before which also didn't have any slowdowns
I added some very minor performance changes which probably won't affect this game. However, I did make a change to temporarily remove the D3DCREATE_MULTITHREADED flag. This can speed up the game a little bit but also can cause crashes in some games. You can try the build without this flag. I can add an option to remove this flag if there is noticeable performance saving.
Here is the build without the D3DCREATE_MULTITHREADED flag: dxwrapper.zip
Note: I think the difference here is how DirectDraw handles the vertex Lock() vs. how Direct3D9 handles it. I don't really have control over that.
latest log: dxwrapper-igi.log
there is still some slow downs when looking at certain places but other areas have become better performing
ingame cutscenes and menu still has some slowness sorry for not mentioning that before
there is still some slow downs when looking at certain places but other areas have become better performing
Ok, I will make an option to remove the D3DCREATE_MULTITHREADED flag unless the game requests it.
ingame cutscenes and menu still has some slowness
This is probably related to something else and not the vertex Lock issue. Usually this is related to surface Blt() or GetDC() speed. But I would need to look into this separately. A fix for this is probably not happening very soon. The DdrawUseShadowSurface option should help with this somewhat but isn't a full fix.
Note: I think the difference here is how DirectDraw handles the vertex Lock() vs. how Direct3D9 handles it. I don't really have control over that.
Oh, one other thing you could try is using dxvk. dxwrapper can convert the game to d3d9. Then you can use dxvk to convert the game from d3d9 to vulkan. Sometimes this will help with some games, especially on Linux/Wine.
tried pairing dxwrapper with dxvk and it seems like there's an issue with the models warping sometimes and the stutter is still there
ill also try contacting the creator of the patch to see if he could provide some insights of his