Update on Drakan: I've just run it again and I must have taken a mistake. Draw distance seems to be normal after all.
UCyborg, could you check it out plz (these files are from your patch)?
http://dege.fw.hu/temp/Drakan_fastvidmem_dept … uffer_patch.zip
Thanks, will do! I was just writing the following wall of text. I'm a bit slow. Perhaps some questions will be answered by looking at your patches.
Got some results some from the laptop with Intel Core i3-3110M 2,4 GHz + Intel HD Graphics 4000. Drakan works quite nicely on it (absent lens flares, but more on that later) without dgVoodoo, the lowest recorded FPS number I got was 45 on level Islands while being bombarded by 4 other dragons. I've had resolution set at maximum available 1366x768 and draw distance to 200%.
Things were slower with dgVoodoo, first the frame-rate was quite low (choppy mouse) in menu when there was a background. In-game FPS was nicely at 60 until doubling draw distance from the original maximum of 100%. It was around 25 in that scene at the end of Wartok Canyons level (the one of which I uploaded a save on my thread on page 178).
We could say the codepaths handling Direct3D 10+ aren't as fast in that card's driver, at least for this scenario.
Now some dumb questions and thoughts:
The base problem with the cursor bitmap reading is that dgVoodoo doesn't notice that surface content changes. I inserted a little code snippet into the reader function that 'pokes' the mapped surface area, by writing one byte into it before ReadFile gets called.
Do I understand correctly that dgVoodoo doesn't notice only when ReadFile writes into the surface, but doing it manually (memcpy?) would work? OllyDbg catches many PAGE_GUARD_VIOLATION exceptions with enabled fast memory access, which, if I understood correctly, you use to detect changes. But nothing happens when you move the mouse. I think I'm missing something here, ReadFile gets called continuously when moving the mouse over one of the gems in the menu, but not when when it's moved anywhere else.
Dirty, but works for the cursor.
I recall 2 dirty hacks in my patching attempts as well. The game is quirky and I'm no software engineer.
The game can only work with either pure 16 bit or pure 24 bit depth buffers.
Is this the number the callback function checks at the offset 0x0C from the pointer in CPU register at two places?
By default it chooses the largest bit depth, so 24 bit in our case. When saying 24 bit, I mean real 24 bit, 3 bytes per pixel.
Is it just me, or is that function a bit flawed, assuming the answer to my previous question is positive? Both natively and with dgVoodoo, the first enumerated buffer depth is 16-bit, but the second is 24-bit with dgVoodoo and 32-bit natively. The engine cancels enumeration in both cases, but only in latter case lens flares disappear completely. I need to test this more; the game eventually crashes in Dragon.rfl (out-of-bounds pointer?) when it uses 32-bit buffer, but not with lower depths. Islands level, "iamgod" cheat and being bombarded with enemy dragons is a good way to get it to crash.
either limit Drakan to 16 bit depth buffers (doesn't sound good, I don't know what glitches it brings in)
Lens flares are perfect, but you get wallhack effect in the distance.
Then I tried the other way, what if I force the callback function to accept D24S8 depth format (all in all it's 32bit but the depth component is still 24). No more fps drop but lens flare disappeared in return
I guess this happens natively all the time. If I get it to use any format that isn't 32-bit, lens flares show up.
so I checked out the code reading back the depth values.
Indeed, it behaved badly, so I patched even this one. Lens flare were back but something went wrong with game draw distance...
So to conclude, the ideal solution would be to patch the function you mention somehow. Now I'm curious what the callback function for Z-buffer formats decides to use on Voodoo 2. I'll check it out in the emulator.
What a case of study for a game of 20 years ago 😁
I love these! Always good to get enlightened after wandering in the darkness.