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.