Wait, what?So I should probably undo the part of the code that prefers 32-bit buffers with mask 0xffffffff and just make it like it was before and only allow mask 0x00ffffff.
Actually there is at least one good reason to NOT use it... incidentally, this is also the very reason I'm not using it either (forcing antialiasing via Radeon Settings instead).The perfect solution to avoid these issues already exists and it's called dgVoodoo2. (...) Not using it given the circumstances is just plain stupidity and ignorance.
It would be essentially perfect, if not for the bloody antialiasing issue.The perfect solution (...) dgVoodoo2.
That was rude and uncalled for.Not using it given the circumstances is just plain stupidity and ignorance.
Hmm, what about some heuristic method of determining the integer vs float format at runtime?This is where AMD's driver handling of legacy Direct3D fails; even though only integer depth buffers are defined on the API level, accessing z-buffer will reveal float values. Do note that the mask is irrelevant for distinguishing between integer and floats.
The ideal fix would be to AMD to fix their drivers. I had another idea of guessing the format from whether the 8 most significant bits in the value of the buffer are cleared or not. Since I don't have the exact knowledge the engineers that designed these things do, I'd rather not make assumptions.
You said that accessing the Z-buffer directly is an uncommon thing to do; that implies there is some other way to access the Z-buffer that would normally be used instead.
Newer depth buffer formats are only defined starting with DirectX 9 or so. Intel and NVIDIA's drivers are still behaving according to the spec in that regard, just AMD's drivers are special. They have been historically problematic in general, doesn't seem much has changed.
Ahh, so I wasn't imagining things when the lens flares were unexpectedly not appearing (or disappearing) when viewed from certain angles, even when they should have been perfectly visibleI accidentally messed up the lens flare visibility code so it didn't work quite properly, flares might render when obscured by something else or vice-versa.
Huh. Well, that explains it then, since I can't remember having ever run any game which allows AA (in any way, shape or form) without also having anisotropic filtering enabled.I've tried dgVoodoo on the laptop with Radeon R2, with forced MSAA, text is still perfectly clear. The only thing that blurs the text is "Filtering" set to anything else but "App driven". When running without dgVoodoo, forcing anisotropic filtering through drivers doesn't have any effect on the image, on neither NVIDIA or AMD machine.
0043178E 7E 35 JLE SHORT Level_Ed.004317C5
00431790 55 PUSH EBP
00431791 33ED XOR EBP,EBP
00431793 8B46 14 MOV EAX,DWORD PTR DS:[ESI+14]
00431796 8B0CB8 MOV ECX,DWORD PTR DS:[EAX+EDI*4]
00431799 8B51 08 MOV EDX,DWORD PTR DS:[ECX+8]
0043179C F6C2 01 TEST DL,1 ; Check if layer is selected for editing
0043179F 74 15 JE SHORT Level_Ed.004317B6
004317A1 F6C2 02 TEST DL,2 ; Check if layer is hidden
004317A4 75 10 JNZ SHORT Level_Ed.004317B6
004317A6 FF7424 14 PUSH DWORD PTR SS:[ESP+14]
004317AA E8 C14B0000 CALL Level_Ed.00436370
004317AF 08C3 OR BL,AL
004317B1 C646 2C 01 MOV BYTE PTR DS:[ESI+2C],1
004317B5 45 INC EBP
004317B6 47 INC EDI
004317B7 3B7E 1C CMP EDI,DWORD PTR DS:[ESI+1C]
004317BA ^ 7C D7 JL SHORT Level_Ed.00431793
004317BC 85ED TEST EBP,EBP
004317BE - 0F84 57BD0C00 JE Level_Ed.004FD51B ; Jump to the new code if no layers have been processed here
004317C4 5D POP EBP
004317C5 8BCE MOV ECX,ESI
004317C7 E8 640D0000 CALL Level_Ed.00432530
004317CC 8BCE MOV ECX,ESI
004317CE E8 7D090000 CALL Level_Ed.00432150
004317D3 5F POP EDI
004317D4 8AC3 MOV AL,BL
004317D6 5E POP ESI
004317D7 5B POP EBX
004317D8 C2 0400 RETN 4
004FD51B 33FF XOR EDI,EDI ; This point can only be reached if NO layers were both selected AND visible at the same time
004FD51D 8B46 14 MOV EAX,DWORD PTR DS:[ESI+14] ; But it's also possible that ALL the layers were hidden
004FD520 8B0CB8 MOV ECX,DWORD PTR DS:[EAX+EDI*4] ; That's a pathological case, in which the importer has nothing to do anyway
004FD523 F641 08 02 TEST BYTE PTR DS:[ECX+8],2
004FD527 74 01 JE SHORT Level_Ed.004FD52A
004FD529 45 INC EBP ; EBP = always 0 at the start of this loop
004FD52A 47 INC EDI
004FD52B 3B7E 1C CMP EDI,DWORD PTR DS:[ESI+1C] ; Check ALL the layers!
004FD52E ^ 75 ED JNZ SHORT Level_Ed.004FD51D
004FD530 3BFD CMP EDI,EBP ; Won't be equal if at least 1 layer wasn't hidden
004FD532 75 05 JNZ SHORT Level_Ed.004FD539
004FD534 - E9 8B42F3FF JMP Level_Ed.004317C4 ; Bail out if all the layers were hidden
004FD539 68 44494D00 PUSH Level_Ed.004D4944 ; "DIM"
004FD53E 68 44454D00 PUSH Level_Ed.004D4544 ; "DEM"
004FD543 54 PUSH ESP
004FD544 FF15 54614A00 CALL DWORD PTR DS:[<&KERNEL32.LoadLibrar>; kernel32.LoadLibraryA
004FD54A 85C0 TEST EAX,EAX ; Did it work?
004FD54C 74 20 JE SHORT Level_Ed.004FD56E ; Bail out if it didn't
004FD54E 8BF8 MOV EDI,EAX
004FD550 58 POP EAX
004FD551 54 PUSH ESP
004FD552 57 PUSH EDI
004FD553 FF15 58614A00 CALL DWORD PTR DS:[<&KERNEL32.GetProcAdd>; kernel32.GetProcAddress
004FD559 85C0 TEST EAX,EAX ; Did it work?
004FD55B 74 12 JE SHORT Level_Ed.004FD56F ; Bail out if it didn't
004FD55D 59 POP ECX
004FD55E 56 PUSH ESI ; Pointer to the layer meta-metadata struct
004FD55F FF7424 18 PUSH DWORD PTR SS:[ESP+18] ; Handle to the calling window
004FD563 FFD0 CALL EAX ; Call the one and only export of the DEM importer DLL
004FD565 57 PUSH EDI
004FD566 FF15 5C614A00 CALL DWORD PTR DS:[<&KERNEL32.FreeLibrar>; kernel32.FreeLibrary
004FD56C EB 02 JMP SHORT Level_Ed.004FD570
004FD56E 59 POP ECX
004FD56F 59 POP ECX
004FD570 - E9 4F42F3FF JMP Level_Ed.004317C4 ; Return control back to the Editor
Users browsing this forum: Google [Bot] and 2 guests