*Zaccheus* on 24/6/2009 at 21:53
As Bikerdude (
http://www.ttlg.com/forums/showthread.php?p=1876052#post1876052) suggested in the Thief 1 and 2 (SShock 1&2): Direct3D Texture Fix & Widescreen Patch thread I'm starting a new thread specifically for discussing the future possibilities of Timeslip's excellent idea which lead to DDFIX.DLL as we know it now.
I've created the thread here because I'd like to keep these discussions on TTLG if there are no major objections.
*Zaccheus* on 24/6/2009 at 22:06
My main two thoughts are summariesed in these two posts:
Quote Posted by *Zaccheus*
I've just managed to get the DDFIX.DLL source code to compile (and run!) using Visual C++ Express 2005, Platform SDK, and an old DX7 SDK which I had lying around. :D
There are two issues - giving Thief a fake DX6 interface to talk to and implementing a new way of rendering the graphics. I think those two should be possibly be split into two DLLs. Let me explain. If we had a DLL which looks like DX6's DDRAW.DLL to thief but which called some other DLL in order to do the actual rendering (which might use Open GL), then we could have different people working on different solutions without the need for them to understand how the old DX6 code works. I'm not sure how feasible that is, but even just finding a DX6 SDK can be a challenge these days so it would be good to decouple things at the interface level.
and
Quote Posted by *Zaccheus*
Something strange I noticed last night ... if you rename DDFIX.DLL so that Thief2.exe cannot find it, the LOAD/SAVE/QUIT screen runs in windowed mode at something like 640x480. Going into game mode works briefly with false colours before crashing. Thing is ... it should not be able to render anything at all without the DDFIX.DLL, what is going on?
I'm wondering if it is actively falling back to some other way of rendering (an abandoned attaempt at SW rendering) and/or creating DX objects directly via COM.
I'm 10% through reading [the whole Direct3D Texture Fix & Widescreen Patch] thread, sorry if that oddity has already been discussed.
bikerdude on 25/6/2009 at 00:56
On the end user testing side I have the following gfx hardware:
nVidia(GTX280)
ATi (HD3580)
Intel (GMA950, X3100)
Volca on 25/6/2009 at 05:54
I would kill for the possibility to use nvidia perfhud. It is quite simple to implement/get running but only works on DX9 and later, if I'm not mistaken. I tried to do this myself but couldn't manage to get the ddfix to compile (lack of DX sdk, quite probably).
Wille on 25/6/2009 at 10:59
I would really like to see improved performance for the latest (DX6?) version. Legacy computers that need ddfix stutter a lot in complex missions like Rocksbourg 3.
DX8, DX9 or even OpenGL renderer could provide us with cool things like shadows, reflections and proper bloom :cool:.
bikerdude on 25/6/2009 at 11:38
Quote Posted by Wille
with cool things like shadows, reflections and proper bloom :cool:.
I dont see how this would be possible if the dark engine itself dosent support it..
*Zaccheus* on 25/6/2009 at 12:21
If DX were doing the lighting, we might have been able to insert simple things like bumpmaps into the rendering, but looking at the code I notice that DX lighting is not used at all, which suggests to me that the DE does all its lighting 'by hand' and it is completely out of our control.
Volca on 25/6/2009 at 12:30
It uses mixed approach - WR geometry uses lightmaps that are cached in a set of textures, objects and AI are lit dynamically. Post-processing effects are the only thing with straightforward implementation chance, in my opinion (SSAO, bloom). Even the dynamic lights seem to have a real-time calculated, low resolution lightmaps for WR geometry, surprisingly.
It would take more than a DX wrapper to improve the rendering - namely it could be possible to hook in the code that does rendering of the WR geometry, but I fear this would be too fragile and complicated to do - and still most the limitations that are there would stay.
One other thing which could be useful is purely software renderer (TimeSlip planned one, if I remember well).
Timeslip on 25/6/2009 at 12:32
Quote Posted by *Zaccheus*
If DX were doing the lighting, we might have been able to insert simple things like bumpmaps into the rendering, but looking at the code I notice that DX lighting is not used at all, which suggests to me that the DE does all its lighting 'by hand' and it is completely out of our control.
It uses a second texture as a shadowmap. One thing that would improve things quite a lot would be increasing the resolution of that shadowmap, but when I tried thief ended up drawing to it incorrectly so all the shadows ended up in the wrong positions. :(
Volca on 25/6/2009 at 12:35
From what I discovered the pixel size of lightmap seems fixed at 16 pixels of the texture - software renderer was based on this fact.
