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.