Pixel Shader support (more like re-inventing the wheel)...

Today, I sat back and thought to myself, "Hmmm, maybe I should start fixing some internal issues with Cxbx rather than updating the HLE database for a while." I thought back to myself how no matter how hard I tried, I never could get that stupid BumpEarth demo in the XDK to work right! The base texture always rendered fine, but the bump map and the environment map never did work. I decided to investigate. Initially, I assumed that it was a missing/wrong deferred texture state. After browsing the source code for a while, I realized all that stuff was fine. I even compared the code to the PC version. I noticed that the Xbox version of BumpEarth used a pixel shader, but the PC version didn't. Since I never really bothered with Xbox's pixel shader stuff (or even checked Cxbx's) I didn't initially assume that was a problem. I thought that this would be a good opportunity to check out how Xbox's pixel shaders worked. Turns out that Xbox pixel shaders are converted to a structure. Sounds weird to me, but I'm sure Microsoft had a good reason. After finding out that this was so, I checked Cxbx's implementation of IDirect3DDevice8_CreatePixelShader. Turns out that there was no [dynamic] pixel shader support at all! Whoever wrote it just used a fall back pixel shader and that was the end of it. That's better than nothing, but it's time change that (because if I don't do it, it might not get done)! Kingofc did it before, but we have no idea where he's been off to...

"Oh, I'm sure it can't be that bad... can it?" Well, so far, the Xbox's documentation on how it's pixel shaders work are a bit vague. The XDK also supports "Hard Coded" pixel shaders via the D3DPIXELSHADERDEF structure. Here's the definition of it (the X_ prefix was added for Cxbx to prevent collisions):

typedef struct _X_D3DPIXELSHADERDEF
{
DWORD PSAlphaInputs[8]; // Alpha inputs for each stage
DWORD PSFinalCombinerInputsABCD; // Final combiner inputs
DWORD PSFinalCombinerInputsEFG; // Final combiner inputs (continued)
DWORD PSConstant0[8]; // C0 for each stage
DWORD PSConstant1[8]; // C1 for each stage
DWORD PSAlphaOutputs[8]; // Alpha output for each stage
DWORD PSRGBInputs[8]; // RGB inputs for each stage
DWORD PSCompareMode; // Compare modes for clipplane texture mode
DWORD PSFinalCombinerConstant0; // C0 in final combiner
DWORD PSFinalCombinerConstant1; // C1 in final combiner
DWORD PSRGBOutputs[8]; // Stage 0 RGB outputs
DWORD PSCombinerCount; // Active combiner count (Stages 0-7)
DWORD PSTextureModes; // Texture addressing modes
DWORD PSDotMapping; // Input mapping for dot product modes
DWORD PSInputTexture; // Texture source for some texture modes
DWORD PSC0Mapping; // Mapping of c0 regs to D3D constants
DWORD PSC1Mapping; // Mapping of c1 regs to D3D constants
DWORD PSFinalCombinerConstants; // Final combiner constant mapping
}X_D3DPIXELSHADERDEF;

At first glance, the use of each field looks a bit obvious, but transforming this into a pixel shader isn't a trivial task (at least not for me). So far, it's just now starting to make sense (I had to look in the header file instead of the XDK docs). In the end, all pixel shaders on Xbox take the form of the structure you see above.

For those who have been following Xbox emulation history as long as I have, you might recall the day that _SF_ (author of Xeon) released the source code to his Xbox -> PC Direct3D pixel shader conversion code in an effort to prove that his emulator was not fake. I took a look to see how _SF_ did it in Xeon. Turns out that instead of using assembly, he used HLSL instead. It was a brilliant idea, but it's not going to work for Cxbx since it still uses DirectX 8.1 (another reason why I really want to start using OpenGL soon). Assembly shaders will still be possible, but just a bit more tedious.

What have I done so far? I've already written some prelimary code for pixel shader generation. For now, the best thing to do is to test it against pixel shaders written by myself and XDK demos to ensure accuracy. So far, I've written 3 pixel shader examples. Nothing fancy. I've also written some code to output the contents of the structure. They vary from shader to shader. Here's the results.

shader 1:
xps.1.0 // Xbox PixelShader

mov r0, v0 // Move the diffuse vertex colour to the
// output colour register (r0).
output:
PSAphaInputs[8] = 0xD4301010 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSFinalCombinerInputsABCD = 0x00000000
PSFinalCombinerInputsEFG = 0x00000000
PSConstant0[8] = 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSConstant1[8] = 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSAlphaOutputs[8] = 0x000000C0 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSRGBInputs[8] = 0xC4200000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSCompareMode = 0x00000000
PSFinalCombinerConstant0 = 0x00000000
PSFinalCombinerConstant1 = 0x00000000
PSRGBOutputs[8] = 0x000000C0 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSCombinerCount = 0x00011101
PSTextureModes = 0x00000000
PSDotMapping = 0x00000000
PSInputTexture = 0x00000000
PSC0Mapping = 0xFFFFFFFF
PSC1Mapping = 0xFFFFFFFF
PSFinalCombinerConstants = 0x000001FF

shader 2:
xps.1.0 // Xbox PixelShader

tex t0 // Declare texture register t0 (Texture Stage 0)
mul r0, v0, t0 // Multiply v0 and t0 the output register (r0)

output:
PSAphaInputs[8] = 0xD4D81010 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSFinalCombinerInputsABCD = 0x00000000
PSFinalCombinerInputsEFG = 0x00000000
PSConstant0[8] = 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSConstant1[8] = 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSAlphaOutputs[8] = 0x000000C0 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSRGBInputs[8] = 0xC4C80000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSCompareMode = 0x00000000
PSFinalCombinerConstant0 = 0x00000000
PSFinalCombinerConstant1 = 0x00000000
PSRGBOutputs[8] = 0x000000C0 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSCombinerCount = 0x00011101
PSTextureModes = 0x00000001
PSDotMapping = 0x00000000
PSInputTexture = 0x00000000
PSC0Mapping = 0xFFFFFFFF
PSC1Mapping = 0xFFFFFFFF
PSFinalCombinerConstants = 0x000001FF

shader 3:
xps.1.0 // Xbox PixelShader

tex t0 // Declare texture register t0 (Texture Stage 0)
tex t1 // Declare texture register t0 (Texture Stage 1)
mov r1, t1 // Move texture register t1 into output register r1
lrp r0, v0, t0, r1 // Lerp between t0 and r1 by proportion
// specified in v0
output:
PSAphaInputs[8] = 0xD9301010 0x14D8DD34 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSFinalCombinerInputsABCD = 0x00000000
PSFinalCombinerInputsEFG = 0x00000000
PSConstant0[8] = 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSConstant1[8] = 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSAlphaOutputs[8] = 0x000000D0 0x00000C00 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSRGBInputs[8] = 0xC9200000 0x04C8CD24 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSCompareMode = 0x00000000
PSFinalCombinerConstant0 = 0x00000000
PSFinalCombinerConstant1 = 0x00000000
PSRGBOutputs[8] = 0x000000D0 0x00000C00 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
PSCombinerCount = 0x00011102
PSTextureModes = 0x00000021
PSDotMapping = 0x00000000
PSInputTexture = 0x00000000
PSC0Mapping = 0xFFFFFFFF
PSC1Mapping = 0xFFFFFFFF
PSFinalCombinerConstants = 0x000001FF

So obviously enough, the contents of the structure will vary on the contents of your shader. Quite frankly, it reminds me of .fx files. They are very convienent to use, but once again, not available in D3D8.

Now that I think about it, there is one more option for this... Cg! IMO Cg is awesome shader language (I don't understand why so many hate it) and it supports Direct3D 8.1 too! It's not very different from HLSL either. Although it should work fine on ATI cards, it will make Cxbx much more NVIDIA oriented than it already is.

So, that's what I've been working on lately. I really hope that I can get this pixel shader stuff working sometime. Turok is looking a bit "lifeless" without it's lighting shaders emulated properly. Lack of pixel shaders also limit Cxbx's bumpmapping support too. I'll be sure to keep you all posted on what's going on with this latest endeavour.

Shogun.

EDIT: Sorry, blogger is not very code friendly.

I'm back, but I need a favour (for those who can contribute).

Yup, I'm back to work on Cxbx these days. I'm still rather busy, but I can still make updates from time to time. Since the internet is down at my place, I might not be able to update this blog as much as I want to (I'm at the library). Rest assured, I still have lots of things planned.

The day after Christmas I started working on Cxbx again for a bit. Nothing major, but I did get a few noises out of Azurik's Xbox Demo xbe. It's probably not working due to lack of launch parameters (which means Azurik needs to attempt to execute it first). What's the status of this game? It's still not doing anything yet (one of my old betas got it in the Nothing status). So far, Azurik appears to be the H-A-R-D-E-S-T Xbox game to emulate, and if it ever works, I'll die a happy emu author. What it did do is further remind me how lacking XDK 3911 support is. Signatures for XDK 3911 have been rarely added from anyone lately. I've managed to add a few, but the changes from 3911 to the closest XDK I have (4361) are just to great. IMO, XDK 3911 wasn't very organized when it released it, but eventually got a better flow of organized code structure. Adding DirectSound stuff for this XDK has always been a pain to do by hand (especially if you don't have that XDK).

So anyway, I have a few favours I want to ask you all.

1. Does anyone have XDK 3911? It was abundant at one point, but now it's impossible to find. Even the lib files will do okay. I never could get it back then because I didn't have access to broadband (56k only). If you ever want to have hopes of playing DOA3, please ask/look around :)

2. Can anyone generate FLIRT signatures for IDA? I had a copy of the FLIRT SDK, but I don't know what happened to it. This will make working on Cxbx much easier so I can identify missing functions right away.

I really hate to ask favours of people, but at these times, I really need them! Thanks.

Shogun.

Good news and bad news...

Yes, it's that time again. The dreaded "good news and bad news" post... here's what's going on:

Bad: After starting my new job (judging by the hours I'll be working on a frequent basis), I won't have any time to work on Cxbx probably except on Sundays (and maybe not even then) until after Christmas time. So just because you won't see as many frequent updates this month doesn't mean I've stopped working on Cxbx. If I stop, I'll tell you first.

Good: Thanks to an anonymous source, I've got some new XDKs! 5659 and 5788 to be exact. I haven't found many that uses either one, but they'll come in handy later, I'm sure. Also, I'm sure I'll be able to talk Caustik in making a release before Christmas too. You've all been waiting 5 years for a new release, and it's about that time. Just remember, it will be a *BETA*, meaning it's probably going to have random bugs in it. Also, not every game on the compat list is guaranteed to work for everyone due to region differences, okay? For instance, one version of DOAV might give you the dirty disc error, and another version will not so now you know.

Unfortunately, it's about time for me to go back to work. *Sigh*, I just got off of work!

Shogun.

More on Unreal Championship

If you've read my last update on Unreal Championship, you'll have a good understanding by now what the situation is. If not, you might want to read that first :)

So, now what's going on? So far, this is the most interesting situation I've come across when working on this emulator. The solution to it might be even more interesting (or annoying). I'm not really sure which would be the best way to go from here, but I do have two ideas for this scenario (to handle the problem with the xbe trying to re-launch itself). When XLaunchNewImage is called (and when the .xbe being called is itself) and the LaunchData parameter is saved, we can either:

1. Trigger some sort of "restart" process inside the CxbxKrnl so everything except the necessary things are in the initial state at which the game was started. Then jump right back to the game's main entry point and continue as normal. Optionally "Persist" the display until D3DDevice::Present is called.

2. Save the contents of pLaunchData to a file in the same directory of the game (it's size will always be 3KB). Then load the file and restore certain states the next time Cxbx is running the same game. This will require you to restart Cxbx each time you want to go in-game.

Remember, I said I'm looking for the "best" way to handle this, not the most "ideal". I know everyone would rather have me do number 1, but so far I've only had time to try number 2. This is what happened...

Rats! To a certain extent, #2 does work, but it does have one small problem. The controller needs to be re-initialized so that the game will recognize that it's still there. This will require a bit of hacking. So far, it appears that everything else worked fine. All the files required to load the map, etc. were loaded without problems. But so far, it looks like #1 is harder to implement and #2 requires more extensive hacking. Maybe a simple jump could fix everything (for #1)! Since I'll be busy tonight and all day tomorrow, there's no telling when I can actually try it. Hopefully Caustik can jump back in sometime and give a few suggestions, but unfortunately, it appears that I'm the only one on the Cxbx team that has this game.

I'd really like to get more in-depth on this, but atm I have much work to do IRL so just stay tuned and I'll see what I can do. There's a lot that can be done with this game (once it works), but you'll just have to see if/when that happens :)

Shogun.

Unreal Championship progress...

Yeah, it's been a while since I've worked extensively on this game, but yesterday I had lots of time on my hands so I went at it. Before I go any further, I'd like to thank Chrono Archangel find a certain XNet function (XNetGetEthernetLinkStatus). Without his l337 google skills, I might not be posting this right now!

Unreal Championship goes comfortably to the menus (and is more interactive) with little or no problems. So far this is only for the NTSC version. It required a small handful of hacks, but so far it looking good. Since the game uses time based updates, you don't have to worry about it going to fast when VSync isn't enabled :) I also learned a few new tricks when emulating this game! Even though UT2003 for PC is practically the identical in many ways, IMO this game is too different so I say it's safe to consider this game an Xbox exclusive (that's one reason why I own both).

If you look at the screens, you'll notice that it looks as if termites have been eating some of the textures. "What is it?" Not 100% sure, but my guess is either it's another swizzling issue, or it's a palettised 8-bit texture and the conversion from D3DFMT_P8 -> D3DFMT_A8R8G8B8 isn't perfected yet. One thing I noticed was that so far, XACT wasn't really used much after loading one wave bank (which was surprising), so I might not have to implement the whole XACT API after all (which would be a major sigh of relief).

Now for the list of hacks needed. The first one I should have mentioned before. Sorry to those who tried running this game on my branch before with no success.

1. At one point, I was trying to add a missing DirectSound API and I couldn't generate a digital signature for it. So what I did was I made a copy of my xbe and filled that function call with NOPs using a hex editor.
2. Disabled overlay updates so that the second video can play. The first video works without the hack, but when the second one plays without the hack, it will cause a crash inside of the DirectDraw DLL. I couldn't think of a better solution at the time so I did this.
3. For some reason, Unreal likes to lock it's textures at each level until it fails. So I had to tell EmuIDirect3DTexture8_LockRect to fail when the texture level is higher than 5.
4. This last hack probably won't work for everyone, but I added a hack in EmuIDirect3DDevice8_SetIndicies to stop it from crashing because the IndexBuffer pointer appears to be bogus. If you get a CreateIndexBuffer failed error when trying to go passed the first menu screen, try it again.

These were some dirty and totally ugly hacks used (and I had a feeling that this was going to happen anyway). Oh well, as long as it works, right?

"So, what's stopping it from getting us in game?" Okay, here's where it get's complicated. It's bad enough that Unreal Championship uses features that are rarely used in Xbox games (or should I say features that we're not used to emulating for Cxbx?) which makes things a bit more complicated, but it's biggest feature is getting to us. Unreal Championship was the first console game in history that supported [executable] patches for the game. This means that in order to run that patch, it has to execute a new .xbe file. Cxbx is currently not capable of doing that. But what if it's not there? What it appears to be doing is loading the default.xbe over again if it isn't. It may have been designed like this as a cheap way of clearing most data from memory. So, that's the problem... but what about a solution? Here's an idea. I added the function XLaunchNewImage today to see what it was trying to do. Just as I stated above, it's just re-executing itself. Wouldn't that just start everything over? No, not really. Fortunately, the XDKs documentation on XLaunchNewImage is quite adequate, well written and very informative. Since an Xbox .xbe's entry point (void __cdecl main()) does not take any parameters (i.e. no command line), they have to be set using XLaunchNewImage. The function XGetLaunchInfo is used to retrieve the the data set by XLaunchNewImage. Since Unreal appears to be going back to the entry point after attempting to reload default.xbe, there's a chance that we can fool it by saving the params from the last call from XLaunchNewImage so that they can be retrieved by XGetLaunchInfo. This might work, and it might not. It's worth a try, and so far, I don't see any other options as of now. I'll give it a try, but just know this. I can't guarantee that I can get this one in-game. I can only guarantee my best efforts!

One more thing, I'm looking for anything on the .xbx file format. What is an .xbx file? It's a customized texture format for the Xbox. Since Unreal Championship calls XGWriteSurfaceOrTextureToXPR to create it's icons, it would be ideal to be able to create this functionality just in case the icon is actually used. So if you can find any tools, have any source code that deals with this file format, let me know!

Before I conclude this update, I just want to thank all the Cxbx supporters and fans that have been keeping up with us for all this time. Chrono Archangel, Mr. Fabulous, saintseiya, nokiaman, and more, I really appreciate you all!

Shogun.

Martin_sw continues his work for Chihiro support.

It's been a while since I've talked to Martin_sw, but today we were having a conversation and so far, it looks like he hasn't given up. Here's what he had to say:

"ok, seems sega just highjacked it for chihiro then so far i have added these to cxbx:

JvsScFirmwareDownload@16
JvsScFirmwareUpload@16
JvsScSendRs323c@12
JvsScReceiveRs323c@12
JvsScSendMidi@12
JvsScReceiveMidi@12
JvsEEPROM_Read@16
JvsEEPROM_Write@16
JvsBACKUP_Read@16
JvsBACKUP_Write@16
JvsNodeReceivePacket@12
JvsNodeSendPacket@12
JvsFirmwareUpload@16
JvsFirmwareDownload@16
JvsRTC_Read@16"

This is interesting because even though it's obvious that Chihiro would have customized functions, but it's amazing how fast Martin discovered these. It looks like we might be seeing Chihiro sooner than we thought!

Another thing, remember that game I was going to surprise you all with? You all guessed right, it was JSRF. I hate to say it, but it might not be playable before Christmas at this rate (darn)! I ran into some extremely annoying problem and I have no idea how to fix it (for both PAL and NTSC versions). *Sigh*, oh well, I'm sure I'll figure something out, but as long as you know I'm working on it so you don't have to beg me for JSRF support anymore. Either way, I can still make up for this with something else in the meantime *muwahahahahahaha!*

Shogun.

The lastest on Shogun's branch (11/24/09).

Well, Thanksgiving is right around the corner! Hmm, I wonder what's for dinner? lol. Anyway, what's this update about? Good question. As of yesterday, I've been hauling alot of code around (mostly digital signatures from the D3D8 and XAPILIB libraries). I noticed that XDK 4134 is really lacking in digital signatures. There were some good games using that XDK, so I decided to do some work on it (which also leads up to some new stuff for other XDKs). The first thing I did was tell Cxbx to treat whatever library I was testing as a different version:

if(BuildVersion == 4134)
BuildVersion = 3925;

So after I checked my 4134 games against each XDK from 3911 to 4627, I've managed to come up with almost 100 signatures (and there's lots more to add for DSOUND). Here's a list taken from my changelog:

- Added the following function(s)
RtlCreateHeap (4134)
RtlAllocateHeap (4134)
RtlFreeHeap (4134)
RtlReAllocateHeap (4134)
RtlSizeHeap (4134)
XapiBootDash (4134)
XRegisterThreadNotifyRoutine (4134)
XGetDeviceChanges (4134)
XID_fCloseDevice (XREF) (4134)
XInputClose (4134)
XInputGetCapabilities (4134)
SetThreadPriorityBoost (4134)
GetThreadPriority (4134)
XGetDevices (4134)
QueryPerformanceCounter (4134)
QueryPerformanceFrequency (4134)
XInputPoll (4134 - 4928)
XGetSectionHandleA (4134 - 4928)
XLoadSectionByHandle (4134 - 4928)
XFreeSectionByHandle (4134 - 4928)
RtlDestroyHeap (4134 - 4928)
D3DDevice_CreatePixelShader (4134)
IDirect3DSurface8_LockRect (4134)
Lock2DSurface (4134)
D3DDevice_SetGammaRamp (4134)
IDirect3D8_CheckDeviceFormat (4134)
IDirect3D8_GetAdapterModeCount (4134)
IDirect3D8_EnumAdapterModes (4134)
IDirect3DDevice8_LoadVertexShader (4134)
IDirect3DDevice8_SelectVertexShader (4134)
IDirect3DDevice8_CopyRects (4134)
IDirect3DDevice8_CreateImageSurface (4134)
IDirect3DDevice8_SetVertexShaderConstant (4134)
IDirect3DDevice8_SetPixelShader (4134)
IDirect3DDevice8_SetTextureState_BumpEnv (4134)
IDirect3DDevice8_SetIndices (4134)
IDirect3DDevice8_SetTexture (4134)
IDirect3DDevice8_SetRenderState_VertexBlend (4134)
IDirect3DDevice8_SetRenderState_TextureFactor (4134)
IDirect3DDevice8_SetRenderState_EdgeAntiAlias (4134)
IDirect3DDevice8_SetRenderState_Simple (4134)
IDirect3DDevice8_SetRenderState_ZEnable (4134)
IDirect3DDevice8_SetRenderState_StencilEnable (4134)
IDirect3DDevice8_SetRenderState_MultiSampleAntiAlias (4134)
IDirect3DDevice8_GetTransform (4134)
IDirect3DDevice8_SetStreamSource (4134)
IDirect3DDevice8_SetVertexShader (4134)
IDirect3DDevice8_DrawVertices (4134)
IDirect3DDevice8_DrawVerticesUP (4134)
IDirect3DDevice8_DrawIndexedVertices (4134)
IDirect3DDevice8_SetLight (4134)
IDirect3DDevice8_SetMaterial (4134)
IDirect3DDevice8_LightEnable (4134)
IDirect3DVertexBuffer8_Lock (4134)
Get2DSurfaceDesc (4134)
IDirect3DSurface8_GetDesc (4134)
IDirect3DDevice8_SetRenderState_StencilFail (4134)
IDirect3DDevice8_SetRenderState_NormalizeNormals (4134)
IDirect3DDevice8_Reset (4134 - 4361)
IDirect3D8_KickOffAndWaitForIdle (4134 - 4361)
IDirect3DDevice8_SetTextureState_TwoSidedLighting (4134 - 4361)
IDirect3DDevice8_SetRenderState_BackFillMode (4134 - 4361)
IDirect3DDevice8_SetTextureState_ColorKeyColor (4134 - 4361)
IDirect3DDevice8_SetRenderState_FrontFace (4134 - 4361)
IDirect3DDevice8_SetRenderState_LogicOp (4134 - 4361)
IDirect3DDevice8_SetRenderState_StencilFail (4134 - 4361)
IDirect3DDevice8_SetRenderState_OcclusionCullEnable (4134 - 4361)
IDirect3DDevice8_SetRenderState_StencilCullEnable (4134 - 4361)

- Move the following functions
XInputPoll (4928 -> 4134)
XGetSectionHandleA (4627 -> 4134)
XLoadSectionByHandle (4627 -> 4134)
XFreeSectionByHandle (4627 -> 4134)
RtlDestroyHeap (4627 -> 4134)
IDirect3DDevice8_Reset (4134)
IDirect3D8_KickOffAndWaitForIdle (4432 -> 4134)
IDirect3DDevice8_SetTextureState_TwoSidedLighting (4432 -> 4134)
IDirect3DDevice8_SetRenderState_BackFillMode (4432 -> 4134)
IDirect3DDevice8_SetTextureState_ColorKeyColor (4432 -> 4134)
IDirect3DDevice8_SetRenderState_FrontFace (4432 -> 4134)
IDirect3DDevice8_SetRenderState_LogicOp (4432 -> 4134)
IDirect3DDevice8_SetRenderState_StencilFail (4432 -> 4134)
IDirect3DDevice8_SetRenderState_OcclusionCullEnable (4432 -> 4134)
IDirect3DDevice8_SetRenderState_StencilCullEnable (4432 -> 4134)

That's quite a bit of stuff missed. TBH, I'm not done yet. I've also been able to find out why 4034, 4039 and 4134 are getting false positives. Whoever started trying to add 4034 and 4134 support just threw in a bunch of signatures from D3D8 3925 must have been looking for similarities in that XDK. Good idea when you don't have a certain XDK, but it's not 100% safe to do (or leave in unattended). There may be more, but I do need to check for some more doubles when I get a chance.

"Hold on a sec, there's got to be a reason why you're doing all this! What is it?" Well, that's going to be a surprise for now. TBH, I really don't want to spoil it but I if you have an Xbox game that was released in February 2002, I'm sure you have a good idea what it is. I want to see it work just as bad as you do, so you all can stop complaining about it! :) I get requests for this game all the time, so I just want to keep you guys "smiling" a "bit" (another hint)!

Oh yeah, don't worry, I've got a nice Christmas present up my sleeve for you all! Stay tuned.

Shogun.

Latest Progress: Petit Copter (and continuing Kingofc's work).

So far, my theory was right! The game known as Petit Copter (XDK 4361) so far seems to be pretty easy to emulate. It's already showing 3D graphics (not in-game yet) and runs at reasonable speeds. Nothing too complex so far, there's just one annoying thing I'm having a bit of trouble fixing, but I'll get it eventually.

Hey, want to know what makes it even easier to work on?? The code was almost completely based off of the Technical Certification Game in the XDK! Almost everything is the same. So that means fixing the TechCertGame will make this game playable! While I respect the work of any game developer/programmer, this game was very cheap, lol. The only thing that's stopping me right now is the dreaded IDirectSoundStream_FlushEx function. It's a bit tricky, and also different from the XDK specifications when viewing the disassembled version in IDA. So far, this function appears to be stopping the TechCertGame from working. So far, I'll assume it's the same with Petit Copter. Either way, if Kingofc could get this TechCertGame working, so can I! It would be nice if he was still around as have learned a great deal from him and would love to continue to do so. This was his old dev page (ahh, the good old days of Cxbx)!

So stay tuned. It shouldn't be too much work getting this game playable. TBH, I thought Smashing Drive was super easy to work with. So far, this one is easier than that, and it only took less than a day's worth of work to get this far! Boy, that was easy...

Btw, check out the youtube video Here!

Shogun

Got my hands on a fairly rare Xbox game today! Haha.

Even though I'm still not off of my Cxbx break yet, I still want to share with you all what my plans are for when I'm ready to start working on it again. I still have multiple IRL things to take care of, and I think I burned myself out on Cxbx too many times. No worries, I shall return soon!

So, about this new game, what is it?? To much surprise, I got the opportunity to get my hands on a Japanese title (NTSC-J) known as "Petit Copter"! What is so great about this game? Well, after browsing the internals of this game, is looks like this game is of little complexity, uses an XDK Well supported by Cxbx (4361), only standard XDK libraries (No LTCG!), and an extremely simplified file structure. So far, this game looks very easy to emulate! I already did try running it with Cxbx, and the crash details so far appear to be very minor. The funny thing that happens with the debug output is that when the console is enabled, it crashes on a missing Xapi function (Rtl*Heap). On the other hand, this does not happen when the KrnlDbg.txt file is outputed; instead, it's a missing DirectSound function. No big deal though, nothing I can't fix.

When I take a good look at Cxbx, it appears that XDK 4361 has been a bit "neglected". Probably because there aren't (or at least it doesn't appear that) many games using this XDK exist. So far, I only have 2 besides Petit Copter (if you count Smashing Drive which uses 4242, but counted as 4361, that makes 3). Since I have this XDK already, finding the missing functions should be no problem. Can't wait to increase the compatibility list game count to 20!

Shogun.

Cxbx and OpenGL: Time to shed some light on this topic...

Okay, this question has come up many times (even more ever since I started that poll on ngemu.com getting opinions on an OpenGL port of Cxbx). Will Cxbx be ported to OpenGL? That's part of my plan, yes. For those of you wondering why I'd do such a thing, I'll give you an explanation as to why.

Ever since Cxbx has been released, you'll notice that it has been using Direct3D 8.0; notice a problem already? Direct3D 8 has been depreciated a long time ago and it doesn't really have any good debugging tools anymore. IMO, the driver support for Direct3D 8 isn't that great either. To top it off, PC standard Direct3D8 (and 9) does not contain all of the functionality we need to emulate the Xbox. Fortunately, OpenGL does! Using OpenGL will allow us to have a much cleaner implementation for certain functions if implemented properly. Some say that because OpenGL isn't COM oriented, an OpenGL port would be too hard. No, not really.

Ever heard of Wine? We can always use the WineD3D implementation instead. This way, we can basically have our own customized Direct3D library, and add all the custom functionality that standard Direct3D lacks... and still be using OpenGL the whole time! I've already picked up the idea and have been planning my implementation of WineD3D into Cxbx. It would be easiest to just take the needed code from WineD3D and create a custom library and call it WineX or something like that. Thank God it's GPL :)

So there you have it. An OpenGL port is planned, but as of now, it's still not a top priority. But once implemented, we can easily test it against XDK samples to ensure accuracy and speed when necessary.

Shogun.

Thoughts: DrawIndexedVertices[UP] may be our problem...

I've been talking to martin_sw about a few things Cxbx related a few days ago. Eventually we got around to talking about speed and corruption issues (for Panzer, Robotech Battlecry, and BattleStar Galactica appear to suffer from this). One interesting detail that came up was our implementation of EmuIDirect3DDevice8_DrawIndexedVertices. He says that if this function is used in any games we are emulating and speed/graphics issues occur, this function is likely the problem as it really needs optimization and stuff. I've never actually looked into how the Draw[Indexed]Vertices[UP] functions work on a real Xbox, and just assumed sir Caustik had that taken care of. Just in case you didn't know Draw[Indexed]Vertices[UP] is not a part of PC standard Direct3D. It's an Xbox extension and as far as I know, Draw[Indexed]Primitive[UP] is really redirected to Draw[Indexed]Vertices[UP]. I can do some simple tests to see what may be causing our problems.

I can hear you saying, "Do you have anything interesting to show us??". Hold on, I'm getting to that; okay, fine... lol. I got Robotech Battlecry to go in-game again. I still didn't get around to fixing the random problem yet, but someone from emu-land.net (IIRC) made a SSE2 optimized version of Cxbx r-153. It started up Robotech Battlecry about 4 times in a row without problems. I did make a few in-game screenshots for you (since I couldn't last time). They are highly distorted, but here they are:





Even through the frame rates are decent, you can't really do anything in-game because it crashes almost immediately. Since it was a release build I tested, I wasn't able to track the problem. I can already tell it's an internal problem in the CxbxKrnl. I tried to make a youtube video of this, but it looks like fraps can't correctly record this game (everything is just a few blue lines). Oh well...

So as you can see, the problem is getting pretty dire (haha). So I'll start testing some scenarios with DrawIndexedVertices[UP] on Cxbx and then try them on my real debug Xbox. Well, had to have some kind of update, heh heh....

Shogun

New SVN update (r-153)

If you've tried to download and compile my last SVN update (r-145), you might have had some problems. Well, I fixed those issues today (and tested them for myself), and hopefully, that should solve everyone's problems! What did I change/fix?

1. Updated the OpenXDK includes in the import folder. I forgot to fix that.
2. Updated the resource files Cxbx.res and CxbxDll.res. I didn't realize those changed at first.
3. Updated the libjpeg.lib file.
4. Added the DirectX8 SDK include and library files so if you don't have it, you can save yourself some time. It's an extra 12.5MB, but worth it.
   

This should make things easier for everyone now. If you don't have the DirectX8 SDK (or an SDK that has the required include/lib files), you'll still have to set the include/lib directories yourself in Visual Studio. One more thing, if you have conflicts with LIBC.lib, you can just add LIBC.lib in the "Ignore Specific Library" list (just remember to add a semicolon (;) after each lib. It's a single threaded library and Cxbx uses the Multi-Threaded options in VS 2008 making it obsolete. So go ahead and start compiling!

Shogun.

Chihiro XOR keys discovered!

Good news for all the Sega Chihiro enthusiasts! After a talk with Martin_sw (the one who added support for BattleStar Galactica for Cxbx), I got to find out that he discovered how to decode the entry point and kernel thunk addresses for Sega Chihiro .xbe files! If you've ever tried to load a Chihiro .xbe into Cxbx, you'll notice that the entry point is some absurd hex number! That's because the engineers for the Chihiro software decided to do things differently. So when loading a Chihiro .xbe file, use the following keys to decode the entry point and kernel thunk address instead.

#define XOR_ENTRY_POINT_CHIHIRO 0x40B5C16E
#define XOR_KERNEL_THUNK_CHIHIRO 0x2290059D

I haven't actually tried it myself, but Martin_sw really knows his stuff! Hope to make more discoveries that lead up to emulating this awesome arcade machine architecture!

Shogun.

Cxbx SVN update (145).

That's right, the shogun3d branch just got updated today. TSVN decided to stop being a jerk today, so now it's updated (rev-145). You can get it from http://cxbx.svn.sourceforge.net/viewvc/cxbx/branches/private/

So, what does this update contain? Everything I've done since last October actually. Sorry I waited this long. Just has to do it soon before something unfortunate happens. Yes, it plays Smashing Drive, Panzer, and Robotech: Battlecry (if you're lucky). Remember, this is still in the beta stages, so please don't ask me why your game doesn't work (even if it is on the compatible list) or how to compile it here because this blog is for the disscussion of the shogun3d-Cxbx branch's updates... not tech support nor a compatibility FAQ. If you need help, go to the forums @ ngemu.com (and don't PM me for support either!), okay?

Also, don't forget to chech the doc folder. There you can view my changelog (ShogunChangeLog.txt) and see what I've done and when I've done it. I've also started the XACT support too. It isn't fully tested nor is it complete enough to run any game using it, but Unreal Championship needs it. There's more, but I am typing from an iPhone so it takes too long for me to type it all! I'll have more updates soon!

EDIT: You'll need Microsoft Visual Studio .net 2008, the latest Platform SDK and a DirectX SDK containing the DirectX 8.1 headers and libraries to compile these sources (search google). If you don't have MSVC .net 2008, you can use an express version of 2008 downloaded from microsoft.com. If you are using .net 2010 Beta, you'll just have to try it for yourself because 2010 Beta isn't working on my laptop.

Shogun.

Robotech: Battlecry... hey, it was working a minute ago!!!

*sigh* I hate it when this happens...

Even though I'm still taking a break from the scene, I just thought I'd share this with you all anyway. Today I was getting curious about Robotech Battlecry again (XDK 4721). In general, I just wanted to see if anything I added in for Panzer fixed this one. It appeared that way, but then again maybe not. I booted up Robotech Battlecry with Cxbx, and it appeared to go in-game without problems (by problems I mean crashes). The distortion of 3D was worse than that of Panzer TBH, but at least it worked! I did take some screens though (how could I not?) so check 'em out below.






In-game, as I stated earlier, the 3D scene was heavily distorted! I should have taken a screenshot of it, but instead, I closed Cxbx in an attempt to run it with a Release build because I had the debug trace enabled and the debug console was also on and I wanted to see how fast it would run without the console slowing it down. After that, it never worked again! Debug or Release build, it just crashed. It appears that the DirectSound call that was causing the crash didn't get called that time. I'll look into the problem later as I am just way too tired right now.

When will I be back, you ask? I dunno when, but right now, the IRL issues are enough to keep me busy and sleepy throughout the day. It shouldn't be too long since I tend to have lots of free time these days. But today is not one of these days, so stick around. I have lots more tricks up my sleeve!

Just thought I'd keep you all posted on my progress today (even if it was just a one time fluke). So if you'll excuse me, I'll be taking a nap now!

Shogun.

Taking a break for a while.

Ever since I started working on Panzer, it's been taking a lot of my energy. Right now, I'm completely burned out from working on Cxbx. We all get this way. Don't worry, I'll be back. Just remember, we all have lives outside of the scene. I feel good that I've gotten this far, but sometimes you just have to take a step back and get back to other things for a while because the excitement is just killing me (literally, in one way or another).

Also, it may not be to long until Caustik is back in action. I won't say much at this point, but I think it's going to happen rather soon.

Before I go, I just wanted to share something with you all (just in case you haven't seen it). I made a youtube video of Panzer Dragoon ORTA ingame if you're interested in seeing it right now. So far, only the NTSC version is compatible, PAL doesn't work yet.

http://www.youtube.com/watch?v=4i6fmVuFgvA

When I come back, I'll try to fix a few more issues with Panzer and get back to work on a few other games I started working on, like Robotech: Battlecry and Unreal Championship, okay?

Shogun.

Continuing preliminary XACT support.

Yup, that's right, I'm finally getting around to adding XACT support for Cxbx. What is XACT? It's a cross platform audio API which was originally designed for the Xbox, but now included on the DirectX SDK and Xbox 360 SDK. It's a rather simple API and it shouldn't take too much work to get it up and running. So far I'm only adding it for XDK 4627 and 4928. The reason is that the only game I have access to that uses it is Unreal Championship. I've been working at this game trying to fix it for "years" (yes, it's that tough), and I have no intention on giving up yet. Besides, this was one of my first Xbox games and also one of the most memorable :) For now, I'll share my true motives for emulating this title later... I want it to be a surprise!

Even though XACT on Xbox1 is basically a wrapper for DirectSound, we still have no choice but to emulate it. Even though XACT is now on the PC, we still can't simply use the PC version of these interfaces because the .xwb and .xsb file formats appear to be different. Luckily for us, they have both been hacked and there are open source tools out there to help us learn how to parse these files ourselves. Since .xsb files generally use .wav files, I can easily use my custom wave loader to load sounds directly from that file. We'll still have to worry about non-standard PCM formats though (i.e. ADPCM, XBOXADPCM, etc.), but the Xbox Adpcm codec is also hacked and can be loaded via custom decoder.

When the preliminary support is finished, it will probably have the same status as DirectSound on Cxbx as just getting the functions hijacked are the most important thing. Then when the XDK samples work without crashing, then we can add the stuff that makes it work! Eventually, I want to get the Xbox Adpcm codec working. It shouldn't take too long, but it's only a medium priority now.

Oh yeah, I figured out why my XRefs were killing Cxbx. I forgot to increase the size of the XRef database array! I feel so stupid. Anyway, I can resume working on this HLE data base maintenance.

Shogun.

Cxbx compatibility list (Updated December 9, 2012)

This is something I've been meaning to re-write lately. Now that I have a chance to do it, my internet is not working too well (Comcast wireless). So we'll have to settle for the plain-old text version. My last list was on geocities (which was shut down last month), so I've managed to add every game that actually does something here. So without further adieu... here it is.

IF IT'S NOT ON THE LIST, THEN IT EITHER DOESN'T WORK, OR HASN'T BEEN TESTED!

***I've added a new catagorey called Nothing. This means the game shows nothing but a black screen, without crashing.***

Total Games: 61
Playable: 5
Ingame: 11
Menus: 12
Intros: 28
Nothing: 5

Newly added: None

Newly Updated: Rayman Arena, Zapper, Castlevania: Curse of Darkness.

1. Turok Evolution
Status: (Playable)

2. Battle Star Galactica
Status: (Ingame, with PAL and NTSC!)

3. Panzer Dragoon Orta
Status: (Ingame)(**)

4. Halo: Combat Evolved
Status: (Menus)

5. Dead or Alive Xtreme Beach Volleyball
Status: (Intros)

6. Unreal Championship
Status: (Menus) (***)

7. Myst III
Status: (Ingame)

8. Genma Onimusha
Status: (Intros)

9. Smashing Drive
Status: (Playable)

10. Futurama
Status: (Playable)

11. Celebrity Death Match
Status: (Ingame)

12. 4x4 Evo2
Status: (Intros)

13. Star Wars: Clone Wars
Status: (Intros)

14. Rayman Arena
Status: (Menus)

15. Zapper
Status: (Menus)

16. Taz: Wanted
Status: (Intros)

17. Robotech: Battlecry
Status: (Playable)

18. Blood Rayne
Status: (Menus)

19. Tron 2.0: Killer App
Status: (Intros)

20. Petit Copter
Status: (Ingame)

21. Fusion Frenzy (Demo)
Status: (Intros)

22. Commandos II
Status: (Nothing)

23. Taito Legends
Status: (Nothing)

24. Dead to Rights

Status: (Ingame)(*)(***)

25. Pacman Worlds 2

Status: (Intros)

26. Alter Echo

Status: (Intros)

27. Namco Museum

Status: (Ingame)(*)

28. Dues Ex: Invisible War

Status: (Intros)

29. Azurik: Rize of Perathia!!!
Status: (Ingame)

30. Burnout

Status: (Intros)

31. Blade II

Status: (Intros)

32. Kabuki Warriors

Status: (Menus)

33. Blood Wake

Status: (Intros)

34. Gauntlet: Dark Legacy

Status: (Menus)

35. Metal Arms: Glitch in the System

Status: (Menus)(****)(*)

36. Tetris Worlds: Live

Status: (Intros)

37. XIII

Status: (Intros)(****)

38. Nicelodeon Party Blast

Status: (Intros)

39. Simpsons: Road Rage

Status: (Intros)

40. Innocent Tears
Status: (Menus)

41. World Series Baseball

Status: (Intros)

42. Whacked!
Status: (Playable) (*****)

43. Quantum RedShift
Status: (Ingame) (*)

44. Amped

Status: (Intros)

45. Metal Slug 3

Status: (Menus) (*)?

46. The Red Star

Status: (Intros)

47. Exa Skeleton

Status: (Intros)

48. Barbie Horse Adventure

Status: (Intros)

49. Splinter Cell 2

Status: (Intros)

50. Fatal Frame

Status: (Nothing)

51. Mortal Kombat: Deadly Alliance

Status: (Intros)

52. Forza Motorsport

Status: (Nothing)

53. Angelic Concert

Status: (Intros)

54. ESPN NFL Primetime 2002

Status: (Intros)?

55. Antz Extreme Racing

Status: (Intros)

56. Panzer Dragoon 1

Status: (Menus)

57. Nakashima Tetsunari no Othello Seminar

Status: (Ingame?) (****)

58. Castlevania: Curse of Darkness

Status: (Ingame) (******)

59. Seablade
Status: (Nothing)

60. Blinx: The Time Sweeper
Status: (Intros)

61. Outrun 2!
Status: (Menus)

(*): Not interactive.

(**): So far, only supports Vista and later.

(***): Requires special hacks.

(****): Complete status not yet known.
(*****): Appears to have driver issues (primarily Direct3D) with my machine.
(******): REALLY Hard To Do!!!
So until I get around to setting up a new page dedicated to this, check this list every once and a while. You might be surprised! I have a few more tricks up my sleeve yet...

Shogun

The lastest on Shogun's branch.

Well, I'm really glad that I've managed to make it this far. I don't mean to sound... you know, but when I first saw the first screens of Panzer, I never dreamed that I would someday carry on sir Caustik's work and get it ingame, haha. Sometimes I miss being a noob! (Yes, that's right... "noob") :D

Anyway, here's the latest. I've managed to increase the stabilitiy of Panzer Dragoon ORTA for the most part except for a few but rare random crashes related to threads (not while in game luckily). So far, the framerates aren't very fast.

I think I have an idea about the overlapping quad covering the 3D scene. My guess is that it's really supposed to be transparent (Alpha Blended) to simulate fading in/out for 3D scenes. This reminds me of the time when I was working on Smashing Drive. The transparency overlay quad didn't work on my WinXP machine, but worked fine on my notebook PC running Vista. The problem may be related, but that can't be verified now because I don't have my WinXP desktop here in Washington (State), it's at my cousin's house still in Indiana.

I've added the Direct3D API IDirect3DDevice8::SetStipple (Xbox extension) and a missing texture state again (D3DTOP_BLENDFACTORALPHA, 15). So far, that appears to be the end of any missing Direct3D function calls. That's a big relief!

The main thing stopping our progress now is this missing low level DirectSound Buffer call to either CDirectSoundBuffer::Pause (as stated in my last update) or CDirectSoundBuffer::GetStatus because when looking at the dissassembly of them both, they look the same! I had the same problem with Robotech: Battlecry (XDK 4721), so fixing one will fix the other. Initially I was having trouble adding it because when Cxbx would locate my OOVPA for it, it would crash. This had me scratching my head for quite some time now. I discovered a few minutes ago that when I moved the XREF IDs higher up in the list, then they work fine. That's really strange, and I hope it doesn't cause any future problems because if it does, then we can forget about Metal Gear Solid 2 (and no I don't care about the fact there's a PC port, I still want to see it emulated)!

Before I conclude this blog update, I just want to address one more thing. This question/suggestion has come up on more than one occasion for a long time now (in fact, someone asked me about this today!)... can Cxbx use a more up-to-date API such as OpenGL or at least Direct3D9? If so, when? Good question. Right now, an OpenGL 2.1 implementation is looking much better. Direct3D9 would also be a major improvement. I'll show you the pros and cons of both.

1. Direct3D9
Good:

• Easiest to debug. More debugging tools (i.e. NVIDIA's PerfHUD).
• Requires less code wrapping/hacking.
• Easier to manage.

Bad:

• Still lacks many features native to NVIDIA's hardware.
• Less control over some settings (i.e. some games get CreateDevice failures when VSync is enabled).
• Not portable.

2. OpenGL
Good:

• Closer to the hardware we're emulating. Some Xbox Direct3D features are only exposed via OpenGL.
• VSync can be enabled/disabled without problems.
• Better texture support for those unusual formats (IIRC).
• Locking/updating resources are much faster.

Bad:

• Harder to manage (i.e. lots of extensions to deal with).
  
• Lots of data type converting can get annoying (i.e. DWORD dwARGB -> float4 fRGBA).
• No native support for YUV surfaces. Will have to convert YUV -> RGB manually which may increase overhead.

So far, OpenGL is looking better now. But then again, we can always use Wine's Direct3D -> OpenGL implementation as suggested by Caustik and Nisse (a glass of wine sounds pretty good right about now!), and add Xbox specific extensions ourselves.

That's what's happening with Cxbx today. Until next time.

Shogun.

More Panzer Dragoon ORTA stuff...

Yup, I'm still at it. This thing is getting way too addictive IMO, just can't stop working on Cxbx, especially when making significant progress such as this. Just a few minor additions and discoveries. Here's the latest... Rewrote my implementation of IDirect3DDevice8_GetTexture2@4. Since it kept causing a crash in there and IDirect3DResource8_Release, I had to write a dirty (and yet sloppy) hack to fix it. What I did:

• Get a copy of the currently active texture (without allocating any memory).
• Return the copy without increasing the reference count.
• Added a special flag in the X_D3DResource::Data field to represent that this texture is a clone.
• When IDirect3DResource8_Release is called, don't release the texture if it's a clone.

The code is really ugly, but at least it works (for now) without leaking memory like crazy.

Now that I've taken a closer look, it looks as if that 3D does work! The textures look buggy when viewing Pandora's Box. You can't see it in game because there's a black quad covering the entire scene. The above fix allows you to stay in game a little longer, but there's yet another missing Direct3D API. This time, I have no leads on what it is.

One last issue. Microsoft must have had Cxbx in mind when they released XDK 4721. That stupid and totally useless piece of crap IDirectSoundBuffer8_Pause function is giving me trouble (it's another problem on Robotech: BattleCry). I'll need a break to my brain can rest after putting so much energy into this... good night.

Shogun.

Panzer Dragoon ORTA: More progress!

Okay, I got around to trying to get Panzer Dragoon ORTA a bit more stable in Cxbx. It's not perfect yet, but it's getting there. Panzer and Windows Vista don't get along at all, so it makes thing a bit more frustrating. Nothing I can't handle (I hope).

So, what's new? Okay, Panzer Dragoon ORTA is finally showing some REAL in-game progress. It's still not considered playable at this point (still some bugs to work out). TBH, I still don't think I'll remove the "asterisk" yet, but like I always say, you can't complain about what little progress comes by, because in this neglected area of emulation, some is better than none!

New functions added:

• IDirect3DDevice8_SetPixelShaderConstant (4928 - 5344) (implimented only for 4928)
• IDirect3DDevice8_SetRenderState_TwoSidedLighting (4627 - 4928)
• IDirect3DDevice8_GetTexture2 (4627 - 4928)

New deferred texture states added:

• Added D3DTOP_BLENDTEXTUREALPHA (14)

Current issues: There may be a problem with my implementation of IDirect3DDevice8_GetTexture2. Since no one else did it, I had to write my own. It's a bit more complex than you might think, but here's my current approach.

// Since this function does not specify any texture stages,
// I guess we can assume it's just the first one. According
// to the XDK documentation, this function should also add
// to the reference count.
// TODO: Verify texture?

pTexture = EmuD3DActiveTexture[0];

EmuSwapFS(); // Xbox FS
EmuIDirect3DResource8_AddRef(pTexture);
EmuSwapFS(); // Win2k/XP FS

Another idea I had was this:

hRet = g_pD3DDevice8->GetTexture(0, pTexture->EmuBaseTexture8);
EmuVerifyResourceIsRegistered(pTexture);

What happens is that Panzer does an unusual act of getting the current texture, setting to some stage, then releasing that copy of the texture. Not 100% sure if it's my implementation of this function, but Cxbx crashes when releasing the texture. I'll try implementation #2 later on, because it's late and I'm tired!

What's the deal with no 3D graphics? It's too early to say right now, but so far I've narrowed it down to two possibilities:

1. Incomplete PushBuffer simulation. This was a problem in Turok (and still is occasionally).
2. RenderTarget problems. Cxbx continuously informs us that it's setting the render target fails.

Upgrading to Direct3D9 or better yet, OpenGL, may do use some good. That's for a later date though...

Shogun.

Panzer Dragoon ORTA: Some progress...

Since Cxbx's activity is rather low these days, I think starting a blog dedicated to my work on Cxbx would be a good idea so that everyone knows it's not dead yet. Right now, I'm the only one who has the time to work on it (I don't have much, still).

The purpose of this blog is to keep you all up-to-date on what's going on with my Cxbx branch. This is NOT a help line. If you need help, click here to be taken to the Cxbx official forum (and read the rules before posting). DO NOT ask me for roms, ISOs, betas or release dates! Requests of this nature will be ignored!

Anyway, last night I got to work on Cxbx for a while (I really had nothing else to do). I was originally trying to fix some problems with Taz: Wanted and Zapper. These two games use the same engine and share the same problems/bugs so far, so fixing one will fix the other! Instead of finding a solution for those games, I ended up fixing Panzer Dragoon ORTA (XDK 4928) unexpectedly! I was scrolling through some output generated by IDA and noticed some code referenced ObReferenceObjectByHandle. After seeing that, the first thing that came to my mind was, "Forget it, this is my chance to fix Panzer!", lol! Turns out it was just a missing call to GetExitCodeThread, which hasn't changed since 3911, so all I had to do was copy that over to 4627 and it worked... after adding some more missing functions below (verified for all XDKs within the range listed):

RtlDestroyHeap (4627-4928) (Others?)
CDirectSoundVoice::SetAllParameters (4627 - 4928)
CDirectSoundBuffer::SetAllParameters (4627 - 4928)
IDirectSoundBuffer8_SetAllParameters (4627 - 4928)
D3D::SetFence (4627 - 4928) (*)
IDirect3DDevice8_InsertFence (4627 - 4928) (*)
D3D::CDevice::KickOff (4627 - 4928)

(*) These weren't required for Panzer.

Now, for the good news and bad news:

Good:

• You can get passed the menus and initial dialog.
• Audio output is almost perfect and stutter free. Background music works, but a few sound effects are missing.
• No more crashes due to missing APIs!

Bad:

• So far, it appears that 3D is not rendering (can't confirm this yet). If this is true, it's more than likely a problem in the push buffer simulation (then it's Caustik's problem).
  
• Even though Panzer is no longer bound to the menu stages, you can't exactly "Play" it either. So right now I'm going to set Panzer's status to "Ingame" with an asterisk (*).
• Either way, you will get the dreaded dirty disc error message again prior to going ingame. We might be able to copy some of Panzer's files directly to it's folder in the emulated Z: drive. This is what I had to do for Myst III.

So, it's nothing too major, but in general I'm picking up where Caustik and KingOfC left off. The solution to fixing Panzer Dragoon ORTA might be simple, but I could be wrong. Stay tuned, and I'll see what I can do.

Shogun.