owl on 20/10/2007 at 07:29

---

No DDRAW.DLL in my thief2.exe, too. Version is 1.18, file length 250.438 Bytes.

TheNightTerror on 20/10/2007 at 08:15

---

*whisper* That's a link to a local hard drive directory. *whisper*

Timeslip on 20/10/2007 at 16:43

---

oops..

Fixed in 1.0.6.


Source code is included with the non-installer version, in the src folder.

ida pro wasn't involved, apart from looking at a few callback function to see which texture types thief was checking for. It's just a pile of fake DX interfaces, so they don't really care what thief is doing, just which DX functions it calls.

bikerdude on 20/10/2007 at 19:27

---

Fixed..

Btw does anyone think its worth getting the admin's to making this thread a sticky..?

NB. ive updated the 1st post to include the ongoing work by Timeslip.

biker

smithpd on 20/10/2007 at 20:51

---

I suggest that sticky status should wait until ddfix is debugged and stable. Then the title can be changed. It might be worthwhile actually to start a new sticky thread when all is stable and leave all this debugging discussion out of it. It is up there and active anyway.

@Timeslip,

Two new issues and one question.

I encountered an error in the GUI. Before install it said it needed .NET framework 2.0 or later but it couldn't find it. I already had .NET 2.0 SP2 installed at the time. I continued installing the GUI, and on launch it said "The application failed to initialize properly (0xc0000135)". I then ran a repair on the .NET 2 installation, and nothing changed. I then deinstalled .NET 2 and installed .NET 3 and it worked. Do you really require .NET 3? If yes, the error message is misleading. If no, then do you know why .NET 2 did not work for me?

I have found something strange with the frame rates that may shed light on the performance hit some people are describing. I guess my system is fast enough that I don't have a performance issue in game, but I noticed another problem described below.

First of all, before I installed ddfix, I used to let the application decide on vsync, and it worked just fine with Thief2.exe. Garrett ran at a normal speed with app controlled vsync. Now, with ddfix applied, application controlled vsync doesn't work. If I set both vwait=0 and LimitFPS=0, then Garrett runs very fast. I think this means that vsync is not working, which means that the application is not sending the control message to the driver. If, then, I go into the Nvidia control panel and force vsync to always on, then Garrett runs normally as he should. This seems all right in game, but then I notice a very stuttery response while in the Thief menu. The mouse-over effects are slow to react. Also, the resolution change on reading books is slow and jerky. So, something about forcing vsync on in the drivers is working badly in the ddfix version. I suspect that this issue may be affecting frame rate in-game for some.

To check out this stuttering menu problem, I set vsync back to app controlled in the driver and, to prevent Garrett running fast, I set LimitFPS=1 for the game. Now Garrett runs normally again, and strangely, the menus and resolution changes are again quick to react. I also notice another small issue. Garrett's running motion is not totally smooth in this LimitFPS mode. There are small speed variations -- not enough to complain about, but noticeable compared with the way the driver's vsync used to work. I speculate that you might be controlling FPS by some time-wasting procedure that is adversely affecting performance for some people. I wonder if it might be worthwhile to bring back the old default behavior, where application-controled vsync worked, as an option. This might resolve performance problems, but I really don't know. In any case, it seems that that menu stuttering needs more study.

Last and not least, do you have any word on the fog? I am waiting with bated breath.

Thanks again for your work on this! :)