Sunday, January 24, 2010

XDK 3911: Random stuff...

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!

Shogun.

10 comments:

  1. Great news! With more people working, it becomes easier and faster.

    ReplyDelete
  2. Yeah, defiance fixed a in the vertex shader code that causes problems in Vista.

    ReplyDelete
  3. wow more progress ...i´m crazy for to see ogl graphics...i don´t know why cxbx can support my motherboard chipset graphics controller but looks fine -.-.-.hehe-.-...is awesone to see that cxbx will can support more graphics, renders, more vertex types and effects,,greetings blueshogun...i love your cxbx videos..nice job for the emulation in all the world

    ReplyDelete
  4. I will see that emulator on x64? Uau :D.

    ReplyDelete
  5. Hi blueshogun96, thanks for excelent job in CXBX, i would like surprises in terms of games status compatible exemple in-game or playable for next released CXBX? Which would be?

    Sorry my english. =)

    ReplyDelete
  6. This comment has been removed by the author.

    ReplyDelete
  7. hmm..I was thinking of something the other day...it probably wouldn't work/would be too much work, but what if, instead of intercepting the calls the game makes, couldn't you scan the converted exe for the called methods and write a new exe with windows methods? then, the game could, potentially, run on its own and call the windows stuff without having to ask cxbx to do that...

    again, this was just off the top of my head..no idea if it would work.

    ReplyDelete
  8. That's what we're doing o_O. The .exe is not dependant on Cxbx at all. If you move the .dll into the same directory as the default.exe, it will run.

    ReplyDelete
  9. This article is very helpful.

    I just want to share a PDF filling out tool I've discovered, just in case you need it.

    PDFfiller.com allowed me to upload word and powerpoint document to be converted to PDF. Let's me fill out the form neatly and after I had the capability of either to save, print, fax , share or SendtoSign the forms.

    I was able to get also the form i need through http://goo.gl/mIu8lR.

    Such a great experience!

    ReplyDelete