Regarding broken scaling, an Nvidia employee confirmed there's a fix which will appear in a driver to be released in October.

In other news, Return to Krondor FMVs are still broken. There's sound, but no video in 2.44 and 2.45 regardless of in-game stretch setting and driver scaling setting and FMV is a pretty big part of the story-telling I'm afraid. Expack3 said the FMV was misplaced mostly off-screen, though I was personally unable to find a pixel of it. This is one of countless old games I get flickering in (only in 3D mode, not in menus) on my GTX 970, so dgVoodoo's the only way I'll play this one anytime soon.

MGS is one of the very very few handful pre-DX8 games to do pixel buffer effects so the incompatibility is not too surprising.

Voodoo2s aren't 100mhz stockGeforce256 isn't released as a beta on New Years '99 under the Quadro brandDOS gaming isn't a bilinear 320x200 16:10DOS PCs aren't better than the MacintoshDOSBox is not for running Windows 9xSGL != Glide

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?

Response to Dege

Hmm... I never try games in multiplayer mode because configuring them for MP always looks complicated (to me).I guess this game does not work for you with native DX, but somehow it should be seen if fps drop has something to do with dgVoodoo.One general thing that can be checked: if fps drops less with lower resolutions than higher ones then it has a good chance that it's rendering related.I'm not sure, but if multiplayer mode uses network communication then even a "bad" network handling with high implicit time-delaying can cause fps drop.

(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.

I can say definitively that low framerate is a widespread problem that most Jedi Knight players experience with dgVoodoo. Those who are fortunate enough to have NVIDIA GPU's generally do not require dgVoodoo to play this game and have no framerate issues.

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.

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 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.

Thank you for your fascinating answer Dege. We in the community have been looking for insight into why this happens for some time now.

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.

When the last couple of versions of dgvoodoo were released and I noticed this feature - I tried it out and I noticed a small improvement in FPS under certain circumstances.

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.

Please let me know what I can do to assist with this. This issue affects many players and I would love to get this resolved!

EAH_XxHeReTiKxX wrote:Please let me know what I can do to assist with this. This issue affects many players and I would love to get this resolved!

I'm going to implement the needed things in the next version. I can test it with other games that suffer from this readback thing. When it's ready, I will upload a new WIP version for testing and see if it helps Jedi Knight.

I'm not sure when a new version will be available. Unfortunately there are still internal things I would like to change before, but in spite of that, I may release an "intermediate" WIP for testing fixes made for other things.

Very exciting news Dege. We are eagerly anticipating the next version of dgVoodoo.

One thing I wanted to mention quickly is that when using dgVoodoo, toggling the in-game score screen ON (with multiple players in-game) in Jedi Knight/Mysteries of the Sith drops the framerate severely.

This is not caused by MP netcode because non-dgVoodoo/NVIDIA players do not have this issue.

This would be a good symptom to explore to see if it is due to the readback problem because it reliably causes low framerate.

I also just read the discussion on page 57 about games getting capped at 60FPS with dgVoodoo. Jedi Knight/Mysteries of the Sith seems to be one of those games.

Returning to thanks dgvoodoo one more time, i recently started using dgvoodo 2.44 and 2.45 and fixed a lot of oldies games, follow the list of some games that are fixed for me:

-Take no Prisioners - was unable to play in d3d mode, fixed with dgvoodoo 2.44 by adding its dlls to game game folder (ddraw.dll and 3dimm.dll)-Mage Slayer - same engine from the game above fixed on the same way-Captian Claw - Very pop 2d plataformer was messed up colors issue, added dgvoodoo dlls and fixed it, no more need to kill explorer or use more complex workaround-Baldies - A win 95 game that was unplayble on modern hardware due to messed up color and ultra high speed, fixed with dgvoodoo ddraw.dll on game folder, plus some workaround on video card profiles, due to in game the speed was stabilized by ddraw.dll but in game menus the frame rate was greater than 1000fps, than your should force vsync on video card-Grouch -A funny 3d action fantasy based game that was fixed by dgvoodoo, the game was unable to render black areas making parts of objects transparenty-Dark Reign -Fixed messed up color, no need to kill explorer anymore-Overboard -Pirate themed game that have various graphics problems solved with dgvoodoo

There many other that i dont remenber right now, but when i got and oldie that is with problems, first thing to try is dgvoodoo. Please share this info, there are many people trying to runs those games too.

There two games that i would like to get fixed with dgvoodoo

-g-police - has the same problem groch was, dgvoodoo fix it but the game crash on transition from ingame to menu-stratosphere - conquest of the skyes - unique themed game where you build and fly on a fortifyed rock, acctually playable but with very creepy graphics, tryed dgvoodoo on it and graphics was improved much, but there are some glitches and flickering.

Not yet, unfortunately. I'll try to emulate that case by enumerating a lot of dummy resolutions for debugging.

duduba wrote:Returning to thanks dgvoodoo one more time, i recently started using dgvoodo 2.44 and 2.45 and fixed a lot of oldies games, follow the list of some games that are fixed for me:

-Take no Prisioners - was unable to play in d3d mode, fixed with dgvoodoo 2.44 by adding its dlls to game game folder (ddraw.dll and 3dimm.dll)-Mage Slayer - same engine from the game above fixed on the same way-Captian Claw - Very pop 2d plataformer was messed up colors issue, added dgvoodoo dlls and fixed it, no more need to kill explorer or use more complex workaround-Baldies - A win 95 game that was unplayble on modern hardware due to messed up color and ultra high speed, fixed with dgvoodoo ddraw.dll on game folder, plus some workaround on video card profiles, due to in game the speed was stabilized by ddraw.dll but in game menus the frame rate was greater than 1000fps, than your should force vsync on video card-Grouch -A funny 3d action fantasy based game that was fixed by dgvoodoo, the game was unable to render black areas making parts of objects transparenty-Dark Reign -Fixed messed up color, no need to kill explorer anymore-Overboard -Pirate themed game that have various graphics problems solved with dgvoodoo

There many other that i dont remenber right now, but when i got and oldie that is with problems, first thing to try is dgvoodoo. Please share this info, there are many people trying to runs those games too.

There two games that i would like to get fixed with dgvoodoo

-g-police - has the same problem groch was, dgvoodoo fix it but the game crash on transition from ingame to menu-stratosphere - conquest of the skyes - unique themed game where you build and fly on a fortifyed rock, acctually playable but with very creepy graphics, tryed dgvoodoo on it and graphics was improved much, but there are some glitches and flickering.

Thanks againRegards

Thanks for the report! Now I'm in a hurry coding of dgVoodoo internals. Unfortunately it's not a bugfixing coding period because very basic things are under refactoring/development (which means a huge risk factor for breaking working things), so only when it's done I can test particular games again.

The things now is that I secretly planned DX8 support long ago and recently I realised that it's worth better to do the needed internal improvements before any other additional development to avoid 'double bugfixing' later (even if DX8 won't be part of the next version).Of course I keep testing the wrapper continuously to avoid breaking things but the current state is still not a final one.

Jedi Knight has very strange rendering. It seems the actual FPS is half of what is actually indicated if 60FPS or above. For whatever reason, frames of the game world are not updated as often as the FPS counter suggests.

For example, at 60 FPS, the game seems closer to 30FPS despite showing 60.

My only guess is that this crude framerate limit was intended for the first person weapon model layer but was applied to the game world layer instead, as they seem to animate at their own intervals, and the weapon models notoriously animate too fast at higher framerates. Perhaps machines back during development time didn't run the game fast enough for the mistake to be apparent.

EAH_XxHeReTiKxX wrote:Perhaps this strange behavior is a cause of the poor performance?

I recently decided to get JK running and immediately noticed the jerky camera / hyperspeed weapons at 60 fps. It seems to be a trait of the engine (I'd be curious to see how the game looked at 60 fps when it came out).

Anyway, you can improve things a bit by locking the framerate to 47 (48 in my testing) or below. Explanation Do this and you'll at least get that many FPS plus weapon animations playing at proper speed (a godsend for the lightsaber). Personally I lock it at 40 because I run my monitor at 120Hz and the even divisor prevents the stutter I see at 47. I'm satisfied with that.

I've tried to utilize 32bpp rendering of the Napalm build of the glide3x.dll in the NFS3 Modern Patch. But it seems that it doesn't work correctly How to reproduce:1. Download: http://veg.by/files/nfs3/outbin.zip2. Extract to the NFS3 directory.3. Replace drivers/dgvoodoo/glide3x.dll to the Napalm build.4. Run the game, choose any 32bpp resolution in the settings, start race.

In my case all 3D objects aren't displayed when 32bpp rendering is used. For enabling 32bpp rendering I'm using grSstWinOpenExt(hWnd, resolution, refresh, color_format, origin, pixel_format, nColBuffers, nAuxBuffers) with pixel_format = GR_PIXFMT_ARGB_8888 (0x0005). Address of the grSstWinOpenExt is got by grGetProcAddress("grSstWinOpenExt"). Support of 32bpp rendering is checked by executing grGetString(GR_EXTENSION) and searching substring PIXEXT.

nGlide works without problems with this code. What do you think about this? What is the cause of the problem: something in the NFS3, or something in the dgVoodoo? It would be very nice to test it on the real 3dfx Voodoo 5, but I don't have any 3dfx Voodoo

VEG wrote:I've tried to utilize 32bpp rendering of the Napalm build of the glide3x.dll in the NFS3 Modern Patch. But it seems that it doesn't work correctly

Indeed, no any 3D objects can be seen. I've just debugged a little to see what's going on, and I can say the following:

- The game uses Z-buffering (instead of W-buffering), I'm not sure if it's normal- In 32 bit display mode, the voodoo's depth buffer is 32 bit wide too, using only 24 bits for depth values (8 bits unused)- Because of this, the type of 'depth' parameter of grBufferClear is changed from FxU16 to FxU32 in the Glide3 API- If a 16 bit z-buffer is used then the depth range for grBufferClear is 0x000000 - 0x00FFFF; if a 32 bit one is used then the range is 0x000000 - 0xFFFFFF- W-buffering uses 3Dfx's 16 bit float format (which is extended to 24 bit in the W-buffer by the Voodoo hardware during rasterization and buffer clearing), but grBufferClear still expects it in the 16 bit format specified in the SDK

So, if one ports an old Glide app from 16 bit to 32 bit rendering then the Z-values for grBufferClear must be scaled to 24bit too. In case of w-buffering, the code can be left unchanged.NFS3 calls grBufferClear with depth = 0xFFFF. If I change it to 0xFFFFFF then the frames are rendered correctly.

Maybe I'm wrong, but I studied the Glide3 Napalm source carefully to put these things clear back when I was coding the Napalm version.