EAH_XxHeReTiKxX wrote:FRAMERATE PROBLEMS WITH DGVOODOO 2.45 - JEDI KNIGHT: DARK FORCES 2 AND MYSTERIES OF THE SITH
UPDATE 11:50 AM EST: RadeonPro with VSYNC off only crashes Jedi Knight when you launch the game in windowed menu mode with the -windowgui switch.
UPDATE 12:23 PM EST: Framerate increases dramatically as I lower resolution. I.E 150-200FPS @ 1280x720. Why does framerate suffer so much at high resolution with dgVoodoo? On such an old game shouldnt we be able to achieve much higher framerates?
This symptom implies that the game applies direct access to some of its rendering buffers, through the CPU (some hud element, subtitle, cockpit, anything that is not rendered by the GPU in a 3D-way).
Unfortunately this type of access is slower than natively. While the (old style, out-of date) native way allows applications to reach video memory directly, the modern way (like DX11) doesn't.
This means that dgVoodoo has to do a readback from video memory to system memory to emulate this. Altough readback from video memory is done by the GPU and improved a lot compared to, say, hardware architectures of 10 years ago, it's still slow if done very frequently during rendering a frame. Say, the game renders something and wants CPU-access n-times if n gamers are present then the wrapper has to do n readback in the worst case. The higher resolution the more data to move. The more cumulates the slower rendering a frame will be.
The only solution would be porting the 'partial-access' method present in the Glide wrapper to the DX wrapper. It's on my todo list but still not implemented. 🙁
What if 'Fast videomemory access' is enabled? It won't solve the readback problem but can 'defer' it resulting in minimizing it's number.
(Edit: in some games it's also common to lock and access the depth buffer by the CPU to check if something is in occlusion, like the sun for a lensflare effect. The best practical example for this is game Pyl (Glide) which locks the depth buffer multiple times during a single frame to see if the environmental light sources are occluded and decide to render or not their aura. Without partial readback that game is unplayably slow.)
EAH_XxHeReTiKxX wrote:(When using dgVoodoo)
1) Framerate on Jedi Knight suffers SEVERELY as more players join.
2) Players who cannot use native DX are […]
Show full quote
(When using dgVoodoo)
1) Framerate on Jedi Knight suffers SEVERELY as more players join.
2) Players who cannot use native DX are the ones who use dgVoodoo.
3) FPS improves as you lower the resolution.
4) Other players who do not have to use dgVoodoo do not have this FPS problem even in large games.
5) VSYNC OFF helps, but framerate apperas to remain severely impaired, especially in large MP games.
vSync off in dgVoodoo setup doesn't mean vSync off for the game. If it's unchecked then just the forcing of vSync is disabled. There is no option for forced-off vSync in dgVoodoo.
EAH_XxHeReTiKxX wrote:
Dege thank you for your help. I noticed earlier in this thread you mentioned old DX SDK's. I have many of them going back to the mid 90's. Let me know if you want them.
Thanks, now I have them all. At least, what is needed.
Of course, I would like to check the exact reason of the slowdown myself to see if my theory is true.
I haven't really cared the readback-problem so far because only in a few game it appeared, but it seems more and more urging to improve it.