Thief 1/2 & SShock 2: DDFix and Enhanced Resolution Patch - discussion - by bikerdude
Hiatus on 4/4/2008 at 11:56
Quote Posted by Timeslip
I'm not having any luck with objects. Their creation is handled by a whole different section of code, so to override them I effectively need to start everything again from scratch. Probably going to take another few weeks.
that's unfortunate :(. Hope you'll be able to work out a less laborious/time consuming solution.
Timeslip on 4/4/2008 at 15:25
It seems I was being a bit pessimistic, or possibly very very lucky. Thief apparently doesn't use mipmaps on object textures, which means that I can just use my original code that I'd dropped to get world textures working. With a combination of the two, I can retexture (
http://img230.imageshack.us/img230/3999/screenshot1aa0.jpg) pretty much (
http://img296.imageshack.us/img296/430/screenshot2we4.jpg) everything. There will be stuttering when an object comes into view for the first time; whereas world textures are all loaded from disc at the start of a mission, object textures will only be loaded when used for the first time. Once loaded, they stay in memory until the mission ends.
With objects retextured as well, memory usage increased to just under a GB. With the 256x256 textures in those shots usage was only 100MB though. Sabatage took up 109MB.
1.3.8 is up, and includes the option to disable the windows key too.
ZylonBane on 4/4/2008 at 15:29
Quote Posted by Timeslip
Hopefully that's everything. :)
Thanks! So the *.override files only exist as a flag to ddfix that a texture has a high-res equivalent, correct? If so, wouldn't it be tidier and more convenient for ddfix to instead automatically scan its folder for textures with the same filename on every load request? Y'know, essentially assume that *every* texture will be overridden, and treat the original 8-bit textures as the fallbacks.
Also, when are we getting bump maps? ;)
Timeslip on 4/4/2008 at 15:45
Quote Posted by ZylonBane
Thanks! So the *.override files only exist as a flag to ddfix that a texture has a high-res equivalent, correct? If so, wouldn't it be tidier and more convenient for ddfix to instead automatically scan its folder for textures with the same filename on every load request? Y'know, essentially assume that *every* texture will be overridden, and treat the original 8-bit textures as the fallbacks.
They aren't just a flag, they also contain the file path to the replacement texture. It's a bit messy, but I can't interfere with the texture at file open time; I need to wait until thief creates its texture class and copies the data there. By then the texture just has a numeric id, which I can't turn back into path information, so I can't check for the existance of a file in a specific place. That's why I encode the file path into the texture data instead.
I intend to try and do it by checking for the hi-res texture at load time, and then overriding readfile to encode the path into the texture then, but I suspect it's going to cause problems with the runtime library thief uses. (It caches file reads. :()
Quote Posted by ZylonBane
Also, when are we getting bump maps? ;)
When I get the Thief 2 source code. :p
inselaffe on 4/4/2008 at 15:51
This opens up thief and ss2 improving no end :) great job.
One thing - why is the sky texture a bit blocky - does the sky have to be tga or something, and this is causing the problem?
Timeslip on 4/4/2008 at 16:03
Quote Posted by Dan Knott
This opens up thief and ss2 improving no end :) great job.
Still no SS2 support. That's going to have to wait for someone else. :p
Quote Posted by Dan Knott
One thing - why is the sky texture a bit blocky - does the sky have to be tga or something, and this is causing the problem?
You mean in shots I just posted of retextured objects? I'd deliberately modified the texture to only use the colours available in A4R4G4B4 format for some comparison shots a few pages back, and hadn't changed it back.
I've replaced the shots with some ones using the original texture, because I suppose there's not much point showcasing a 32 bit texture replacer using 16 bit textures...
ZylonBane on 4/4/2008 at 16:17
Quote Posted by Timeslip
They aren't just a flag, they also contain the file path to the replacement texture.
Ahhh, okay. I was thinking that you'd hooked directly into the filesystem routines. How about this then-- Would it be possible to, at game start, automatically generate (if one doesn't already exist) a manifest file that contains an MD5 checksum of every original texture for which a replacement exists in the TXT32 (or whatever) folder? Then when you get handed the raw texture data, you'd have a mechanism for determining exactly which file it is.
sNeaksieGarrett on 4/4/2008 at 16:43
Well, I guess I'm too late, but hiatus, I've got a zip version of ddfix 1.1.1 if you want it.:cheeky: (that way you don't have to have ddfix "install", cuz then it puts a installer registry entry and you have to uninstall it to get rid of it. I prefer the default ddfix way, non-installer.)
Damn, so much updates! =o I haven't read all this because it is too much technical and stuff... but from what I read, I get the jist of it, which is that this new ddfix beta allows better world textures?:o
Timeslip on 4/4/2008 at 18:03
I've been playing for a bit, and haven't come across any more major problems, (alpha'd textures that use mipmaps still can't be replaced, but there aren't many of them around,) so I'll replace 1.2.7 with 1.3.8 as the current version later today. (I'll leave Thief2Extensions=0 in the default ini, and leave 1.1.1 and 1.2.7 up for download too, just in case.)
Quote Posted by ZylonBane
Ahhh, okay. I was thinking that you'd hooked directly into the filesystem routines. How about this then-- Would it be possible to, at game start, automatically generate (if one doesn't already exist) a manifest file that contains an MD5 checksum of every original texture for which a replacement exists in the TXT32 (or whatever) folder? Then when you get handed the raw texture data, you'd have a mechanism for determining exactly which file it is.
Far too complicated for my tastes. :p
Then again, my ReadFile hook idea didn't work out either, (it works fine for pcx's, but breaks gifs,) so I have no better ideas.
Quote Posted by sNeaksieGarrett
Well, I guess I'm too late, but hiatus, I've got a zip version of ddfix 1.1.1 if you want it.:cheeky: (that way you don't have to have ddfix "install", cuz then it puts a installer registry entry and you have to uninstall it to get rid of it. I prefer the default ddfix way, non-installer.)
I already gave the zip version. It was the installer/GUI that I didn't have.
There isn't an installer anymore anyway. You wouldn't believe the confusion that the instructions 'extract the contents of the zip file to morrowinds installation directory' cause some people over on the morrowind forums, (just look for all the obse installation help threads. :eww:) so I generally make installers for everything. Luckly you all seem to be a bit more computer literate over here. :)
Quote Posted by sNeaksieGarrett
Damn, so much updates! =o I haven't read all this because it is too much technical and stuff... but from what I read, I get the jist of it, which is that this new ddfix beta allows better world textures?:o
Yup. Lets you replace any .pcx, .bmp or .gif texture with a 32 bit replacement with no size limits. (Edit: well, there's still the hardware limit of 4096x4096 for DX9 cards and 8192x8192 for DX10, of course. :p)
Speaking of which, is anyone actually intending to make a texture replacer or FM that uses this?
ZylonBane on 4/4/2008 at 18:24
Quote Posted by Timeslip
Speaking of which, is anyone actually intending to make a texture replacer or FM that uses this?
If you (or someone) can make an SS2 version of this, it will find immediate application in upgrading all the horribly low-res "tech" screens.
BTW, does this play well with animated textures? If memory serves, the Dark Engine has a 64K(?) limit on animated texture sequences.
