First of all: to avoid using the windows compatibility mode I checked the "handle exceptions" flag under Compat tab to be able to pass the intro screen, resulting in a black screen with the audio track in the background (same behaviour using the windows compatibility mode)
I have tried under windows 7 and 10.
Everything else seems to work perfectly during gameplay.
Things I tried: I checked every flag on the directx, video or tweaks tabs and this is what I found.
I am able to "watch" the intro if I change Emulation renderer to primary buffer only in windowed mode but the palette is all corrupted (if I make a screenshot the result is a black window ??¿? So I captured it with the phone...)
The other way is to activate de flag ddraw:LockColorDepth under the Tweaks tab. But the result is similar with different palette and the image is streched (although I can make a screenshot).
Can someone help me to make it work properly?
Regards and congratulations for this amazing software.
I repeated your experiments and found them very interesting. So far, I thought that in my RIP the movie was simply missing from the files on hard disk, but the test with primary buffer proves I was wrong. Unfortunately the logs show a quite weird way to blit the movie on screen, with QueryInterface operations with IID_Unknown interface and other things I still have to analyze.
The failure seems related to a DDERR_NODC error code on a ReleaseDC operation, also this error somehow puzzling me.
Well, I think that now I need more time and some luck to understand and fix the problem. Stay tuned ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I read the logs for all ddraw blitter modes and in the end I think I got something: despite the complexity of the logs, the reason for the black intro is pretty simple: in emulation mode the game sets a black palette adter the company log, making the whole intro and outtro fully black.
To be certain of this fact, I added a debug flag to my WIP dxwnd release to force a random palette with non-black colors no matter what you set in the SetPalette wrapper. The result showed a game with scrambled colors, but with a meaningful intro movie (see screenshot).
So, this slightly shift the problem: I don't have to understand why the movies are not rendered to screen, but instead why the palette is cleared.
Something to investigate:
The game shows the company logo for about 5 seconds and during that period it defines a palette and changes its values with DDrawPalette::Setentries to make the appearing / disappearing transition effect. At the end of these 5 seconds the palette is fully black and the new video segment should appear. If you look at the following log you can see the last SetEntries definitions (all 00, that is all black) and soon after that I would expect to see a new palette definition, but you see an exception instead.
So, my guess is that for some reason (hopefully to be fixed) the new palette is not built and the blackened one remains active. Probably with "primary buffer" mode the logical palette defined for ddraw emulation is not considered, so you can see "something" that is at any rate something wrong.
To be continued ...
Last edit: gho 2019-01-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, you can feed it to VLC Media Player that is able to play it and show 26 seconds of .... complete blackness. I fear that the movie expects something to set a proper palette during play.
BTW did you have some information about the DJ.DAT internal structure? That could be interesting for other types of hacks ...
Last edit: gho 2019-01-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Vlc fails in this case.
But you can play it in mplayer, smplayer, mpc-be (here the player crashed if I switch to fullscreen). Also with lav filters (and flic format enable) I can play video in potplayer.
In Windows 95, you could install aflc codec (Autodesk.Animator.v1.11.Codec.exe), but according to some discussions it is no longer compatible with WinXP.
I have no information about the structure of DJ.DAT.
Intro and other two .fli, I extracted over one old tool.
Intro starts at offset 17DD55E and ends 221AFB1 (I think).
Fli have 320x200, 8 bits, 14.00fps
Potplayer says input type 32-bit RGB and output type YUY2 16bits.
Mplayer says - videocodec [fffli] vfm: ffmpeg (Autodesk FLI/FLIC Animation)
bicubic scaler from pal8 to yuv420p using MMXEXT, VO: [direct3d] 320x200 Planar YV12.
Last edit: huh 2019-01-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, the offset is wrong (it was a offset of another video).
Intro starts E174B7 and ends 17DD55D.
Edit:
Videos are in DJ.DAT in one block.
Offsets:
E174B7-17DD55D
17DD55E-221AFB1
221AFB2-222E110
But the problem is certainly with setting palette as you wrote.
If I set compatibility with Win98 in my virtual XP, video is black.
But after switch alt + tab or Win + D and back, the video is black and white.
This routine seems to manage all palette transitions, both for the company logo, the black movie and what follows. You can see there some essential parts: 00401EDD JNZ SHORT 00401EA3 where it loops for 256 times to define each palette entry color and 00401EFA CALL DWORD PTR DS:[ECX+18] where it calls DirectDrawPalette::SetEntries.
Palette colors are written to memory location starting from 0x4116A8 (at least, on my session) and during the black movie this code is not referenced ....
In reality I'm not too sure: in two debugging sessions I got different results, one with (apparently) the palette updated with BLACK colors, the other with the palette not updates. I fear some synchronization trouble ...
Last edit: gho 2019-01-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A few additional notes:
1) the black part of the movie seems to lack also some sound. Forcing some output to screen (you can now use the v2.05.03 release with the debug "Random palette" flag) you can see some scenes where it makes sense to have some music plus some speech, while you can hear nothing. Is the audio missing together with the palette info? Are they both part of the same problem?
2) setting some fake I/O device (for instance, emulated HD drive Z: on "Z:\") and in Logs "System libs" + "debug" flags you can trace all I/O operations attempted by the program. Curiously, there seems to be no other file but DJ.DAT where the program reads multimedia data (other files are CONFIG.INI and HISCORES.DAT), so sounds and palette should be there...
3) A doubt: did anyone actually see this part of the movie on Win95/98/ME? I tried the game on a WinXP virtual machine where the assembly exceptions don't occur (they are caused by not allowed I/O instructions since Win7) but the result was the same: silence and blackness.
4) I'm trying the game with a RIP game version, since the full CD is reported as not installable. But I wonder if the full CD hides something that wasn't copied on the RIP. Later I'll try to compare files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) The soundtracks are stored in the CD as wav files. The intro sounds (track 2) if you mount the full version of the CD, not the rip. I attach the file structure of the full CD.
3) I tried a win98 virtual machine and It worked at is should, video and sound.
A possible track:
reading here https://www.compuphase.com/palette.htm you find that on Win95 the DirectX palettes in "exclusive mode" is inactive, so it could be bypassed by writing directly to the hardware palette through I/O assembly instructions.
Now, back to this assembly
This is the OllyDBG description of the REP OUTS instruction:
Copies ECX words from the memory to the hardware port.
On each iteration, processor reads byte from the memory at address ESI and sends it to the port addressed by the content of the 16-bit register DX.
If flag D is cleared, increment ESI by 2, otherwise decrements ESI by 2.
Register ECX is always decremented by 1.
If ECX after decrement is zero, operation stops; otherwise processor repeats the whole cycle again and again until count exhaust.
Note that if ECX initially contains zero, this instruction does nothing.
When first entering this instruction loop I found ECX = 0x100 = 256 ... quite a coincidence?
My guess is this: while the company logo part of the intro is managed with clean ddraw methods and the Windows palette manager, the second part (probably inherited from some DOS leftover) directly pushes the palette values to the hardware palette through this instruction.
If this is true, it could be possible (with some crazy effort) to identify this specific pattern and within the DxWnd exception handler to replace the assembly clearing (replacement with NOP instructions) with a copy from the address pointed by ESI to the DxWnd emulated palette.
The operation will also require some knowledge about the hardware palette format, since the dump from ESI doesn't follow the typical 4-bytes RGBX pattern of the PALETTEENTRY structure. Here is a sample:
@Jarkan: I read now your previous post. Thank you for the information, that will save some time.
Two essential things:
1) the sizes of DJ.DAT are identical, so the RIP should have the same info as the full version, that is good. If my previous post is right, maybe there's a possibility to make a fix.
2) the audio is on CD tracks, but the game doesn't link to WINMM calls for CD playing (like mciSendCommand or mciSendString). It doesn't even hold these call name strings (searched with a hex-editor) for a possible late-binding with GetProcAddress. This is a big problem, because it could mean that likely the game sends direct commands to the CD driver, something that DxWnd can't emulate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to give you an idea, this experimental release moves to the DxWnd logical palette whatever is pointed by the ESI register when the exception occurs. It's far from ok, but you can see the possibility to guess the proper palette disposition .... perhaps.
On last DxWnd release, replace dxwnd.dll, import "Dark Judgement.dxw" and update the Path, as usual ...
Uhm... would that be possible to get some screenshots (no photos, actual screen dumps!) from the Win98 virtual machine? That could help matching the color values and find a schema.
I see, that both questions were already answered
1)
Intro (.fli) does not have music in itself.
But when intro is started, music from the CD will be played (specifically \DJ_TRACK\TRACK_2.WAV).
The CD does not have any classic tracks.
3)
A doubt: did anyone actually see this part of the movie on Win95/98/ME? >
Yes.
Today, I tried this game on real Win98.
The monitor switches to 320x200 (I had to replace the LCD monitor for an old crt, the LCD reported that it did not supported that resolution), the logo appears, and then the intro. Intro is playing normally, but the image can not be captured via PrintScreen (black screen only).
(But, in virtual Win98, where it's all emulated it maybe is possible.)
Edit:
This is how it looks when playing intro (.fli) over player (potplayer + lav filters).
But I understand you need an original picture from Win98.
Since the palette seems to bypass the Windows layer and is sent directly to the video card, I guess it is impossible to capture a screenshot as a bitmap. So, I guess that a movie taken with your smartphone will be the best one can do, anyway better than nothing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wait, this is perfect! If the bmp files have colors identical to those showed on the Win98 screen (and this seems quite possible!) they are a perfect reference to identify the palette structure.
Maybe Jarkan can confirm this.
Tomorrow I'll make some attempts....
Yes, the colors look the same.
You can check here "https://www.youtube.com/watch?v=m7rqdRywte4&hd=1"
(probably sole video with intro)
I'll add yet uncompress rgb raw, but I do not know if it helps you.
Hello,
I have been trying to make Dark Judgement (win95/98) but I am unable to fix the black intro problem (and possibly the ending).
https://www.mobygames.com/game/dark-judgement
I will try to describe what I have found.
First of all: to avoid using the windows compatibility mode I checked the "handle exceptions" flag under Compat tab to be able to pass the intro screen, resulting in a black screen with the audio track in the background (same behaviour using the windows compatibility mode)
I have tried under windows 7 and 10.
Everything else seems to work perfectly during gameplay.
Things I tried: I checked every flag on the directx, video or tweaks tabs and this is what I found.
I am able to "watch" the intro if I change Emulation renderer to primary buffer only in windowed mode but the palette is all corrupted (if I make a screenshot the result is a black window ??¿? So I captured it with the phone...)
The other way is to activate de flag ddraw:LockColorDepth under the Tweaks tab. But the result is similar with different palette and the image is streched (although I can make a screenshot).
Can someone help me to make it work properly?
Regards and congratulations for this amazing software.
Last edit: Jarkan 2019-01-04
I repeated your experiments and found them very interesting. So far, I thought that in my RIP the movie was simply missing from the files on hard disk, but the test with primary buffer proves I was wrong. Unfortunately the logs show a quite weird way to blit the movie on screen, with QueryInterface operations with IID_Unknown interface and other things I still have to analyze.
The failure seems related to a DDERR_NODC error code on a ReleaseDC operation, also this error somehow puzzling me.
Well, I think that now I need more time and some luck to understand and fix the problem. Stay tuned ...
I read the logs for all ddraw blitter modes and in the end I think I got something: despite the complexity of the logs, the reason for the black intro is pretty simple: in emulation mode the game sets a black palette adter the company log, making the whole intro and outtro fully black.
To be certain of this fact, I added a debug flag to my WIP dxwnd release to force a random palette with non-black colors no matter what you set in the SetPalette wrapper. The result showed a game with scrambled colors, but with a meaningful intro movie (see screenshot).
So, this slightly shift the problem: I don't have to understand why the movies are not rendered to screen, but instead why the palette is cleared.
Something to investigate:
The game shows the company logo for about 5 seconds and during that period it defines a palette and changes its values with DDrawPalette::Setentries to make the appearing / disappearing transition effect. At the end of these 5 seconds the palette is fully black and the new video segment should appear. If you look at the following log you can see the last SetEntries definitions (all 00, that is all black) and soon after that I would expect to see a new palette definition, but you see an exception instead.
So, my guess is that for some reason (hopefully to be fixed) the new palette is not built and the blackened one remains active. Probably with "primary buffer" mode the logical palette defined for ddraw emulation is not considered, so you can see "something" that is at any rate something wrong.
To be continued ...
Last edit: gho 2019-01-05
I remember have seen a similar issue on Galapagos.
https://sourceforge.net/p/dxwnd/discussion/general/thread/e337f3b8/#6f5b
Thank you very much for looking into this issue. I am really glad that you are making some progress.
I hope to see it fixed soon! Thanks!
I extracted intro from DJ.DAT, but it probably will not help much....
Last edit: huh 2019-01-05
well, you can feed it to VLC Media Player that is able to play it and show 26 seconds of .... complete blackness. I fear that the movie expects something to set a proper palette during play.
BTW did you have some information about the DJ.DAT internal structure? That could be interesting for other types of hacks ...
Last edit: gho 2019-01-05
Vlc fails in this case.
But you can play it in mplayer, smplayer, mpc-be (here the player crashed if I switch to fullscreen). Also with lav filters (and flic format enable) I can play video in potplayer.
In Windows 95, you could install aflc codec (Autodesk.Animator.v1.11.Codec.exe), but according to some discussions it is no longer compatible with WinXP.
I have no information about the structure of DJ.DAT.
Intro and other two .fli, I extracted over one old tool.
Intro starts at offset 17DD55E and ends 221AFB1 (I think).
Fli have 320x200, 8 bits, 14.00fps
Potplayer says input type 32-bit RGB and output type YUY2 16bits.
Mplayer says - videocodec [fffli] vfm: ffmpeg (Autodesk FLI/FLIC Animation)
bicubic scaler from pal8 to yuv420p using MMXEXT, VO: [direct3d] 320x200 Planar YV12.
Last edit: huh 2019-01-05
Edit:
With lav filters I can also play video with mcitool
open "FLI00000.FLI" type mpegvideo
SUCCESS: "1"
play FLI00000.FLI
SUCCESS: ""
Sorry, the offset is wrong (it was a offset of another video).
Intro starts E174B7 and ends 17DD55D.
Edit:
Videos are in DJ.DAT in one block.
Offsets:
E174B7-17DD55D
17DD55E-221AFB1
221AFB2-222E110
But the problem is certainly with setting palette as you wrote.
If I set compatibility with Win98 in my virtual XP, video is black.
But after switch alt + tab or Win + D and back, the video is black and white.
Last edit: huh 2019-01-06
Some info from a debugging session.
The assembly responsible for the palette updates is here:
This routine seems to manage all palette transitions, both for the company logo, the black movie and what follows. You can see there some essential parts:
00401EDD JNZ SHORT 00401EA3
where it loops for 256 times to define each palette entry color and00401EFA CALL DWORD PTR DS:[ECX+18]
where it calls DirectDrawPalette::SetEntries.Palette colors are written to memory location starting from
0x4116A8
(at least, on my session) and during the black movie this code is not referenced ....In reality I'm not too sure: in two debugging sessions I got different results, one with (apparently) the palette updated with BLACK colors, the other with the palette not updates. I fear some synchronization trouble ...
Last edit: gho 2019-01-07
Thank you both to look into this! I am exicted! :)
A few additional notes:
1) the black part of the movie seems to lack also some sound. Forcing some output to screen (you can now use the v2.05.03 release with the debug "Random palette" flag) you can see some scenes where it makes sense to have some music plus some speech, while you can hear nothing. Is the audio missing together with the palette info? Are they both part of the same problem?
2) setting some fake I/O device (for instance, emulated HD drive Z: on "Z:\") and in Logs "System libs" + "debug" flags you can trace all I/O operations attempted by the program. Curiously, there seems to be no other file but DJ.DAT where the program reads multimedia data (other files are CONFIG.INI and HISCORES.DAT), so sounds and palette should be there...
3) A doubt: did anyone actually see this part of the movie on Win95/98/ME? I tried the game on a WinXP virtual machine where the assembly exceptions don't occur (they are caused by not allowed I/O instructions since Win7) but the result was the same: silence and blackness.
4) I'm trying the game with a RIP game version, since the full CD is reported as not installable. But I wonder if the full CD hides something that wasn't copied on the RIP. Later I'll try to compare files.
1) The soundtracks are stored in the CD as wav files. The intro sounds (track 2) if you mount the full version of the CD, not the rip. I attach the file structure of the full CD.
3) I tried a win98 virtual machine and It worked at is should, video and sound.
A possible track:
reading here https://www.compuphase.com/palette.htm you find that on Win95 the DirectX palettes in "exclusive mode" is inactive, so it could be bypassed by writing directly to the hardware palette through I/O assembly instructions.
Now, back to this assembly
This is the OllyDBG description of the REP OUTS instruction:
When first entering this instruction loop I found ECX = 0x100 = 256 ... quite a coincidence?
My guess is this: while the company logo part of the intro is managed with clean ddraw methods and the Windows palette manager, the second part (probably inherited from some DOS leftover) directly pushes the palette values to the hardware palette through this instruction.
If this is true, it could be possible (with some crazy effort) to identify this specific pattern and within the DxWnd exception handler to replace the assembly clearing (replacement with NOP instructions) with a copy from the address pointed by ESI to the DxWnd emulated palette.
The operation will also require some knowledge about the hardware palette format, since the dump from ESI doesn't follow the typical 4-bytes RGBX pattern of the PALETTEENTRY structure. Here is a sample:
@Jarkan: I read now your previous post. Thank you for the information, that will save some time.
Two essential things:
1) the sizes of DJ.DAT are identical, so the RIP should have the same info as the full version, that is good. If my previous post is right, maybe there's a possibility to make a fix.
2) the audio is on CD tracks, but the game doesn't link to WINMM calls for CD playing (like mciSendCommand or mciSendString). It doesn't even hold these call name strings (searched with a hex-editor) for a possible late-binding with GetProcAddress. This is a big problem, because it could mean that likely the game sends direct commands to the CD driver, something that DxWnd can't emulate.
Great! I can see something, though the colors are quite scrambled. I need to decode the hardware palette format, we're possibly close ...
Last edit: gho 2019-01-07
Just to give you an idea, this experimental release moves to the DxWnd logical palette whatever is pointed by the ESI register when the exception occurs. It's far from ok, but you can see the possibility to guess the proper palette disposition .... perhaps.
On last DxWnd release, replace dxwnd.dll, import "Dark Judgement.dxw" and update the Path, as usual ...
Uhm... would that be possible to get some screenshots (no photos, actual screen dumps!) from the Win98 virtual machine? That could help matching the color values and find a schema.
Last edit: gho 2019-01-07
I tried it and it "worked". This is going really well.
I will try to get a win98 screenshot later if I have the chance!
I see, that both questions were already answered
1)
Intro (.fli) does not have music in itself.
But when intro is started, music from the CD will be played (specifically \DJ_TRACK\TRACK_2.WAV).
The CD does not have any classic tracks.
3)
Yes.
Today, I tried this game on real Win98.
The monitor switches to 320x200 (I had to replace the LCD monitor for an old crt, the LCD reported that it did not supported that resolution), the logo appears, and then the intro. Intro is playing normally, but the image can not be captured via PrintScreen (black screen only).
(But, in virtual Win98, where it's all emulated it maybe is possible.)
Edit:
This is how it looks when playing intro (.fli) over player (potplayer + lav filters).
But I understand you need an original picture from Win98.
Last edit: huh 2019-01-07
Since the palette seems to bypass the Windows layer and is sent directly to the video card, I guess it is impossible to capture a screenshot as a bitmap. So, I guess that a movie taken with your smartphone will be the best one can do, anyway better than nothing.
Okay, I'll try something tomorrow. Meanwhile, I extracted intro.fli into bmp and tga.
Wait, this is perfect! If the bmp files have colors identical to those showed on the Win98 screen (and this seems quite possible!) they are a perfect reference to identify the palette structure.
Maybe Jarkan can confirm this.
Tomorrow I'll make some attempts....
Last edit: gho 2019-01-07
Yes, the colors look the same.
You can check here "https://www.youtube.com/watch?v=m7rqdRywte4&hd=1"
(probably sole video with intro)
I'll add yet uncompress rgb raw, but I do not know if it helps you.
Last edit: huh 2019-01-08