More likely because it rotates as fast as the computer can render it, rather than using a proper timer.Originally Posted by Hiatus
That happens because Dark (and many other engines) blend the leftmost pixel of the texture with the rightmost pixel of the texture. If the next surface has a different texture on it, then the blending will still be with the other side of each texture, rather with the neighbouring texture.
Again, Dark Engine renderer fault / optimisation. It sometimes mistakely considers a very large object to be offscreen if only the very edge of it would be viisible. Also, objects start to vanish if there are more than a certain number of them onscreen at any one time (regardless of the number of polies in each object). This limit is ~128 objects.
@NV:
thanks for the explanation: I suspected at least some of these issues were graphics driver related (and I was cursing ATI/nVidia along the way), now I know it's not the case. Are all of these issues completely unfixable without DE full source code available?
[dream mode on]I wish DE games were ported to something like Unreal Engine 3 etc one day. Something like 10/15/20th Anniversary Edition on a modern/suitable engine[dream mode off]
Last edited by Hiatus; 13th Mar 2008 at 19:45.
Download new dll: http://timeslip.chorrol.com/temp/ddfixDebug.7z
Strange... UseCompatibleZBuffer=1 added to .ini, and in video properties in game no fog, and max resolutions 800x600x8.
My ddfix.ini:
[Main]
;Screen resolution
;Must be 800x600 or greater
gWidth=1024
gHeight=768
UseCompatibleZBuffer=1
;Set to 1 to fix the duel core related crash
DuelCoreFix=1
;Set to 1 to automatically register lgvid.ax each time thief is started up
VideoFix=0
My ddfix-log.txt:
v1.2.1, 1024x768
Duel core fix: 1
Video fix: 0
SetDisplayMode: 640x480x16
Next to the fog setting, does it say no and not let you change it, or is there no yes or no text at all?
Everytime I've had the problem where it would only let me choose an 8 bit resolution and the fog setting has vanished, it's been because I'd accidently corrupted one of the .cfg files. (Attempting to start the game with a different resolution set in cam.cfg to ddfix.ini can sometimes corrupt them, for example.) Try replacing them with copies of the originals, or if you don't have any, at least check cam.cfg to make sure all the settings are sane.
Yes. No Off or On. Only Fogging:
Ok. I'll check cam.cfg
Yes, was corrupted cam.cfg, It WORK!!! Cool! Thank you, Timeslip
Now 1280x1024!
Only now another problem: I do screenshot (Alt+F9) and dump.xxx pcx black:
Sorry, I read ddfix readme.txt:
This fix breaks thief's normal method of taking screenshots. You can take screenshots using ddfix by hitting printscreen.
I've removed the beta downloads. You can get 1.2.3 in standard or GUI flavours from the normal download link.
I've changed the z mask around a bit, so ATi users might be able to set UseCompatibleZBuffer back to 0 without causing crashes now. (It still defaults to 1, just in case.)
Thanks again for your service to the community, Timeslip.
By any chance have you looked into the SS2 Use mode HUD transparencies bug, introduced by the 1.2.x builds?
Thanks in advance.
Clearing, you can still use Fraps to take screenshots.Yes, was corrupted cam.cfg, It WORK!!! Cool! Thank you, Timeslip
Now 1280x1024!
Only now another problem: I do screenshot (Alt+F9) and dump.xxx pcx black:
I have the same number of copies of SS2 lying around as I do radeon graphics cards, if that answers your question.iirc, transparent menus have been a problem in SS2 with all versions of ddfix, not just 1.2.
Is the menu background supposed to be black? I'm using black as a transparent colour key for the thief 2 text overlay. If SS2 draws the menu by locking the frontbuffer, that's probably the problem. You'd just need to change the 'fx.dwFillColor=0;' line in FakeSurface::ClearOverlay and the 'fx.ddckSrcColorkey.xxx=0' lines in FakeSurface::Flip to some colour that's never used in the menus and recompile.
@Timeslip:
I just quickly tested 1.2.3 with UseCompatibleZBuffer=0 (previously non-working on ATI) and it works ok (sets desired 3D H/W mode and does not crash) BUT... setting this to 0 (on ATI at least) introduces visual artifacts in game - VERY distant objects in game (in huge outdoor levels - like towers etc) tend to disappear and re-appear when you move just a bit. With UseCompatibleZBuffer=1 (16-bit zbuffer) it's all ok (they don't disappear). So it looks like T2 has problems not with 16-bit zbuffer, but with 24-bit one!
the same problems with disappearing distant objects I've noticed in 1.1.1 when I put d3dx9_30.dll in T2 dir to be able to take screenshots - after that distant objects also tended to vanish (oddly, it was fine w/o this .dll).
If you want to test it yourself on nVidia, in User.cfg in T2 dir remove semicolon from ;starting_mission 3 line so it reads starting_mission 3, then start new game, load level (3rd level in game, Framed), in your starting point look ahead and see that very distant tower-like in front of you, above/behind all other objects. Now move slowly forward/backward/strafe and this tower should disappear/reappear briefly.
It works now me, too. But the fog problems in vista are the same: When I start the game, the game shows fog normal, but when I read a book or go into the menu, the fog is disappeared and I have to restart the game. I have no idea what the reason is, but it seems it has nothing to do with ddfix...
That tower flickers for me regardless of what I set UseCompatibleZBuffer to.
Since it's whole mesh subsets vansihing at once rather than individual pixels, I'd say that it sounded more like the dissapearing object bug that you mentioned before if it wasn't for the tower not dissapearing for you with a 16 bit zbuffer. It could be related to my fix for making sure that vertex z coords are less than 1. I'll try removing that and see if it stops the tower vanishing.
Edit: Yes it is. I'll get a 1.2.4 out later, but due to the limits of floating point accuracy I'm not sure if I can fix it properly without loosing the stars again.
that's odd - on ATI (my usual res 1024x768x16 at least, haven't tried others yet) I can't get this tower to flicker (with bother vanilla T2 and 1.2.3 with UseCompatibleZBuffer=1) no matter what I try; and with 1.2.3 + UseCompatibleZBuffer=0 it flickers heavily. If on nVidia it flickers even with 16-bit zbuffer, it looks like ATI has better/more precise 16-bit zbuffer, or sth like that :P.That tower flickers for me regardless of what I set UseCompatibleZBuffer to.
Does it flicker for you in vanilla T2, too?
re different behaviour on ATI/nVidia - maybe you'll be forced to make separate versions of the fix for each after all - or at least/better introduce (more) compatibility settings for each (ATI: 0, nVidia: 1 etc)...
Last edited by Hiatus; 14th Mar 2008 at 07:09.
Could you make that colour an .ini file option? I could handle recompiling the code, but I think that such things are a little beyond most people.
Also, a trivial issue, but since people keep quoting it in their logs: It should be "dual core" (two cores) not "duel core" (the cores engaging in an honourable fight?).
@Timeslip:
I see you nicely reduced/eliminated micro texture seams in 1.2.3 (such as those previously visible on some roofs in fog enabled missions like LotP near mission starting point etc) - they're now gone (but bigger seams are still there - only small one are gone). What have you done, and was it intentional or some nice side effect of other fix(es)?
===
I'd go further, and rename this option to MultiCoreFix to be more general and future proof when 4, 8, 16 etc core CPUs become mainstream, not merely dual core ones as todaylso, a trivial issue, but since people keep quoting it in their logs: It should be "dual core" (two cores) not "duel core" (the cores engaging in an honourable fight?)..
===
@MH.TheFreak (re disappearing fog after going to menu etc): you got nVidia or ATI? It's ok for me on ATI (fog doesn't vanish after going to menus and back) but I'm on XPSP2.
Last edited by Hiatus; 14th Mar 2008 at 06:18.
Morning
Ive updated the begining of this thread with the info from the upated readme that came with the latest version (1.2.3)
Timeslip, keep up the good work and thanks for the updated obmm, fixed a few of the niggles Id been having with Oblivion :-)
biker
MH.TheFreak, it's ok for me too (ATI). Fog doesn't vanish after going into the menu or read the book.
Yes, it appears to be black, going by these screenshots.I have the same number of copies of SS2 lying around as I do radeon graphics cards, if that answers your question.
Is the menu background supposed to be black? I'm using black as a transparent colour key for the thief 2 text overlay. If SS2 draws the menu by locking the frontbuffer, that's probably the problem. You'd just need to change the 'fx.dwFillColor=0;' line in FakeSurface::ClearOverlay and the 'fx.ddckSrcColorkey.xxx=0' lines in FakeSurface::Flip to some colour that's never used in the menus and recompile.
I've uploaded some screenshots of SS2's use mode screens (w/ DDfix v1.2.3) for you to sample.
Just wanna say thanks for this great fix. Had given up all hope on T2/SS2 looking noncrappy.
The see-thru inventory isnt that much of a biggie imho. The weapons-poke-into-walls bug was worse
1.2.4 is up. The tower is fixed for me, and I still have stars.
I did add options in the ini to change the colour key, but my 8800 doesn't seem to be able to cope with anything other than black. Anything else just breaks my picture. Hopefully people will have more luck with SS2.
just tested Framed and that tower very briefly - and same here with ATI - both 16-bit and 24-bit zbuffer (previously causing flicker) are fine now (no flickering) - and stars are there, of course.1.2.4 is up. The tower is fixed for me, and I still have stars.
great job!
===
Q1: can I have vanilla T2 exe and ddfixed one (and .dll+.ini) in game dir simultaneously (with vanilla/ddfixed exe renamed) and just launch them with different shortcuts OR should I move them out of game dir when I launch either of them. Is there any negative side effect of having them all in game dir all the time (only renamed)?
Q2 (out of curiosity): when in ddfix 1.2.x min required res is now 800x600 whereas in 1.1.x/1.0.x it was 640x480?
Last edited by Hiatus; 14th Mar 2008 at 10:14.
No problem with that at all.
So that I can tell whether thief is in game or on a menu screen. When thief calls SetDisplayMode with a 640x480 resolution, ddfix assumes it's displaying the menu, and if it uses any other resolution it assumes it's in game.
I could have done it by hooking a few functions in thief2.exe, but that would have meant that ddfix wouldn't work with thief 1 or SS2, and would have required a specific version of thief 2.
1.1 didn't need to distinguish between game mode and menu mode.
btw when testing today older 1.1.1 (DX9) version of ddfix I've noticed sth that I didn't notice before (1.2.x are fine in this regard): level Framed, near the starting point, sky textures: visible cylindrical-shaped BLACK texture seam (only 1 long one) is visible (across nearly whole screen horizontally) - I assume at some sky texture intesections. As I said, thankfully it's gone in 1.2.x but do you have any idea of the cause of it and was it a known issue for you? (Haven't tested skies in other levels re that, and besides - maybe it's ATI specific...)
ps do you have plan to restore screenshot taking functionality in 1.2.x (w/o using external tools like fraps etc) or is it out of question as it could break (too) many things/have other side effects etc?
Last edited by Hiatus; 14th Mar 2008 at 10:48.
That was a texture seam between two of the triangle strips that make up the sky. It effected all levels and all graphics cards. I did know about it, it was just one of those annoying little bugs caused by using DX9.
Does hitting printscreen not work for you, or do you just want .jpg shots back? Saving the screenshots was handled by d3dx9 in 1.1. There's no equivelent to d3dx in DirectX 6 though, so I had to write my own code to save a surface to a file. The bmp file structure was the simplest, and the only one I know well enough to write myself. Adding jpg support back wouldn't break anything, but I'd have to find some ready made jpg saving code that could handle the pitch being different from the width first.
Reply With Quote
