It looks fine. 32 bit rendering, there is no color banding.

Silanda wrote:

My observation with Jedi Knight is that the game's menus are unstable whatever you do when running on Windows 8. It seems more stable with dgVoodoo than without though. Some of the resolutions in software mode crash with dgVoodoo whether the -windowgui switch is used or not. I haven't tested this much but the game actually reports more resolutions available using dgVoodoo than it does with native DDraw, and it may be these extra resolutions that crash.

I did a few more tests. The game shows the same resolutions in softwaremode with and without dgVoodoo however higher resolutions now also crash the game without the wrapper. These resolutions used to work and I think the problem might have to do with the fact that I recently upgraded my driver.

Dege wrote:

It looks fine. 32 bit rendering, there is no color banding. […]
Show full quote

It looks fine. 32 bit rendering, there is no color banding.

Lovely!

I wanted to download those old SDK's from there but the files were removed.

found them over here too
http://www.alexstjohn.com/WP/2013/02/08/direct-downloads/

Seems to work great with Kiss Psycho Circus except for the finicky mode setting. I can't get it to 1920x1080 at times.

Oh btw no banding here. though it does suck the game's textures are all 16bit formats and has nothing to do with the API or the wrapper, but rather the engine's development in the 1st/2nd gen 3d card era, being tailored for the Voodoo1-2 line and the older Rages and Rivas.

Jedi Knight always crashes when I start a new game/load game. First I see the Watermark on the right bottom, then the screen is completely black and JK closes itself without a message.

Before some tests I got the "a error occured" window and could start visual studio debugger. It said that there is an execption at 0x08F2B7EC in D3DImm.dll (JK.EXE: 0xC0000005: segmentation fault by reading at position 0x00000001).

Did I something wrong, or is this an issue in dgVoodoo? I copied D3DImm.dll, DDraw.dll and dgVoodooSetup.exe into the game folder. I set hardware acceleration on and resolution to 1920x1080 (also 1024x786).

My system:
Microsoft Windows 8.1 Pro (6.3.9600 Build 9600)
AMD FX-6300
AMD Radeon HD 7750 (14.12 AMD Catalyst)

You have multiple monitor setup? The same thing happens for me when both monitors are on otherwise its good.

Little Big Adventure 2 actually works with FunnyFrog's patch. Is what that patch does interesting info?

What causes the display problem and how is it fixed? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LBA2 doesn't query d […]
Show full quote

What causes the display problem and how is it fixed?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LBA2 doesn't query display driver for pitch value (the difference between
addresses of the first pixels of two consecutive lines of image) at the right
time. It apparently uses the value returned by IDirectDraw.EnumDisplayModes
method, which may be incorrect with some drivers. The patch changes the code to
read the pitch value after each call to IDirectDrawSurface.Lock.

(in dgVoodoo2 there is no display problem; it just crashes).

found them over here too
http://www.alexstjohn.com/WP/2013/02/08 ... downloads/

THANKS!! 😎

Seems to work great with Kiss Psycho Circus except for the finicky mode setting. I can't get it to 1920x1080 at times.

Isn't it because LithTech cannot handle resolution >1000 lines as ZellSF wrote?

You have multiple monitor setup? The same thing happens for me when both monitors are on otherwise its good.

It strange. Did one monitor setup solve the problem?
It shouldn't be an issue anyway. Could you tell me what is the base address of D3DImm.dll when seeing the crash in the debugger? Maybe I could check what crashes.

(in dgVoodoo2 there is no display problem; it just crashes).

Thanks for that, I've just fixed it.

(BTW, with dgVoodoo, pitch values are always matches the surface width to avoid cases like that. There are a lot of games handling pitch badly.)

Edit: BTW, G-Police seems to work fine now.

Dege wrote:

You have multiple monitor setup? The same thing happens for me when both monitors are on otherwise its good.

It strange. Did one monitor setup solve the problem?
It shouldn't be an issue anyway. Could you tell me what is the base address of D3DImm.dll when seeing the crash in the debugger? Maybe I could check what crashes.

No sorry, I only have one display (AMD Catalyst says the same).

Here some information from VS debugger:

exception at 0x08FCB7EC (D3DImm.dll) in JK.EXE: 0xC0000005: segmentation fault by reading at position 0x00000001

JK.EXE 00400000-008F5000 [3732] JK.EXE
D3DImm.dll 08FB0000-0901D000* [3732] JK.EXE
DDraw.dll 10000000-1002B000 [3732] JK.EXE

Call stack:
> D3DImm.dll!08fcb7ec()
D3DImm.dll!08fcd78e()
JK.EXE!0042ac06()
JK.EXE!00443d3c()
JK.EXE!0043abea()
JK.EXE!00401f58()
JK.EXE!00403d0e()
JK.EXE!004039cb()
JK.EXE!0050e99d()
JK.EXE!0041ebee()
JK.EXE!00513b3f()
[extern code]

Dege wrote:

Isn't it because LithTech cannot handle resolution >1000 lines as ZellSF wrote?

It can "handle" it (as in display a 1920x1080x32 screen with Vert-), it just seems to have trouble recognizing the mode is there and setting it. Often have to alt-tab for it to change to 1080

There are huge slowdowns when a bunch of gibby dismemberment carnage happens (particularly surrounded by 2 headless spawners giving you a crapload of headlesses while you slice and dice every one of them) and when you use the save/load menu, but I consider that slowdown as part of the immersion 😜 and phong is off i'm sure

Looks like all of the Direct3D 3 games I've tried so far have the same depth sorting issues as Hellbender. (Hellbender, Outwars, and CART... perhaps it's a common trait of Direct3D 3 where it lacks depth sorting/is buggy? Perhaps the information is backwards?) Hopefully some solution can be found.

I remember there being ONE video card I've used in the 90s that didn't have the sort issues, but I cannot recall which. Probably the card they had in mind when the game was designed. (A Diamond Monster card, iirc.)

The reason I think its backwards is because when two polygons intersect, it's always the nearest polygons that get rendered behind the farthest intersecting polygons. If the sorting was inverted, it would likely look right.

Just a couple of updates on my experiences based on the latest release:

Bridge Commander: Some textures are missing and/or the lighting seems screwed up (too dark, like some lights are missing), the viewscreen still has a ghosting problem where anything displayed over it (e.g. mouse cursor) isn't cleared.
Shadows of the Empire: Except for the missing fog it's fine now for me. The only minor issue is that the text is nearly illegible. This is a problem to a lesser extent when running without dgVoodoo.

X-Wing vs Tie Fighter (GoG release) almost works except that the game crashes a few seconds after entering flight mode both in software and hardware mode.

Update:
I just noticed that the main game of XvT seems to work completely fine (dgvoodoo even fixes most of the issues the game has when enabling 3D mode), it's only the addon (Balance of Power) that crashes all the time.

There are even training missions that are exactly the same in both games and the mission runs without problem in XvT but crashes immediately in BoP.

Another quick report.

Rogue Squadron: No in depth testing here but the game appears to work in D3D mode, with one snag. The launcher does not recognize D3D modes as available if dgVoodoo is used. The mode has to be selected and the dgVoodoo files added afterwards.

Call stack: > D3DImm.dll!08fcb7ec() D3DImm.dll!08fcd78e() JK.EXE!0042ac06() JK.EXE!00443d3c() JK.EXE!0043abea() JK.EXE!00401f58( […]
Show full quote

Call stack:
> D3DImm.dll!08fcb7ec()
D3DImm.dll!08fcd78e()
JK.EXE!0042ac06()
JK.EXE!00443d3c()
JK.EXE!0043abea()
JK.EXE!00401f58()
JK.EXE!00403d0e()
JK.EXE!004039cb()
JK.EXE!0050e99d()
JK.EXE!0041ebee()
JK.EXE!00513b3f()
[extern code]

I installed JK and reproduced the same callstack (without crash).
However what I don't understand at all is that JK calls into DirectDraw at that point (blitting), not into D3D.
The crashing point you posted is in a SetViewport method with an invalid data pointer. More misty is, that pointer couldn't be invalid (0x00000001) under any circumstances because it's an address within the stack. 😕 😕
The only explanation for "miscalling" is some object pointer corruption in the game itself (if corruption came by a random memory filling from somewhere else then there is 0 chance to overwrite an object pointer with an other valid object pointer).
I forgot to mention that I always use the original version of games to try with dgVoodoo, without any additional game plugins or something.
Did you tried the orig version of JK or some modified one?

There are huge slowdowns when a bunch of gibby dismemberment carnage happens (particularly surrounded by 2 headless spawners giving you a crapload of headlesses while you slice and dice every one of them) and when you use the save/load menu, but I consider that slowdown as part of the immersion 😜 and phong is off i'm sure

I will search for a savegame to reproduce such a slowdown situation and check it. (Phong is irrelevant here because LithTech does T&L calculations on its own.)

Looks like all of the Direct3D 3 games I've tried so far have the same depth sorting issues as Hellbender. (Hellbender, Outwars, and CART... perhaps it's a common trait of Direct3D 3 where it lacks depth sorting/is buggy? Perhaps the information is backwards?) Hopefully some solution can be found.

Is there possibility of using savegames in Hellbender? If I could reproduce a scene where the issue comes then I could check what happens by native DX.

Thanks for the new reports BTW!

Dege wrote:

I installed JK and reproduced the same callstack (without crash). However what I don't understand at all is that JK calls into D […]
Show full quote

I installed JK and reproduced the same callstack (without crash).
However what I don't understand at all is that JK calls into DirectDraw at that point (blitting), not into D3D.
The crashing point you posted is in a SetViewport method with an invalid data pointer. More misty is, that pointer couldn't be invalid (0x00000001) under any circumstances because it's an address within the stack. 😕 😕
The only explanation for "miscalling" is some object pointer corruption in the game itself (if corruption came by a random memory filling from somewhere else then there is 0 chance to overwrite an object pointer with an other valid object pointer).
I forgot to mention that I always use the original version of games to try with dgVoodoo, without any additional game plugins or something.
Did you tried the orig version of JK or some modified one?

Oh sorry, I forgot to say that I use the gog.com version of JK. But it seems that lots of people use your fix with this version and I'm the only one, who get that crash.
(see: http://www.gog.com/forum/star_wars_dark_force … s_for_all/page1)

I also have the CD version of JK without MOTS and I tested dgVoodoo with that version. It works. It seems that gog did some own fixes in the rendercode and under some circumstances it comes to a incompatability between dgVoodoo and JK gog.com version. I also noticed that the CD version uses dgVoodoo in the main menu, gog.com version does that not, not before new game/load game.

Here is the asm code that calls the SetViewport Method:

1...
20042AB80  ?? ?? 
30042AB81  ?? ?? 
40042AB82  ?? ?? 
50042AB83  ?? ?? 
60042AB84  ?? ?? 
70042AB85  ?? ?? 
80042AB86  ?? ?? 
90042AB87  ?? ?? 
100042AB88  ?? ?? 
110042AB89  ?? ?? 
120042AB8A  ?? ?? 
130042AB8B  ?? ?? 
140042AB8C  push        ebp  
150042AB8D  add         byte ptr [ebx-3Dh],bl  
160042AB90  sub         esp,74h  
170042AB93  push        edi  
180042AB94  mov         ecx,19h  
190042AB99  xor         eax,eax  
200042AB9B  lea         edi,[esp+14h]  
210042AB9F  rep stos    dword ptr es:[edi]  
220042ABA1  mov         eax,dword ptr ds:[00865258h]  
230042ABA6  mov         edx,dword ptr ds:[865328h]  
240042ABAC  sub         eax,10h  
250042ABAF  mov         ecx,dword ptr ds:[865324h]  
260042ABB5  neg         eax  
270042ABB7  sbb         eax,eax  
280042ABB9  mov         dword ptr [esp+8],ecx  
290042ABBD  and         eax,0FFFFh  
300042ABC2  mov         dword ptr [esp+14h],64h  
310042ABCA  mov         dword ptr [esp+64h],eax  
320042ABCE  mov         eax,dword ptr ds:[00865320h]  
330042ABD3  mov         dword ptr [esp+4],eax  
340042ABD7  add         eax,edx  
350042ABD9  mov         dword ptr [esp+0Ch],eax  
360042ABDD  mov         eax,dword ptr ds:[0086532Ch]  
370042ABE2  add         ecx,eax  
380042ABE4  mov         dword ptr [esp+10h],ecx  
390042ABE8  mov         eax,dword ptr ds:[0055C4BCh]  
400042ABED  lea         edx,[esp+4]  
410042ABF1  mov         ecx,dword ptr [eax]  
420042ABF3  push        0  
430042ABF5  push        0  
440042ABFA  push        0  
450042ABFC  push        2  
460042ABFE  push        edx  
470042ABFF  push        1  
480042AC01  push        eax  
490042AC02  nop  
500042AC03  call        dword ptr [ecx+50h]                 ; here is the last call to D3DImm.dll
51...

Mhm maybe it calls the method wrong (push 1 -> wrong push order?) or DirectDraw interpret the arguments differently than your version (for example: if the arguments are invalid, use other arguments). Just my speculation 😉 . Is that possible?

TriHexagon wrote:

I also have the CD version of JK without MOTS and I tested dgVoodoo with that version. It works. It seems that gog did some own fixes in the rendercode and under some circumstances it comes to a incompatability between dgVoodoo and JK gog.com version. I also noticed that the CD version uses dgVoodoo in the main menu, gog.com version does that not, not before new game/load game.

Is there a sdb file in your JK folder? If so could you upload it?

Do you mean the JK gog version? There is one, but not in the folder of the CD version.
https://www.dropbox.com/s/41amb99aedh6mlc/goggame.sdb?dl=0