Sunday, November 29, 2009

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:


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!*


Tuesday, November 24, 2009

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.


Sunday, November 22, 2009

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!


Thursday, November 19, 2009

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!


Monday, November 16, 2009

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 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.


Saturday, November 14, 2009

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 (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....


Friday, November 13, 2009

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!


Wednesday, November 11, 2009

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.


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!


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

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 @ (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 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.


Monday, November 9, 2009

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!


Friday, November 6, 2009

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.

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?


Thursday, November 5, 2009

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.


Wednesday, November 4, 2009

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.


***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...


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
  • Easiest to debug. More debugging tools (i.e. NVIDIA's PerfHUD).
  • Requires less code wrapping/hacking.
  • Easier to manage.
  • 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
  • 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.
  • 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.


Tuesday, November 3, 2009

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.


Monday, November 2, 2009

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:

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
EmuSwapFS(); // Win2k/XP FS

Another idea I had was this:

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

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...


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:

  • 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!
  • 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.