Kilrathi saga owners: beta testers needed

Like promised, here's first version of ddhack that supports wc4:

http://iki.fi/sol/zip/ddhack07.zip

- Wing Commander 4 support
- 8 and 16bit videos work, ingame works, walking around works
- Known issue: the "briefing text" screen blinks until it asks you for keypress:
wc4brief.png


I haven't played much yet, but I'm fairly confident the game is now "playable". The blinking screen is downright mystifying, as it's a "normal" lock/unlock loop of primary surface.. so there shouldn't be anything weird. Still, it looks as if the game is pumping strange data my way. It's a slight annoyance but doesn't stop the game from being played.
 
This one sure is full of surprises.

Controls reset to keyboard when going on a planet mission and when returning from a planet mission. This I don't think I have anything to do about.

After jumping to the mesa system the rendering seems to freeze.

*sigh*
 
This one sure is full of surprises.

Controls reset to keyboard when going on a planet mission and when returning from a planet mission. This I don't think I have anything to do about.

After jumping to the mesa system the rendering seems to freeze.

*sigh*

The controls reverting was present in the game way back in the day, so that's nothing you had anything to do with.
 
If someone would be so kind as to test whether the latest version of ddhack works with the wc4 dvd version, I'd appreciate it. I'll run through the game in the cd version first before trying to upgrade it to the dvd one.
 
I have been testing every one of your ddhack dlls version onto WC4 DVD so far :D. This last one works pretty well, except when a movie needs to be played, the game freezes.
 
I have been testing every one of your ddhack dlls version onto WC4 DVD so far :D. This last one works pretty well, except when a movie needs to be played, the game freezes.

I can confirm the video problem. But if I use the setting in the picture below, you can hear the video but you still can't see anything.
 

Attachments

  • wc4dvdddhack.png
    wc4dvdddhack.png
    22.2 KB · Views: 161
I thought I had downloaded the hires moviepacks correctly, but this was unfortunately not the case. So I won't be debugging this tonight. Hopefully tomorrow.

I don't expect it to be a big hurdle - most of the things I've found have been relatively simple to fix.
 
Analysis so far.. the when wc4 is supposed to play a dvd clip, it basically shuts down, changes cooperative mode, and then hangs on DirectDrawEnumerateExA, which is not an entry point my wrapper supports as of yet.

So, this'll take some digging.

In any case, when I tried the game without my dll:s, it acted a bit weird.. when I reached the first decision point, the game seemed to be frozen, and I had to alt-tab out and back to get the choises on screen (this one seems to be documented in the cd->dvd patch readme). Then, when the first space flight started, the game just crashed.

Anyhoo.. we'll see if I can get this one going. Good side is, wc4w and wc4dvd seem to live peacefully side by side.

Oh, and -i option, at least, doesn't seem to work with wc4dvd.
 
Next it wanted directdraw7, which means this'll take some doing. Assuming it's possible at all.
 
A couple more missing entry points later I'm throwing in the towel for the dvd version; it's simply doing far too much I don't know about and don't care to figure out at this point.

For the curious, here's a snippet of my wrapper log. Format is:

[delta time from last line]("this" pointer) call/other info

Code:
We're inside the load game screen, game spams ddrraw.dll with
FlipToGDISurface calls..

[    +0ms] (03110e58) myIDDraw1::FlipToGDISurface
[    +0ms] (03110e58) myIDDraw1::FlipToGDISurface
[    +0ms] (03110e58) myIDDraw1::FlipToGDISurface

at this point I click "restart game", which starts with a video:

[  +780ms] (03110e58) myIDDraw1::SetCooperativeLevel(000f1fbe, 8) return 0
[    +0ms] (03110e8c) myIDDrawSurface1::Release
[    +0ms] (03110e8c) Object Release.
[    +0ms] (03110e8c) myIDDrawSurface1 Destructor

The old directdraw has been shut down completely at this point. The
following either comes from the game's video handling routines or
from the mci->directmedia hack; no idea which.

In any case the following is FAR more advanced than anything that 
wc4w does.

[  +718ms] (00000000) Exported function DirectDrawEnumerateExA
[    +0ms] (00000000) DirectDrawCreateEx(00000000,05C7E8F0,(guid),00000000)
[   +15ms] (03110f1c) myIDDraw7 Constructor
[    +0ms] (00000000) IDDRAW7 creation result: 0 ptr 05c7e8f0
[    +0ms] (03110f1c) myIDDraw7::GetCaps
[    +0ms] (03110f1c) myIDDraw7::GetDisplayMode
[    +0ms] (03110f1c) myIDDraw7::QueryInterface(?,05c7e8ec)
[   +47ms] (00000000) Exported function AcquireDDThreadLock
[    +0ms] (00000000) Exported function ReleaseDDThreadLock
[    +0ms] (00000000) Exported function AcquireDDThreadLock
[    +0ms] (00000000) Exported function AcquireDDThreadLock
[    +0ms] (00000000) Exported function ReleaseDDThreadLock
[    +0ms] (00000000) Exported function ReleaseDDThreadLock

There's lots more threads going on than with wc4w.

[    +0ms] (03110f1c) myIDDraw7::Compact
[    +0ms] (03110f1c) myIDDraw7::Release
[    +0ms] (03110f1c) Object Release.
[    +0ms] (03110f1c) myIDDraw7::Release
[    +0ms] (00000000) Exported function AcquireDDThreadLock
[    +0ms] (00000000) Exported function ReleaseDDThreadLock
[    +0ms] (03110f1c) Object Release.
[    +0ms] (03110f1c) myIDDraw7 Destructor

Directdraw7 gets shut down again, no idea why. Possibly something
failed and a fallback is tried.

[   +16ms] (00000000) Exported function DirectDrawEnumerateExW
[    +0ms] (00000000) Exported function DirectDrawEnumerateExA

Why call both wide and ansi versions of same function?

[    +0ms] (00000000) DirectDrawCreateEx(00000000,00736F58,(guid),00000000)
[    +0ms] (03110f1c) myIDDraw7 Constructor
[    +0ms] (00000000) IDDRAW7 creation result: 0 ptr 00736f58
[    +0ms] (03110f1c) myIDDraw7::SetCooperativeLevel(00000000, 4104) return 0
[    +0ms] (03110f1c) myIDDraw7::CreateSurface([124,0x1,0,0,0,0,512], 00000000, 00000000) return 0
[    +0ms] (03110f1c) myIDDraw7::GetCaps
[    +0ms] (03110f1c) myIDDraw7::CreateClipper

wc4w (or older games) never bothered with clippers.
Not that it matters. Here dd7 is created again, even though it
was just created and not cleaned up. Strange:

[    +0ms] (00000000) DirectDrawCreateEx(00736F6C,007377A0,(guid),00000000)
[    +0ms] (03110f50) myIDDraw7 Constructor
[    +0ms] (00000000) IDDRAW7 creation result: 0 ptr 007377a0
[    +0ms] (03110f50) myIDDraw7::SetCooperativeLevel(00000000, 4104) return 0
[    +0ms] (03110f50) myIDDraw7::CreateSurface([124,0x1,0,0,0,0,512], 00000000, 00000000) return 0
[    +0ms] (03110f50) myIDDraw7::GetCaps
[    +0ms] (03110f50) myIDDraw7::CreateClipper

And again:

[    +0ms] (00000000) DirectDrawCreateEx(007377B4,00737FE8,(guid),00000000)
[   +15ms] (03110f84) myIDDraw7 Constructor
[    +0ms] (00000000) IDDRAW7 creation result: 0 ptr 00737fe8
[    +0ms] (03110f84) myIDDraw7::SetCooperativeLevel(00000000, 4104) return 0
[   +16ms] (03110f84) myIDDraw7::CreateSurface([124,0x1,0,0,0,0,512], 00000000, 00000000) return 0
[    +0ms] (03110f84) myIDDraw7::GetCaps
[    +0ms] (03110f84) myIDDraw7::CreateClipper
[    +0ms] (03110f1c) myIDDraw7::GetCaps
[    +0ms] (03110f1c) myIDDraw7::GetDisplayMode
[    +0ms] (03110f1c) myIDDraw7::GetCaps
[    +0ms] (03110f1c) myIDDraw7::QueryInterface(?,05c7ee30)
[    +0ms] (00000000) Exported function AcquireDDThreadLock
[    +0ms] (00000000) Exported function ReleaseDDThreadLock
[    +0ms] (00000000) Exported function AcquireDDThreadLock
[    +0ms] (00000000) Exported function AcquireDDThreadLock
[    +0ms] (00000000) Exported function ReleaseDDThreadLock
[    +0ms] (00000000) Exported function ReleaseDDThreadLock
[    +0ms] (03110f1c) myIDDraw7::Compact
[    +0ms] (03110f1c) myIDDraw7::Release
[    +0ms] (03110f1c) Object Release.

At this point the application crashes.

That's a log from my directdraw wrapper, which is a sister project to ddhack. It simply takes the calls from the app, logs what it sees, and passes the calls to the real ddraw.dll. Unless I make some kind of mistake, the application should run just fine. In this case, we ended up with a crash, so something is wrong. The last time the mistake was my assumption that some function parameters might never be NULL, but they were.

The wrapper only logs the stuff I've implemented, so for instance in the above you can see the clipper and surface being created, but no further logging for them. Near the top there's some calls to directdrawsurface1, which is implemented; directdrawsurface7 isn't, so there's no logging for it. It still should work, since the application gets a direct pointer instead of a wrapper pointer.

So anyway, next I'd have to implement wrappers for at least the clippers and iddrawsurface7:s.. and I'm starting to feel a bit weary of this. In any case, the mci->directshow hack tells me the fact that there's some directshow in the soup, which is not something I'd like to touch at this point.

So, apologies. I'll run through the wc4w, clean up sources and release them; unless I get some kind of inspiration to keep investigating this, maybe someone else will pick it up.
 
If you have difficulty with the game without the patch then there may be other problems - you used gulikoza's dxmcia patch? even so, this is an impressive project you've worked up and really cool to see :)
 
Fascinating, truly. I wish I knew more about this particular area of Windows development - not necessarily to write for Windows, but to better understand these sorts of projects.

Also, I tend to avoid assuming something like parameters not being NULL never happens - if I do, I catch it with appropriate assertions. :)
 
If you have difficulty with the game without the patch then there may be other problems - you used gulikoza's dxmcia patch? even so, this is an impressive project you've worked up and really cool to see :)
I used the cd-to-dvd compilation patch/installer which also includes gulikoza's dxmcia patch - the one I referred to as mci->dx hack above.
Fascinating, truly. I wish I knew more about this particular area of Windows development - not necessarily to write for Windows, but to better understand these sorts of projects.
Neither do I, to be honest - it's been interesting journey finding out..
Also, I tend to avoid assuming something like parameters not being NULL never happens - if I do, I catch it with appropriate assertions. :)
When wrapping a couple hundred functions, some things tend to slip by. Especially if all you're after is a hack that lets you play one game, and not a serious undertaking. That said, silly mistakes nevertheless.
 
Back
Top