Thief 1/2 & SShock 2: DDFix and Enhanced Resolution Patch - discussion - by bikerdude
frogdude on 20/10/2007 at 21:40
The installer works ok for me.:) I do have .NET framework 1.1, 2 & 3 installed + all service packs.
Slynt on 21/10/2007 at 01:39
Ok, 1.0.4 worked fine for me. but now when I try loading a game using 1.0.6 the game immediately crashes. This happens with both the GUI install and the manual hex editor install. I'm using an 8800GTX with 163.71 drivers in XP. AA/AF/Vsync are enabled through the Nvidia control panel, which worked fine for 1.0.4.
Timeslip on 21/10/2007 at 05:36
Quote Posted by smithpd
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 don't have .NET 3 installed, so it definately only needs 2. The installer checks HKLM\SOFTWARE\Microsoft\.NETFramework\policy\ to see which versions you have installed, and if the 2.0 entry was missing then no .NET programs would have worked properly anyway. A repair install should have fixed that though, so I have no idea.
Quote Posted by smithpd
Now, with ddfix applied, application controlled vsync doesn't work. If I set both vwait=0 and LimitFPS=0, then Garrett runs very fast.
vwait=vsync. If you use application controlled vsync then ddfix's vwait setting will control whether thief uses it or not.
The problem with menu's is that thief doesn't actually do any flipping, it just directly locks the frontbuffer. That isn't allowed in DX9, so I let it lock the backbuffer instead and then flip. Of course, that means it ends up being affected by vwait, and since the mouse curser and background are drawn in two seperate locks, they get treeted as seperate frames and so the background doesn't get updated while the mouse is moving. :(
The best thing I could do is disabling vwait at menu's, but that requires a device reset, and I wanted to keep things as simple as possible...
Quote Posted by smithpd
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 used sleep() to wait for the next frame. Saves CPU power, but only accurate to 16 ms or so. I'll switch to a loop instead.
Quote Posted by smithpd
Last and not least, do you have any word on the fog? I am waiting with bated breath.
Still not working. Still have no idea why.
Edit:
Quote:
I suggest that sticky status should wait until ddfix is debugged and stable.
Probably never going to happen. In my experience, trying to work around one graphics driver bug just causes another two to pop up. You just have to hope that they aren't as noticable as the original...
It's a shame nvidia/ati value their 3D mark scores over compatibility, but to be fair, if nvidia released something that rendered everything pixel perfect compared to microsofts reference device, but was as big, hot and expensive as an 8800 and only ran at 20-40% of the speed, (which is what would happen without shader recompilers, deliberately throwing away detail in the corners of the screen etc.) I can't imagine anyone buying it.
smithpd on 21/10/2007 at 06:41
Thanks for the explanation and the update. OK, so the software will never be completely debugged. No problem. I guess that is about true for all software. Basically, it is done when you declare victory. :)
Muzman on 21/10/2007 at 07:12
If it involves giving me a crash (refresher) course in how to use a hex editor, no one need bother, but I'd still like any ideas on why I can't see any reference to DDraw.dll in my Thief2.exe.
I was hoping to try hacking it into SS2, but I can't find it in Shock2.exe either. I just did a search for the hex characters for 'dll' or 'DLL'. Lots of other dlls, no ddraw.
Timeslip on 21/10/2007 at 07:33
Quote Posted by Muzman
If it involves giving me a crash (refresher) course in how to use a hex editor, no one need bother, but I'd still like any ideas on why I can't see any reference to DDraw.dll in my Thief2.exe.
I was hoping to try hacking it into SS2, but I can't find it in Shock2.exe either. I just did a search for the hex characters for 'dll' or 'DLL'. Lots of other dlls, no ddraw.
Could be some sort of copy protection that uses an encrypted exe. What happens if you use the installer version?
Edit:
Made a quick 1.0.7 version with the menu vwait problem fixed. I removed limitfps, because I only added it in the first place because vwait was broken.
There's also an unfinished DisableOverlay option which should (hopefully?) solve any fps problems. On the other hand, it will disable any in game text. It's unfinished because I intend for it to turn itself on/off when thief tries to render text, or if that isn't possible to add a toggle key.
vorob on 21/10/2007 at 08:47
Tested on my Laptop with 8600GT on 158.28, works fine! Thank you! :thumb:
bikerdude on 21/10/2007 at 10:15
Hey TimeSlip
Is the 1st thread ok btw..? would you like me to edit amend it?
biker
owl on 21/10/2007 at 10:46
Quote Posted by Timeslip
Could be some sort of copy protection that uses an encrypted exe. What happens if you use the installer version?
I have the same problem as Muzman. My Thief2 is the official boxed version for Germany. Thief2.exe size is 250.438 Bytes, Thief2.icd 2.662.445 Bytes.
Version says 1.18, but I already learned that there are actually different versions with this label. There is no reference to DDRAW.DLL in all files of my Thief2 program directory. Same applies to my boxed german version of System Shock 2. Also my Thief2 and System Shock 2 run under XP without having to set the compatibilty mode, and I have no other problems with NVidia 8800 GTS.
Your installer is also clueless, it says "Could not locate code section to overwrite. Your version of Thief2 seems to be incompatible with this patch".
The DLL reference has to be scrambled somewhere in the .exe or .icd file.
The fixed exe from Nameless Voice (big THANK YOU) is 2.662.400 Bytes long and guessing from file size is like my .exe and .icd combined, but with much more DLL sections.
By the way I find all the contributions in this forum just amazing. Thank you and respect.
Nameless Voice on 21/10/2007 at 11:15
Confirming that the patch also works with System Shock 2.
For those without hex-editor lore, the fixed Shock2.exe is here:
(http://senduit.com/754e03) DDFix-Shock2.exe(Again, link expires in one week)
I noticed a few issues.
First of all, I get visible 'tearing' while moving; I can actually see where the frame is being drawn. This isn't something I can take a screenshot of, since if seems to finish rendering the frame before it takes a screenshot.
Secondly, weapons are not properly rendered on top of everything else. Standing too close to a wall or object will make them disappear into that object:
(
http://img151.imageshack.us/img151/6180/screenshot4gi2.jpg)
Inline Image:
http://img151.imageshack.us/img151/6180/screenshot4gi2.th.jpg (
http://img151.imageshack.us/img151/6422/screenshot5zv9.jpg)
Inline Image:
http://img151.imageshack.us/img151/6422/screenshot5zv9.th.jpgAnother bug: sections of the inventory and user interface which should be black are transparent:
(
http://img151.imageshack.us/img151/7201/screenshot6bb9.jpg)
Inline Image:
http://img151.imageshack.us/img151/7201/screenshot6bb9.th.jpgBack to Thief 2, the
DisableOverlay=1 option does indeed give a major performance boost - the game is actually playable again. It also seems to solve the black borders around particle effects. But, of course, the text overlay is gone. No labels on keys, no onscreen text, and I can't even check status/FPS.
The DromEd problems still remain, though, which means that the supply of new FMs will probably dry up when the authors are stuck with DX10 cards...