Me and our newest programmer (Defiance) have been investigating problems with games and other apps using XDK 3911. It looks like the problems we face with games using this XDK are much bigger than we originally thought. Below is a list of problems I've been able to dig up and how I have addressed or how I plan to address them.
1. The biggest thing so far is the lack of accurate deferred render state emulation. Ever had that EmuD3DDeferredRenderState not found error? Yeah, it has to do with that (sort of). Now that I have 3911 XDK samples to test with, troubleshooting issues with this particular XDK will be much easier. I was testing the basic tutorial examples as they are easy to debug with Cxbx, and noticed that the texture in the Texture tutorial was black! I had assumed that there was a problem with texture loading (there is, but not with this sample), but it turns out that the deferred render states were not being set properly. The example explicitly disables lighting (Direct3D enables it by default), but it wasn't doing it. I disabled lighting manually and it worked. For XDK 3911, instead of directly changing the deferred render states table directly, it calls a function to handle it (D3DDevice_SetRenderState_Deferred), and this function only exists in XDK 3911 and earlier so far. Because of this, Cxbx gets the location of D3D__RenderState (EmuD3DDeferredRenderState) then reads and updates deferred render states until the next draw call. To find it, what Cxbx does is calculate the location of the deferred render state pointer by locating IDirect3DDevice8_SetRenderState_CullMode and then calculating the offset from that function to the list of deferred render states. It appears to work fine for every XDK we support so far except 3911. Since I don't yet understand how Cxbx calculates the offsets, I'll have to use a more hacky method of correctly emulating the deferred render states. This means HLEing IDirect3DDevice8_SetRenderState_Deferred itself. Even though that the render states are supposed to be deferred, I'll set them on the fly and write code to defer them later. It's possible I might have to do the same for the deferred texture states as well (I hope not), but this will diagnose MANY problems you are having with any games released around November 2001 (yes, that means DOA3 and Oddworld). When the deferred render state location code is correct, I'll remove this function as emulating it will no longer be necessary.
2. There is yet another problem plaguing 3911 games. There appears to be a problem related to loading textures with a specific D3DX texture loading function. This is stopping many 3911 games from working (Star Wars: Obi-Wan, Fusion Frenzy, and many more). I haven't had a chance to debug this extensively, but the problem is known and will be addressed hopefully soon.
3. As much as I hate to say this, there's a chance you might be experiencing more "X-Ref only" errors with 3911 titles. Why? Because for DSound, I've added a new X-Ref that will help me quickly identify and fix missing DSound APIs, DirectSoundEnterCriticalSection. AFAIK, this is called in every Xbox DirectSound API. There are some missing DirectSound functions that can be executed by Cxbx and not crash leading to further problems. So when a DirectSound function call is missed, I can easily find out what it is thanks to the breakpoint that I placed before the message is displayed. Yes it will get annoying as heck, but it's for your benefit!
4. One more thing, I finally got around to adding the XGRAPHC library support for 3911. I'm surprised no one did it before o_O. I added every XG function that Cxbx emulates (except for one), so that will fix alot of problems right there.
I wanted to say more, but I can't remember what else I was going to say, lol. So I just wanted to let you all know what I've been up to lately. So stick around, and see what I have in store for you all.... hahahahahahahaha!
Why I’m Using Bitmarks on my Products
1 week ago