Blueshogun's Cxbx Dev Blog

Xbox Dashboard (3944)

2011-11-02T16:09:00.000-07:00

I haven't done any serious work on Cxbx since June this year due to the fact that not only am I spending more time working on my own emulator but working towards getting a long term job (I've been getting quite a few good job prospects), but last night I wanted to play around with the source a bit. And what do you know? Something good came of it after all. I managed to get the Xbox Dashboard (the one built with XDK 3944) to launch, so don't go dumping your own dashboard and send me crazy questions/complaints pertaining to their dashboard not emulating. Only the very first retail Xbox Dashboard works so far, NOT any latter ones yet. I have a copy of the 4920 dashboard, but I have to find it.

Most of the menus can be accessed without problems, but you may get some bogus results sometimes. The time/date is automatically set to the time your computer is running. The memory section doesn't work yet because I can't get the dashboard to accept the fact that I'm not emulating any memory cards! It's probably because there's more to emulating XMountMURootA() then I thought; I just redirected it to XMountMU to get it over with. Oh, and checking the system details will cause a crash.

Quite frankly, I've been working at this for quite a while in the past, but like I always say, I tend to make the best progress after leaving it for a while, then coming back and getting something working! It wasn't exactly "hard" (for the most part), just a matter of hacking my way around certain things. I ended up adding quite a few new features to some existing implementations such as the "Y:" drive (which I just redirected to the current directory) and some other things I can't really remember.

"Why emulate the dashboard?" Because I felt like it, for starters. Second, I like the challenge, which may lead to fixing bigger bugs. You know what I mean, right?

If you look through the source code (at what I changed) you'll notice that HalReturnToFirmware doesn't return when the error code is 4 (the one that makes your Xbox show the multi-language screen saying your Xbox needs servicing). That's just a silly hack to get passed the "Challenge Response Protocall" code since Cxbx doesn't properly emulate the kernel functionality to do it (i.e. XcSHAInit/Update/Final). For a more detailed understanding if you don't know what that is, read this thread: http://www.xboxhacker.net/index.php?topic=455.70;wap2

Don't have much else to say except I did comment out the Gamma Ramp code to prevent problems with certain games in fullscreen mode (Unreal Championship, Azurik: Rize of Perathia, and Robotech: Battlecry in particular). If you need that functionality, just delete the comments in front of the PC equivelant in EmuD3D8.cpp. Okay?

Have fun,

Shogun.

EDIT: The Youtube video for those who want to see it in action: http://www.youtube.com/watch?v=cIeMbH6ug-c

Still here.

2011-05-14T18:16:00.001-07:00

Okay, there's been alot of talk/rumors going on here. I'm really getting sick and tired of hearing all of this crap, so it's time I set the record straight.

For starters, people are saying (more like assuming) that I've discontinued working on Cxbx JUST because I left forums.ngemu.com. This is NOT true. I am STILL actively working on Cxbx from time to time, and that hasn't changed. Lately, I haven't had too much to report though (sorry about that, I'll post that when I'm ready), but I want you all to think about this. Did I actually say that I left the emulation scene? Did I say I was done with Cxbx? No, I didn't. So why are you making these bulls@#% assumptions??? Gah, it makes me kinda mad knowing all of this has been going on! I've said this so many times before, and I'll say it one more time. It's not over until I say it is!!!! Got it? Good.

Second, some of you already know about this, others don't so I'll go ahead and say this now. I haven't said much about this before, and I have almost lost some good friends on the net because of it (thank God I didn't), but, I've been working on a new Xbox emulator (and yes, it does work to a certain extent). It's an LLE Xbox emulator because now that PCs are capable of handling it, there's no real need to use HLE. Now, it's in the alpha stages and it doesn't do much atm (meaning it won't play your favourite games or any games right now), so don't start requesting games and compatibility features like ISO support right off the bat. I won't get too detailed on it here. I have a seperate blog for it and I'll post progress there.

Furthermore, until I'm ready to do otherwise, when I make releases, I'll be making "source-only" releases. Meaning that if you can't compile the source code yourself, then you're out of luck. The reason for this is because the last thing I want are n00bs banging down my door asking "when will game X work" and that "ur emu sux ass" and all of that BS. If there's one thing I noticed, it's that there's a direct correlation with the "warez monkeys/freeloaders" and the inability to understand or appreciate source code, so that will eliminate alot of my headaches there. Not trying to sound better than anyone else, but I get enough complaints with Cxbx as it is... really.

This is the blog link: http://xenoborg-emu.blogspot.com/. Follow it!

Third, I do want to mention some things I've done with Cxbx. I haven't gotten any new games playable lately, but I did get some progress done on a couple and learn a few new tricks. I finally got Metal Slug 3 to do something, but everything is highly distorted, so I can't tell exactly what it does atm. All I know is that it's at the menus and the sound does appear to work (but heavily distorted). I also finally managed to make a bit of progress on Panzer Dragoon 1 the other day. Surprisingly, after fixing the Panzer Dragoon ORTA demo and getting it ingame (still not playable), it started doing something. All it does is play the intro video, but very slowly. Unfortunately, you can't see it because Cxbx still isn't properly equipped to deal with render targets and stuff. After that, it crashes. I can't remember the details right off the bat, so I'll make another blog post about it later.

Okay, it's dinner time. So I'm going downstairs to see what's for dinner. I hope this clears up all the misconceptions. Sorry for getting mad, It's just frustrating to see people making assumptions about my status on the scene without asking me first!

Shogun.

Think I Found the JSRF Problem and Other Random Cxbx stuff.

2011-04-17T20:09:00.000-07:00

Meh, it's been a while since I've updated this blog. Lately, I've been working IRL (which is great) and haven't done a whole lot on Cxbx (needed a break anyway), but I do have a few things I want to say though.

First, I'd like to thank Evan "spidertrax" for sending me the copy of Amped in exchange for the game's sound track. This game has been a major help in finding problems within Cxbx. While the lack of XG signatures were obviously lacking, I was quite sure that it had to be the source of numerous problems. I managed to get a dirty disc error out of it, but that was about it so far. (Screen above, obviously).

Let's start from the beginning. When I got the copy of Amped, I noticed that there was something strange going on in EmuIDirect3DResource8_Register. Cxbx's implementation interprets it as a vertex buffer, but wasn't the case. So, I loaded up the .xbe file in IDA and applied the necessary .sig files to see if there was anything not being intercepted. Turns out it was XGSetTextureHeader. Never noticed that function before then, but I honestly don't see what makes it useful to begin with. What the function does is fill in the variables within the structure (D3DTexture is not a real COM interface) and return a pointer that is ready to be passed into D3DResource::Register. Sounds easy to implement right? Yeah, but so far, I can't get it to work for some reason. More on that later.

My initial thought after finding it was "I bet this is the culprit causing the trouble with other games like Crazy Taxi III!" So, I pulled up Crazy Taxi III. Did I find it there? I sure did! So after that, improving XG emulation has been a higher priority. What was my next instinct? Test JSRF, of course. Was it there? IIRC, yup, it was. Is that what was causing the problem? Not sure, but there were other XG functions being used in it, so I'm sure it's one of 'em. With JSRF, the particular one that caught my interest was XGCompressRect. Never noticed that one either, but if it's like XGSwizzleRect internally, then it needs to be emulated. If I can ever get a working implementation of that function and all of the XGSet[x]Header function(s), then maybe it will finally work. Honestly, JSRF has been kicking my ass for a long time, I'm running out of patience with it. If it doesn't put out after THIS, I'm going to say "f@#% it" for a while and try again later.

Shogun.

Random Update

2011-02-28T13:25:00.000-08:00

How it's going everyone? Good, good. I haven't gotten to work much on Cxbx for the past few weeks, but I do want to give at least a partial update of what I'm doing for it now. I haven't made any breakthoughs, but hopefully what I'm working on will lead up to one eventually.

To start off, I finally found out what's going on with Quantum Redshift, although I still can't find a solution to the problems. The biggest problem is with the controller input. Turns out that it calls XInputOpen and no other Input APIs are called after that! That's strange. It probably has to do with the initialization of gamepads and memcards within XInputOpen. I'll have to hack away at that later. Second, I added support for more descriptive error messages via dxerr8 library so when Direct3D resource creation APIs fail, I know exactly what the error was. Turns out that texture that keeps failing to create is returning E_OUTOFMEMORY, which means Direct3D couldn't allocate enough memory to create it. Keep in mind that this doesn't necessarily mean that I'm out of video memory. According to GPU-Z, I'm not using much for this game. Looking at the task manager, I'm not using more than 64mb or Ram either. So I don't know what the heck the problem is *shrug* Any ideas??

Oh, about Gauntlet. I've gotten a few questions about it. Honestly, I never got the chance to get that game yet, so I haven't gotten it playable yet. Which leads me to another issue: 8-bit palletized textures! This issue is far to big to overlook. Now that I have my debug Xbox out of public storage, I can actually write some code to load an 8-bit paletteized texture on the Xbox, and verify that it works on the PC. So what I'll probably do is write a .PCX file loader supporting 8-bit textures and go from there. How does that sound? To be honest, the lack of 8-bit palettized texture support does cause quite a few games to have issues. One of those games is Alter Echo (which is a prime target game for me). Other games like Fusion Frenzy, Tetris Worlds, Smashing Drive and Soul Calibur II use it too.

The other day, I was trying to pull Azurik apart to see what's causing all the problems. I didn't find much yet, but I did get something good to come out of working on it that day. First off, I added a fix that will enable you to sync your games to 30fps. Games like Azurik and Halo will require this to play normally since they run way too fast at 60+ fps. I did a sync to vertical blank twice every frame, and it works great. Since my laptop only supports refresh rates at 60Hz, it probably won't sync to 30fps for higher refresh rates in windowed mode. Have you ever tried to view a game in wireframe mode only to see nothing but missing textures? I added a fix that will allow you to see the game in wireframe mode no matter how the game is rendered. This was essential to finding out what was going on with Azurik (should have taken a screen shot to show the funky results). Oh, I also added code to show the current primitive count in the title bar, that's something I should have done before! So far, Azurik renders 88,000 primitives within the training room (one single isolated small room) alone! For an Xbox game, that's alot.

"That's cool in all, but did you find out what the problem is?" Not yet, but given the fact that the game uses some unconventional methods for vertex shader creation, that might play a big part in it. For starters, Azurik starts by creating some really wierd vertex shaders that equate nothing but the version number (vs.1.0) after the conversion. I had to create a dirty hack to get around that to avoid crashing. It's been a while since I've checked, but it looks like the vertex shader doesn't even match up to the vertex declaration to begin with! Second, it uses D3DDevice::LoadVertexShaderProgram (or one of it's relatives) which is an API that none of us ever implemented yet. Sounds like an easy fix, but it really isn't. Should look into it because vertices might be transformed within a shader for all we know. I'll make another post about the specifics relating to Azurik's vertex shader madness later.

One more thing. I'm still trying to find out what the heck is going on with JSRF and what's causing it to crash without any indication to the problem. Not even the stack trace helps :/

This is what I'm going to do. This game uses XDK 4134, one XDK we don't have (making matters worse) and I ended up redirecting DSOUND for 4134 -> 4627 since it appeared to work and most of it was similar or the same. There might be a chance that there was a missed DirectSound call, so I'm going to remove that hack and start manually working on a new .inl file for DSOUND.1.0.4134. That way, if the issue is DSound related, I can hopefully fix it easier. It could be something else, but I've already worked my butt off to write/find specific signatures for this XDK. Lastly, I'll do one more check for false positives. That's caused problems in games before, so it's a possibility. Let's just hope the game doesn't uses RTPatches! Then you'd need a GeForce 3 or a GeForce 4 to play it. >.<

Other than that, I haven't done much as of late. Still have to continue my job hunts and that crap. See ya!

Shogun.

More on Quantum Redshift

2011-01-29T17:27:00.000-08:00

Okay, just wanted to make a quick update on Quantum Redshift (XDK 4721). I'm going to update the status of this game to ingame with an asterisk or two for the due to the fact that it does show ingame gfx even though you can't interact with it. It's still really buggy and I don't know what's causing those hideous bugs. There's no push buffer usage, and the primitives are rendered via D3DPT_TRIANGLESTRIP. Maybe I should check the FVF for unsupported flags.

The primary issue is the fact that this texture keeps failing to create/resigter! It's always the same 512x512xDXT1 texture (8 mip levels). I don't think my VRam gets full, but I don't seem to have any problems creating a texture with the same specs outside of Cxbx. Strange.... o_O Meh, this project needs OpenGL so badly, and the Direct3D8 support for modern card drivers aren't too great either. I did get a dirty disc error once, but that was before these errors started poping up. Since the game is loaded in a seperate thread in the background while you are being given a tour of the map, it will keep going forever since the texture failed to create. I wish the stupid thing would work. Those texture specs are no big deal and take up minimal VRam.

"Don't just complain about no OpenGL support, get it working!" Hey, I'm working on it! Xbox Direct3D is rather complex and it will take some time to get it working right, you hear? Speaking of that, I think I finally found a permanent solution to our PixelShader problems. Instead of converting pixel shaders to low level assembly (i.e. GL_ARB_fragment_program), we can use Cg and choose what ever fragment shader profile we want, or let Cg choose for us. This way, we won't have to worry about any shaders being too long to convert properly. It will raise the system requirements a bit, but it's a small price to pay for accuracy! I plan to do the same for vertex shaders too. Fortunately for us, _SF_ released his pixel shader conversion code years ago and gave coders permission to use it (as long as we give him credit of course). Ahh, just can't wait to kick Direct3D8 to the curb!

Just got these details a little while ago. Hopefully I can find out what is causing controller input not to work for some games. It's preventing me from making further progress. :(

Shogun.

Whacked! is playable and more

2011-01-29T14:31:00.001-08:00

I hope that this update is proof that I DO listen to user's requests!

Let's kick off the new year with some cool updates, shall we? Got lots to share, but so little time to share it all xD

As you can see, the game known as Whacked! (XDK 4831) appears to be playable for the most part, but I do have some good news and some bad news about it, and hopefully the bad news won't apply to you. But first, let me do a quick rant. Whacked is my 3rd favourite Xbox game of all time, and it makes me feel great knowing that it's now playable on Cxbx and cheers to the guy that requested it too. It only took me one night to get it working, fortunately. This is how I got it working.

When I first tried to emulate Whacked, I was ready to pull my hair out! Cxbx did not initially support XDK 4831, and it's been on my todo list for a long time. Knowing that 4928 is treated as XDK 4627, I figured that it would work if I did the same for XDK 4831. Did it work initially? Nope. That was the most annoying part. Eventually, I found out that it was missing a call to XapiApplyKernelPatches, which was thought to have originated in XDK 4928. So I added that, and that XDK started working normally. Did Whacked work after that? Nope. I was still getting crashes for some strange reason. I couldn't figure it out to save my life at the time, then when I found it, I felt like a n00b! Read on.

A few days ago, I bought some used Xbox games from the GoodWill store for $5 USD each. One of them was the Exhibition demo disc. I know they are only demos, but I got it anyway because it said it had content for DOA3 (which was released prior to Xbox Live's launch, giving it potential value knowing that Xbox Live for Xbox1 is dead). Now, I took it back to my place and did a dump of that disc and just for the heck of it, I tried the Whacked demo. It crashed for the same reason. So I pulled it up in IDA, and it turns out it was just a missing call to D3D::PixelJar::Lock3DSurface. Easy fix, but it's a mystery why that was never added. When I found out that was the thing stopping it from going ingame, I damn near slapped myself because I was stumped on this for a very long time. Did Whacked become playable after that? Still no -_-. Took me a few hours to track the next problem, but I got it though. Turns out that it was just a missing call to XMediaObjectCreateEx. I wrote enough code to make the function fail, but the game still worked after that. That's what fixed the game, and now other games that use it should have less problems, because honestly, I've been dodging this API for a while.

"Okay, it works! Now that's the good/bad news?" Okay, sorry. Had to get that off my chest :)

While the game does appear to be playable, I do want to address a few things.

Good:
- Runs at stable frame rates with debug logging disabled.
- Uses time based movement and every map appears to work so far.

Bad:
- I think I'm having driver issues with my PC and this game. It likes to crash sometimes when creating a 128x256x16 texture. Might not effect everyone.
- Missing textures and post processing effects.
- No sound (the audio is hilarious).
- Only works in debug mode so far. Playing in retail mode crashes.

The point is it works, and when I get the opportunity to update the SVN, you can try it for yourself and see what happens.

Next on our list is Quantum Redshift (XDK 4721). This is another game that a user requested (which was also on my todo list). I can't get passed the menus because the controller won't respond. This is the same problem with Metal Arms. This game makes use of blending effects that are only available on PC via OpenGL. Last time I checked, Direct3D is not capable of using constant colours for blending. Sucks, but I'm working on the OpenGL layer still, and it will be supported once it's finished. This is another one of my favourite games. It's a totally awesome futuristic racing game with an excellent soundtrack. Highly recommended by blueshogun! In the future, I'll look into the issues with this game.

Next is World Series Baseball. This image was submitted by Bill_gates (no, not the Microsoft founder), and since I don't have this game, I can't go any further on it yet. Why the strange interlace-like look? I dunno, looks like a problem with his ATI card drivers :/

Lastly is Splinter Cell the demo version. I also have the full version, but it doesn't play the intro video in Cxbx. I haven't found out why, but I'll look into it later. That game is a headache to deal with. At least the demo shows that there is hope somewhere along the line for it though.

So there you have it, some cool new updates and proof that I do consider user requests. Don't make this your green light to make ridiculous requests like crazy, but requests are fine. Just don't expect it to happen right away.

Stick around,

Shogun.

More on Innocent Tears & [Native] XInput support.

2010-12-21T18:40:00.000-08:00

Okay, I made a quick examination of the game's contents to see how tough it will be to get this game working. So far, I hate to say it, but it's going to be rather tedious :( This game contains multiple .xbe files besides the default.xbe itself that are loaded at different times while the game is running. One for intros, gameplay, movie play back, etc. It can be done, but it's going to be really annoying! Fortunately, I learned how to handle this situation with Unreal Championship. We'll have to launch the specified .xbe file each time in order to progress through the game. Cxbx saves the launch data as CxbxLaunchData.bin and loads it when necessary so the game can function properly. Then there are some new DirectSound APIs I have to add (one looks really daunting) and maybe we'll get somewhere. Either way, the compat list is now 40! Thanks to everyone who helped make Cxbx what it is today, including the fans and other enthusiasts that refused to let it die!

"Wait, you added XInput support?" Yup, XInput for the 360 controller is supported now, but for some reason, it works on some games, but doesn't work on others :( I don't know why this is, but I'll continue to look into it. Using DirectInput for the 360 controller isn't really desirable since we miss out on rumble and the d-pad, so I added it. Btw, is this desirable for you guys? If so, then as a result, Cxbx won't support Win2k anymore because XInput only works on XP and later. Just so you know.

Just thought I'd throw this quick update out there for you (while I actually have the chance).

Shogun.

Random update(s) & OpenGL project updates.

2010-12-21T13:14:00.000-08:00

Yup, that's right. I'm still kicking! And now that I have a spare moment, I thought I'd share some good news with you all. Nothing spectacular, but hopefully this might interest someone out there :)

As you can see here, the game known as Innocent Tears is showing stuff. This screenshot was not taken by me, btw. It was taken by Bill_gates (no, not THE bill gates, the one on ngemu!) and I don't have this game for myself (yet) but since it uses XDK 4627, I think getting it working passed this screen won't be too hard.

The next thing I wanted to mention was that I finally figured out what was causing Azurik to hang in XP. Turns out it was an Xbox exclusive flag being set that matched a PC flag. The flags MEM_NOZERO (Xbox) and MEM_ROTATE (PC) have the exact same values and causes failures when used with MEM_COMMIT. So all I had to do was omit that flag, and bam, it works again. Why this flag combination works on Vista and later is beyond me, but meh, I'm glad I solved the problem on XP. Azurik still looks rather horriffic going ingame (I've never seen such major distortions in any game to date), and Cxbx generates some funky pushbuffer results for it. No clue how I'm going to emulate this game properly :(

One more thing, I started writing my Xbox Direct3D -> OpenGL 1.5 driver last week in my spare time. So far, it works okay, but it still has a long way to go until it is ready to handle Cxbx. It wasn't really hard or anything, just having to fix annoying bugs to get it to work and trying to support the large array of features and formats is going to take time. It's not intended to replace the actual Direct3D .dlls, but it's (right now) a customized .dll that I aptly named d3d8_xbox.dll that is called instead of d3d8.dll, but you still have to link it with the project. Right now, I'm just testing it against DXSDK examples to make sure it works okay. Here's what I did so far:

D3DDevice creation and OpenGL initialization for windowed and fullscreen modes. Also uses glew to initialize the required extensions, saving me precious time and headache.
Primitive rendering via D3DDevice::DrawVertices[UP] and D3DDevice::Begin/End. Right now, it uses immediate mode because my vertex array code kept crashing, but for now, getting it to work is the primary concern. Any calls to D3DDevice::DrawPrimitive[UP] are redirected to the above by default. Indexed geometry is not yet supported. Also, every primitive type is supported, so no more primitive patching for non standard primitive types like D3DPT_LINELOOP, D3DPT_QUADLIST and D3DPT_QUADSTRIP! This should run much faster in Robotech: Battlecry and Panzer since they rely on Quad rendering heavily. Also, I'm going to stick with immediate mode for D3DDevice::Begin/End since that's basically what it is, and speed isn't critical for these related APIs.
Very basic push buffer emulation via D3DDevice::BeginPush/EndPush. Once again, I'm using immediate mode for it. Works like a charm.
World, View and Projection matrices/transformations. I found another D3D -> OpenGL wrapper out there and got the idea for how to do it from that project (dxwgl, IIRC). Before then, I couldn't figure out how to do it. The solution was simple once I understood how it worked.
Lighting. It works, but only when I don't set the light position :/ I wonder why that is... Btw, is there an OpenGL equivelant to the "Range" field in D3DLIGHT?
Textures and surfaces work, but I only wrote support for D3DFMT_X8R8G8B8 and D3DFMT_A8R8G8B8 so far. Textures use the standard 2D texture, but surfaces use texture rectangles since they are more efficient for such an operation. Special care has to be taken into consideration when dealing with surfaces to make sure they behave properly when rendering normal 3D geometry with certain render states. For instance, I have to disable almost every render/texture state prior to rendering it, but it pays off with speed. My surface code is about 4x faster than Direct3D itself, even when using immediate mode!
Various render states. I haven't finished adding all the renderstates, but many of the renderstates not supported by standard Direct3D have been implemented, so we no longer have to worry about those!

There are many more features to go, but give me a month, and hopefully it should be working at a satisfactory level. The big thing that troubles me is converting the vertex/pixel shaders to OpenGL vertex/fragment programs. I can use NVparse and do this easily, but then we'll be limited to NVIDIA cards and ATI users will be left out, or is there an equivelant library for ATI users? If not, I'll try to use the ARB versions for both. Okay? If it works, then we can kiss many of our compatibility problems goodbye!

So, there you have it. This is everything I've been up to so far. I'm still having it rough IRL (well, not too bad since I have stable housing now) but at least I have a bit more free time atm (but I can't spend it all on Cxbx unfortunately). Isn't open source a great way to go?

Shogun.

EDIT: I found this today: http://realmforge.tigris.org/source/browse/realmforge/trunk/src/Axiom/RenderSystems/OpenGL/ATI/PixelShader.cs?revision=5&view=markup

It's in C#, but maybe a bit of hope for the ATI users for a working vs/ps1.1 -> ATI vertex/fragment program conversion.

Metal Arms and more!

2010-11-09T15:45:00.001-08:00

Now, I realize I've been leaving you all in the dark for a while, and I'm sorry about that. But please understand that I absolutely MUST take occasional breaks from Cxbx and the emulation scene. Not only do I have a life outside of Cxbx (which you all can understand, I hope), but I can't overload myself or else I can't make good progress! I usually do better when I take a break for a month or two after exhaustion, then come back full force. The above screens are proof of this. Let's get on with the updates (I only have 7 minutes).

Lately, I've been putting some time and effort into emulating games with XDKs 5233-5558. Since I have the XDKs necesarry and games that I've been neglecting, I thought I'd take the time out to see what I could get working.

Metal Arms (First 4 screens, XDK 5558): This game is friggin awesome! I've been working with this game since yesterday, and it's already looking good. The intro videos play fine, but are a bit stuttery (as usual) and it reaches the menu screen just fine (but lacks textures, etc). "So, can you play it?" TBH, I don't know. The controller doesn't respond at all, so I can't find out if it goes in game or not. Keep in mind, that only the buggy screen represents in game gfx, not the others (they are all bink videos). If anyone has this game, please try it next time I get the SVN updated.

The other two screens are Tetris Worlds Live and XIII. Sorry, I have to cut this short, I only have a few seconds. I'll complete this update later. Stupid library...

Shogun.

Gauntlet: Dark Legacy

2010-11-04T15:23:00.000-07:00

Yeah! That's what I'm talking about, an RPG on Cxbx! But hey, any progress is good progress. Credit goes to LoveMhz for discovering this. I have to get a copy of Gauntlet sometime.

"Where have you been all this time?" Relax guys, some emu authors disappear for years without saying anything, just be happy I only disappear for months at a time :) But seriously, I'm in a lot of mess right now, and it's going to take a while to get it all sorted out. Housing, jobs, credit, the stuff you hate dealing with. Yeah, it sucks.

Enough of that, I'm tired of whining! As you can see, Gauntlet: Dark Legacy (XDK 4242) is starting to work to a certain extent. So far, it only goes to the menus (keep in mind that I only have these screens to go by for now). When I get the game, I'll see what else needs to be fixed to get it working in general. I'm hoping that it's just a few missing APIs preventing it from working, and if that's all, it just might work no problem. So far, games that use XDK 4242 have been surprisingly easy to deal with (so far, I've only seen 3 games uses this XDK, including Smashing Drive and Slam Tennis) since it's basically the same as 4361.

"What's with all the texture bugs?" Good question... until I actually get the game, I can't really answer that. My guess is that the textures are being registered in the wrong formats (luminance, maybe?) or maybe it's a driver issue. Who knows. So when I get it, I'll see what I can do.

Unfortunately, my internet time has been reduced to little or none on a given day. I miss having control in life! Meh, could be worse...

Shogun.

Pixel Shader 1.3 support.

2010-09-26T19:34:00.000-07:00

This is something I've been meaning to write for a long time, but never got around to it. The lay off is hitting me rather hard and I no longer have the net at my house. This is bad, but not enough to stop me completely.

So, what about pixel shader support? Well, Cxbx has gone too long without it for starters. Second, i didn't write it. This the work of kingofc! "What? Kingofc is back?". I wish... but defiance managed to get ahold of him and passed on his work to us. I thought it would never happen, but it did!

"So, how does it work? Can I play game X now?". No. It just another improvement gfx wise. It's not perfect and causes more crashes on certain instances. Since I'm runnin XP, the exception handler doesn't always report crashes properly (just exits). So until I can install Win7 on this laptop (painfully hard!) that won't work properly.

Since I'm on my iPhone, I don't have much time to post, but I want to leave you with one more thing. It turns out that Cxbx does run better on Vista than on XP. I haven't had the liberty of trying Win7 because i can't get the stupid thing to install (stupid ACPI bios thing). Example: Azurik absolutely refuses tonrun on XP and so far only works on Vista. I hate Vista.

So here's a small update for you. Hoping to have more soon.

Shogun.

Random update(s)

2010-07-17T18:27:00.001-07:00

Well, I'd feel really bad if I didn't update this blog with something! =) So I thought I'd at least do a few quick things for Cxbx. Since it's on my resume, keeping it updated would help.

Even though the above screens aren't all to impressive, those two games have been driving me crazy as of late and getting it to do something is better than what it was doing before. Which leads me to another thing I wanted to bring up. Patrickvl and defiance have been talking about fixing how we emulate Critical Sections in Cxbx. So far, it appears to be a rather big problem for this emulator. Patrickvl did manage to fix a few things with Enter/LeaveCriticalSection() (hence the reason Dxbx does a better job of emulating Rayman Arena right now) and if I can get in touch with him and discuss how he fixed it, then we will see a lot more games working on Cxbx. Since I'm a noob to how critical sections work (I've never used that feature before), I'll have to further educate myself on the subject just in case I have to figure this out on my own. After taking a look myself, the big thing is that it just appears that the main problem is that the structures differ from the Xbox to the PC version. This is bad, but either way, it should be emulated correctly. For now, I guess I could just keep track of each critical section created (just like how Cxbx keeps track of every IDirectSoundBuffer* pointer created) and just save the valid params for each critical section. If this works, then it should solve problems with various games such as Blood Wake, Rayman Arena, Taz: Wanted and Zapper and possibly more. I'm assuming this will work, until I try it tonight, we'll see.

As of late, I've noticed that we've had some rather "problematic" kernel functions preventing numerous games from working correctly. One of the most notorious of those functions is NtQueryFileAttributes. Instead of dealing with that pain-in-the-ass-to-emulate function, instead I created a signature and emulated it on a higher level using the native GetFileAttributesA() function. I did this when working games such as Dues Ex and Hunter the Reckoning and it worked like a charm.

"Why haven't you updated the SVN yet if you've done all this and more?" Good question. That's because I have a bit of bad news. First of all, I was tracking down some bad DirectSound signatures for XDK 3911 when working on Blood Wake. I commented those out and was planning on fixing them later (not really a problem to fix actually), but upon doing that, I broke Halo. I assume most of you don't care about that, but it does get worse. My latest build broke Turok! Why? I don't know yet. All I know is that there's NULL surface causing the crash. I can add sanity checks to get around that, but not sure if it's a major problem. My debugging skills really suck, and so far I've been relying on other team members to help me debug stuff. That needs to change, and fast!

One more thing, I know that you guys want to play games like Conker, Midtown Madness 3, Unreal Championship II, and other games using the D3D8LTCG library. Well, I have some more bad news for you. When I was working on adding further support for this library, I did get some of the XDK samples built under the LTCG release to work, however, the code inside these functions are dynamic, NOT static like with normal D3D8 library builds. What does this mean? It means that even though one signature might work for one app/game, it's not guaranteed to work for the next as the code and signature would change per game. Furthermore, there is no standard way to dissassemble the library in IDA or use our automated tools to locate the functions. So with that being said, Cxbx CANNOT emulate these games using the method it uses now. The only way to do so is to actually create an HLE datasheet that manually specifies the location of each function similar to how Xeon works. This is really a lot of work to do since most games require many functions to be HLEd and finding them all manually can take months (unless we had a dedicated team to search them out). Now I see what Nisse was talking about =/

So, that's all I wanted to share tonight. In the mean time, I can still add a few updates here and there. Just know that I'm not completely off of this project for any reason! =)

Shogun.

Laid off

2010-07-09T10:30:00.000-07:00

Yup, that's right. As of today, I am officially laid off. Of course, the bad news is self explanatory, but just so you all know, what little time I was allocating for Cxbx is now gone again! Damn you economy! Oh well, I'm too old to throw a tantrum over it and quite frankly, not only am I used to this, but I saw it coming anyway. Now it's time to go back to my old job... and that is looking for one (which I sincerely f@#%ing hate with a passion because it's painfully hard).

"Is Cxbx dead, then?" No! And STOP f@#%ing asking me that!!!! If I've said it once, I've said it a million times... it's NOT over until I say it is! *sigh*, sorry, I just get tired of n00bs asking this everytime I go for at least 1 month without updating Cxbx.

But while I'm at it, I want to ask you all a favour. Please tell me what games are giving you the following error "EmuD3DDeferredRender/TextureState was not found!", okay? I can pop in here and there and see if I can fix games that give us this error (as long as the game doesn't use the D3D8LTCG library (check your Xbe dump); I'm not interested in those games atm). That being said, you now officially have a reason to bug me :)

So, that's all for now. In the future, I'll see what else I can do from time to time.

Shogun.

Cxbx svn r163

2010-06-21T13:55:00.000-07:00

Yup, just in case you haven't seen it already, it's there! I just wanted to make a breif update about yet another breif update I made to the SVN. Many of you noticed that Panzer stopped working with r162. Well, I fixed that last week and now you can all fool around with Panzer again if you feel like it.

"Speaking of Panzer, how's that going?" Better than before actually. There's another contributor who managed to fix some issues with it a while ago. So far, there's still more to fix, but it's leading up to some very interesting bug fixes. With the right hack, speed will be closer to that of playable, and when we fix the problem with EmuIDirect3DDevice8_SetRenderTarget, it should work properly. The problem is that Cxbx likes to resize textures and render targets to it's liking and if the sizes are not compatible with the screen resolution, SetRenderTarget fails. Sounds easy to fix, but we'll look into it. If it works, then no more fullscreen quad overlapping the 3D scene because everything will be rendered on top of that! If _SF_ (Xeon) can do this, so can we!

Just thought I'd do a quick update. I'm still rather busy and trying to move into a new place closer to my job. Once that happens, I'll have more time for Cxbx. Until then....

Shogun.

Going to be busy for a while.

2010-05-13T21:04:00.000-07:00

Okay, before I start getting numerous messages about my inactivity, I'll spare you the suspense of wondering what's going on. First of all, I finally have a new job. Blueshogun now works at Microsoft (the enemy, lol). After all this time applying, I finally got it. It's a rather rewarding career (although the project management isn't 100% stable) and I really take pride in what I am doing here. So in short, I won't really have time for Cxbx for quite a while.

"What are you going to be doing at Microsoft?" Quite frankly, that is classified information, so I can't spread that information around, plus I don't want everyone nagging me with silly requests anyway. Yes, it's Xbox 360 related, but that's more than enough information given there. If you're aware of what's going on in the Xbox 360's new line up of new features, chances are you know what I'm doing.

"So, how come you won't have time for Cxbx? Is Microsoft working you overtime?" No, that's not it. My biggest issue is my commute. Since I'm really far away from Microsoft's location and I don't own a vehicle, I have to use public transportation. After traveling over 40 miles and transferring from 3 buses a day for both ways, my daily commute to and from work is 3 hours! So working 8 hours a day, plus 6 hours of commuting time, that's 14 hours a day I'm out of the house! I work only on weekdays, but I need to dedicate those available weekends to take care of important business IRL. "Why don't you move closer to your job?" That's the plan, but I have to find an affordable and suitable place to move into first. The Seattle area in general is not a cheap place to live, and when you think you find a good deal on apartments, you have to really look into it because sometimes it will come back and bite you in the @$$. Having said that, even more of my time is spent looking for a new place to live. Trust me, I didn't choose to live where I am now, and I don't plan on making the same mistake twice. Catch my drift?

So yeah, that's what's going on right now. I have lots of work ahead of me and I don't know when I'll be readily available to work on Cxbx again. Right now, I have to worry about my financial future and get that straight before I can worry about things like this right now. Hopefully, you understand. Thanks for supporting me all these years!

Shogun.

The race for 64-bit support is on!

2010-05-03T11:13:00.000-07:00

Over in the NGemu forums (here) we have a new dev named tabai working on 64-bit support! So far, it's looking pretty good, but clearly, there is one bug to be fixed. Since I never did understand how FS and LDT worked on Cxbx, I'm sure that I could learn a thing or two from his work.

I attempted to fix the 64-bit issue myself, but I never could figure it out. The work that is being done is originally based off of the original fix from Robert Yates. I won't say too much about him as I'd prefer to keep his career details and contact information confidential, but tabai has been continuing to add on to his work so that both Debug and Release builds are supported. I don't have a 64-bit machine available to test this on (my 64-bit OS desktop is still in Indiana unfortunately) so I'll just have to take his word for it. He has posted his changes in EmuFS.cpp/h and I do plan to add that to my SVN once everything is sorted out. Hopefully we can have this fix working for both 32-bit and 64-bit OSes.

Just keeping everyone up-to-date on what's going on with this issue as more and more users are complaining about it :)

Shogun.

Kabuki Warriors

2010-04-25T15:27:00.000-07:00

Okay, before I go any further, I'd like to apologize to everyone who feels that I have been unnecessarily angry as of late. I've just been under a lot of stress lately IRL and it's been driving me crazy! Getting a job in the US these days is really hard (be it IT or even McDonalds), especially when you're still in the entry level stages. I've been without a full time job since September of last year and getting a job at this point (anything) is very important. So if I offended anyone, I'm sorry :(

As you can see, the game Kabuki Warriors (XDK 3911) is reaching menus so far(ingame is not confirmed yet, and I'll explain that shortly). I had a very positive feeling that this game would have some level of compatibility with Cxbx for some reason (lately, my emulation instincts have proven quite accurate). It looks like all my work on XDK 3911 is paying off, big time! Still have lots of work to do on this particular XDK by fixing the ordering of Deferred Render/Texture States, but that will be an easy fix once I get around to it. TBH, so far, I didn't add anything in particular to get this game showing stuff. All the stuff I added for Azurik and Halo must have been enough to get it this far.

"So, what's the problem?" Truth is, I don't really know what's causing problems. Upon trying to go ingame, conflicts with my display adapter on a driver level occur. I'm assuming that a certain Direct3D function is causing this. What sucks is that DirectX 8.1 is greatly depreciated and it's not easy to debug. I'm convinced that if we were using at least Direct3D9 or OpenGL, this would not really be an issue. The best thing I can think of is to find out if any functions are returning a specific error code (D3DERR_DRIVERINTERNALERROR). It would be nice if I had my other machines to test this on, but sadly my laptop is the only available computer capable of running Cxbx in this household. However, I do hear some background music and voices upon trying to get ingame. Right now, I can't actively work on finding this problem, and tomorrow I have another interview. Hopefully I get this job because it will really help me and my sister through these tough times (and maybe a lucky/unsuspecting British lady; and no, she's not my girlfriend ^^).

"Okay Shogun. What's the deal with emulating all these crappy games?? I want to play DOA3, JSRF, Ninja Gaiden and Otogi!" Okay, calm down! Don't you think I work on those games too? Let's look at it this way. It's rather common to have an easier time emulating a crappy game then a top notch game. Not saying Turok, Futurama, Smashing Drive and Robotech: Battlecry are bad games (well, some of you might not like them), it all depends on how the game was programmed. Crappier games tend to use more generic and uniform coding methods than the more popular ones. Not saying the programmers of these games didn't do a good job of programming these games though, but sometimes programmers will try to take shortcuts by using code already contained in the XDK samples. Emulating XDK samples with Cxbx has been the most effective method of improving it, so a game like Petit Copter (which is almost totally based off of the TechCertDemo in the XDK) will naturally be easier to emulate. That's just the way it is. But look on the bright side, getting crappy games like Kabuki Warriors working will increase your chances of playing a better game such as DOA3 (which is still bugging the hell out of me with it's multi-threading issues).

Side note: I own this game, but never actually got around to playing it for myself. I heard that this game got some really bad reviews and some claimed it to be one of the worst Xbox games out there, but I won't make that kind of judgement until I play it. I won't discourage anyone for trying this game themselves, but get a load of this quote below:

"I literally won a match just bashing the controller against my ass. I wish I was joking, but the score is seriously Kabuki Warriors zero, my ass one." - Andy McNamara (Game Informer)

I'd really like to say more, but I need to get ready for tomorrow. So thanks for checking out my blog and wishing me well on this project.

Shogun.

Cxbx compat list is over 30 now!

2010-04-18T11:28:00.000-07:00

Blade II video

Wow, the progress just keeps on coming! If you look at the compatibility list, you'll see that the games list is now over 30! That's been my target for quite some time now.

Thanks to some "unofficial" beta testing done by BlackDaemon, two more games are proven to show some stuff. None of which are playable or in-game, but since I never had a chance to try these for myself, now I know that there's a chance for fixing these games for the future. I do have Blade II (XDK 4627) but I don't have Burnout (XDK 4361). Since I have those XDKs, fixing the two doesn't sound hard initially, but like I always say... No guarantees! Don't have much to say right now (busy), just keeping you all updated :)

Shogun.

SVN Revision 159

2010-04-16T20:45:00.000-07:00

Yup, it's here. The SVN is finally updated. Thanks to cmccmc for teaching me how to use TSVN [properly], I can now just right click the folder and update any files necessary. All is new, and sorry it took so long. It was a pain in the butt trying to find out myself. I guess my IQ is getting lower... *sigh* I have myself to blame, but oh well.

Yes, it plays Robotech: Battlecry and should play everything else on the list. Please note that some games are NOT guaranteed to work for everyone (this is especially true for Panzer if you're brave enough to try it). If you want, feel free to post your concerns here or on the forums.

Now that I know how to use TSVN better, I'll keep it updated more often. Promise. Happy?

Shogun

Robotech: Battlecry is playable!

2010-04-12T13:14:00.000-07:00

Wow, I've been making quite a bit of progress over the past few days lately! Interesting how all this fell into place over the weekend. Taking a break from Cxbx can do wonders. When I do come back from taking a break, I usually make new discoveries and fix lots of bugs.

As the title says, Robotech: Battlecry (XDK 4721) is now considered playable (but with an asterisk). "What's the asterisk for?" Last night, me and Defiance have been putting our heads together fixing some bugs in Cxbx. We did manage to fix quite a few things (mainly PushBuffer related stuff which fixed a few bugs in Panzer as well and got proper bilinear filtering in XDK 3911). The biggest thing was changing how Cxbx reacted to a certain scenario. It doesn't look like a proper fix, but it worked. At first, it was only working for Defiance for some reason. Initially, I assumed it was another problem relating to Vista and XP again (where XP is more tolerant of the situation). I just fixed that a few minutes ago, and now it appears to be completely playable. Be advized, it does have bugs.

The biggest issue is that the skydome doesn't render, so when looking to the sky, it starts trailing. This only happens when you start playing though. During a cutscene or when the game is paused, it works fine. Why that is, I really don't know. Also, I myself am having some speed issues with my laptop. I'm running an HP dv2700 (not HP's greatest model, many were faulty and had a recall). It's a nice laptop and does pretty well, but for some reason, it likes to slow down randomly for about 30 seconds, then go normal speed again. On average, I get 20 fps ingame and generally runs smoothly. Since quad rendering and EmuIDirect3DDevice8_DrawIndexedVertices aren't very fast atm, you can expect this game to have a few speed issues. Other than that, the game is playable. I played a few levels myself and haven't had any major issues or crashes at all.

So, that's my update for today. Stay tuned for more updates as they surface.

Shogun.

Azurik: Rize of Perathia In-game!

2010-04-10T23:40:00.001-07:00

I never thought I'd say this, but Cxbx is finally going in-game with my favourite Xbox game, Azurik: Rize of Perathia! There are numerous reasons why I doubted this would happen, but read on to find out. These screens shows the result of going in-game. Looks pretty bad, but it's major progress considering that this game uses XDK 3911. There's lots of technical things to discuss about this update and it's going to take a while to explain it all; so grab a snack if you're going to read this update.

Just so you all know, I've been working on Cxbx for YEARS trying to get this game to do something. Why this game of all others? Well, not only is it my favourite Xbox game, but there are alot of unique features in this game that I would like to see emulated, and hopefully pave the way for more games to become playable. You may be thinking that since the graphics didn't look as good as Halo's or even Panzer's, that this game would be easier to emulate. No, that's definitely not true for this game. Let's look at it this way. Have you ever tried to play this on Xbox360 using it's backwards compatibility emulator? Didn't work, did it? The Microsoft devs never could get this game working to save their lives! Yup, that's right. An amateur programmer like me out performed the entire Microsoft Xbox 360 team! That means, if they can't do it, then there's really something about this game that makes it worth emulating. Not just to walk around and boast, but to benefit Cxbx as a whole. We still have a long way to go emulating this game, but Cxbx is making progress on games that Microsoft couldn't emulate... and they have the official hardware documentation! Why is that?

Overall, I had to add quite a bit of stuff to get this working as far as it does. Thank God for Caustik's [indirect] input, or else I'd never have gotten this far! When I first fired up Cxbx and tried to run this game, got a crash, as usual. Since I didn't have that XDK back then, I tried doing some dirty hacks instead of solving the problem. Yeah, I was rather lazy back then! Needless to say, that didn't work. The biggest thing that bothered me was the vertex shaders. The vertex shader declaration was large, but the vertex shader would always be empty! The only thing we had to go by was the "vs.1.1" header of the vertex shader, so I had to check for this scenario each time a vertex shader was being parsed. Since Azurik uses non-routine shader usage methods, we're going to have to use the vertex declaration to create a fixed pipeline shader. Yeah, that sounds very contradictory, but this is how you create vertex shaders without the use of any assembly shader code (which Cxbx still uses). The idea didn't occur to me until a few minutes ago, lol.

If you're going to try this for yourself, then I highly renaming or recommend putting and extra char somewhere in the name of the movies folder. Cxbx will play Azurik's movies (not perfectly), but for me, the videos will randomly cause Cxbx to freeze. If you do rename the folder, then upon loading Azurik, you will be automatically taken to the menu screen where you are asked to create a new game. Then, you know what to do :) "Why do the videos cause problems with Azurik?" TBH, I don't know. I tried using Vertek's idea of using the progressive flag in IDirect3DDevice8_GetDisplayFieldStatus, but that will cause Azurik to do nothing but show a black screen. IMO, I think it's related to threading issues. Cxbx has been having alot of problems dealing with threads lately (especially Halo and Panzer) so I think this is one of those instances.

"Okay, that's interesting... but why are the graphics so distorted?" That's a good question. Before I get to that, let me tell you something interesting about this game. Azurik's polygon counts can reach over 300,000 primitives per frame. Trust me, for an Xbox1 game, that is alot (yes, more than Halo). And yet, it still maintains a steady frame rate of 30 fps. Using your standard Draw[Indexed]Primitive/Vertices[UP] API calls weren't going to get you 30 fps rendering this many polygons, trust me on this. Instead, Adrenium (the company that made Azurik) decided to use PushBuffers instead. The PushBuffer (exposed by the IDirect3DPushBuffer8 interface exclusive to Xbox) was designed to take full advantage of the Xbox GPU (NV2A) hardware. All NV1x GPUs and later support PushBuffers internally (can't say for the Gxx series because I haven't looked into it yet) and the IDirect3DPushBuffer8 can be used to directly program the GPU. Cxbx does emulate PushBuffers (which requires a bit of low level emulation), but so far only Turok seems to have correct PushBuffer emulation (most of the time). Games such as Panzer also use it. I don't know what's required to fix the PushBuffer emulation for this game, but quite frankly, I've never actually used a PushBuffer myself, so now would be a good time to learn! When I get time, I'll write some code examples using PushBuffers and test them against my debug Xbox and Cxbx to make sure I get it right. It's going to be tough fixing the Gfx for this game, but someone's gotta do it!

Aside from that, there's another really annoying thing about this game... the pixel shaders! Okay, why would any professional programmer create a new pixel shader and release it each frame? What sense does that make? From what I was taught, that's bad programming practice! Maybe Adrenium had a good reason for it, but I sure can't think of any. I ended up disabling the code I used to dump the pixel shader definition each time a new pixel shader is created because I'd end up with 8,000 text files containing the same pixel shader in less than a minute! Cxbx already defaults to the basic passthrough shader anyway since pixel shaders aren't yet supported. Not that it's a major problem, but it's annoying!

So I think that it's safe to say that Azurik has undoubtedly the worst bugs I've ever seen in Cxbx; absolutely horrendus. In fact, it's worst than every partially/fully game functional with Cxbx combined, and the speed issues are much worse than Panzers (and Panzer is S-L-O-W). This game is definitely going to keep me busy for a while. It's bad enough that the problems Cxbx has with XDK 3911 are hard enough to fix and I knew that emulating this was going to be painfully hard, but wow, I never dreamed things would get this tough! Oh well, time to stop complaining. Things can't always be easy, can they? Beating the game was hard enough, now let's try fixing it. Wish me well everyone!

Shogun!

Random update

2010-04-10T12:44:00.000-07:00

Yup, that's right. I feel like working on Halo right now. Don't like it? Then GTFO! lol, just joking. But on a serious note, I'm sure I'm going to get multiple "wtf"s for multiple reasons. I'll answer your wtf's later. Just trying to piece together an update since I haven't been doing it very often!

It's been a while since I've done any major updates to Cxbx (and I still haven't), but today I wanted to take some time off more serious things and work with Cxbx for a while. Right now, I'm mainly dealing with issues related to games using XDK 3911 (Azurik and Halo in particular) because this XDK internally operates very differently then all other XDKs released after it. Remember playing Halo on Xeon? Ever noticed how bilinear filtering was never present, alpha blending in the wrong places and the walls weren't visible? That's because the Deferred Render/Texture States are in a completely different order than the other XDKs! I found this out when I first tested the code examples for 3911 and noticed that certain render/texture states wouldn't work, and that the wrong ones were being set. I fixed most of this in Cxbx already, and if Xeon was open source, I could fix it there too. Why didn't _SF_ figure this out? Because he never had XDK 3911 to begin with. He was using XDK 4627 to find similarities, and did a good job of it. Still, anyone could have missed this.

"Hold on a sec, why does Halo look orange?" Good question. I don't know. Besides, I thought Halo's old orange UI looked cooler than the blue one (E3 2000, anyone?). Well, don't be surprised. With every new release of Halo (or new major build), there's always something with Halo that causes the menus to look more and more distorted. At one point, you could actually make sense of what was going on. Now you can't, really.

"Why are you working on Halo anyway? There's already a PC port, why not play that instead?" Okay, this gets really old after a few years. First of all, Cxbx is not intended to replace an Xbox or be a substitute for any PC version of any game available. I don't work on Cxbx so all the warez monkeys can play their favourite pirated games either. My motives for working on Cxbx is to further advance the current state of Xbox emulation as a whole and learn a trick or two about how Xbox works and about Direct3D in general. So please, don't tell me what I can and can't emulate. Yeah, it nice to be able to play your favourite games on an emulator when you can't use your console, but remember this... each time another game becomes playable, it increases your chances of being able to play your favourite game in the next release! Besides, I like the idea of playing Halo's Co-op campaign on my laptop with a friend. Isn't that something to look forward to?

"What about the ring? Does that actually render?" Actually, it does. You'll have to put Cxbx in wireframe mode to see it though. I think it's covered up by stuff again.

Defiance and I have been putting our heads together a bit today. Not sure if he'll have time to work on Cxbx for a while, but he's still around. For any of you who actually got Cxbx to successfully get Halo into the menus and tried to start a new game, you might have been greeted with a nasty grey/white screen that sits there forever. Well, I actually got passed that today. From the looks of things, it appears that it might have actually been going towards the ingame status. Too bad I had gotten a fatal error message ruining the whole thing! My debugging information was off, so maybe I can fix it. The biggest problem with Halo is that there are tons of bugs related to this game. Might be Vista related, but it's too early to tell. So getting to that point is all a matter of chance. Sometimes a crash happens, sometimes not. Totally unpredictable.

There, an update. I never thought I'd make so many users sad by taking some time off :) Maybe I should just take time off every other week instead so no one starts complaining :)

Shogun.

Robotech: Battlecry video

2010-04-08T14:50:00.000-07:00

Yup, I finally got around to making a video of Cxbx running Robotech: Battlecry. Like I said before, Fraps refuses to record it properly, so I had to use CamStudio. I might eventually use another tool, but for now, it works fine. Oh and sound wise, you aren't missing anything.

"So, care to explain what's going on with the graphics?" Hold on, I'm getting to that!

Textures: The issue with the textures I'm assuming is the same as what previously happened with Panzer. Probably a swizzling issue. More than likely, there's a certain swizzled texture format that isn't being unswizzled properly. I never had to deal with texture swizzling issues before. Caustik usually does that. What I need to do is create test scenarios for each and every texture format Xbox supports to be sure that we get it right. Speaking of textures, remind me to implement cube textures for MetalArms, okay?
3D enviromnemts: If you look at the 3D environments, you'll notice how the polygons are poorly shaded. Why exactly this is, I don't know. There are two possible explanations. The first one comes from the fact that this game uses quad lists via index primitives to render gfx (D3DPT_QUADLIST). "What's so hard about that?" For starters, quads are not a native feature of standard Direct3D (Xbox Direct3D does, because it's designed to take advantage of the NV2x GPU, which is more OpenGL compatible). So in that case, we need to create triangles from quad vertex data. It's harder than it sounds. The other reason may be shader related, but that I can't confirm. Cxbx's vertex shader parsing is not perfected.
Frame rates: This game will likely take more processing power to run than most other games atm. Martin_sw said that DrawIndexedVertices[UP] needs further optimization. Probably does (and that would explain part of Panzer's speed problem). My guess that the extra work to deal with the quad format polygons makes it worse. So that one mech on the menu reduces my frame rates to 49 on average, and in game gfx are generally 30 fps. When the OpenGL port is done, it should be faster (I hope).

So yeah, that's basically all I have to say. Still busy battling for a spot on Microsoft's payroll, but if anything pulls through, I might have less time to dedicate to Cxbx, but rest assured, it's not dead until I say it is, got it?

Shogun.

Unreal Championship video

2010-04-02T21:52:00.000-07:00

Just posting another video I made...

I haven't been able to do it with fraps, so I used CamStudio. Sorry for the lack of sound, but I feel I should post something so that you all know that Cxbx isn't dead. So this is Unreal in action. If you want to know more about Unreal Championship's status, read my previous posts regarding this game for Cxbx.

For those of you that want to see a Robotech: Battlecry video, you'll have to wait until sometime next week as I won't be able to do it. My dump of this game is on my other USB HDD and I don't think I'll have the time to dig it up this weekend.

Shogun.

New Panzer video

2010-03-30T19:42:00.000-07:00

I forgot to put this on youtube but, but oh well. What's so great about it? This video actually shows solid 3D ingame gfx of Panzer. The fullscreen quad still covers up the 3D scene from time to time, but at least you can see what's going on for a while. What's the difference between this build and other build featured in the old video? This video was taken in Release mode [from visual studio] rather than Debug. It turns out that Release builds are more stable and less buggy when running Panzer Dragoon ORTA and Robotech: Battlecry. Both games had similar problems. Speed is still an issue, and me and Defiance have tracked it down to the PushBuffer emulation (IDirect3DPushBuffer8, Xbox only). The problem is that it uses a combination of Indexed Geometry and Quad Lists (D3DPT_QUADLIST, Xbox only) and that appears not to have been perfected in push buffers.

Robotech: Battlecry, however, did not use push buffers but did use the same types of primitives using indexed geometry. Defiance fixed that (for the most part). Okay, getting slightly off-topic, but the two games are related though. I'll try to make a video of that soon. Fraps can't record it properly, so I'm using another tool to do so.

So while it's not really news, it's a slight improvement that I want you all to be aware of.

Shogun.

Excuses, excuses.

2010-03-24T10:31:00.000-07:00

First of all, I'd like to say sorry since it's been so long since my last update. You're all probably wondering what's going on. I'll get to that right now so no one is left in the dark.

1. Q: Where have you been all this time?

A: As it has already been stated, I'm really busy IRL and there's lots of work to be done. I'm doing okay, but I've been better. If all goes well, I'll be getting a new job soon (an IT job, finally). How it's going to effect my work on Cxbx is unknown; either way, I want to let you know that whatever happens, it's not over until I say it is, got it? It's only been 2 months so far. Cxbx and other emulators have gone much longer without updates before, remember that.

2. Q: Where's our release?

A: Good question. I emailed my release to Caustik before hoping that he'd release it on the homepage, but he's already busy enough as it is going through some rough transitions. "Why not release it here?" That's not my call. I'm just "The co-author", remember?

3. Q: Is there anyone else still working on Cxbx while you're away?

A: Yes, a fairly new programmer, Verteks is working on Cxbx's D3D8LTCG support for XDK 5849. It's preliminary, and will take a long time to complete, but it's worth waiting for once it finally works. It's tougher to create signatures for this library as it is not directly compatible with IDA, so it will take some time to get things working with it. "What about defiance?" Lately, he's been busy too. I don't know what his details are, but he's made some good progress fixing bugs and advancing towards Direct3D9 support.

4. Q: What about the OpenGL port?

A: That's only partially implemented right now. When it's done, you'll know! Just be prepared with a card with decent OpenGL drivers as it might be using OpenGL 2.x instead of 1.5 as originally planned.

5. Q: When are you going to update the SVN?

A: Good question. The reason I haven't yet is because I really hate having to delete the entire SVN and then re-upload it and missing out on the changes for everyone to see. It takes longer and is much more work. TSVN solves this problem, but I need to take some time to figure out how to syncronize my dev folder with TSVN so I can update the SVN each and every time I make an update automatically. If anyone knows how to do this, let me know.

6. Q: What about x86-64 support?

A: I don't remember if I answered that before or not on my blog. The status of this remains the same. Unfortunately, it still doesn't work. Afaik, it can be done, but quite frankly you're asking the wrong person for this type of update. Since I didn't write the LDT code for this emulator, it's the hardest part for me to understand. A Sony employee claimed to get it working and even left us with his source code to do it. I added it, but didn't get it working due to the fact that I didn't know how it was implemented. Caustik says he can do a workaround eventually, but in that case we might be waiting a while longer.

So there you have it. I'd like to work on Cxbx right now, but I still have lots to prepare for in terms of pursuing a new job, place to stay, and hopefully a vehicle (and more that I'll share with you all at a later time). Until then, stay tuned.

Shogun.

More progress on Robotech: Battlecry.

2010-02-05T17:15:00.000-08:00

Thanks to defiance for finding the bug causing the problems with Robotech: Battlecry's 3D geometry, we now have some much better screenshots of the game! So now it looks alot better. My initial idea for fixing this was totally off! It's a good thing defiance fixed it before I did!

"So, is this game playable now?" Unfortunately, no. There's still more bugs to sort out here, and when it's fixed, I'll let you all know. Other than that, there appears to be issues with texture swizzling. No big deal for now. So I just wanted to let you all know how well Cxbx is doing.

"Nice progress, but enough stalling! When are you going to release it?" It's up to sir Caustik to release it on the website. I sent him my releases earlier this week and hopefully you'll see them on the homepage this weekend. So check the homepage and this blog periodically.

Shogun.

No more Xbox Live for Xbox1 games (sad)

2010-02-05T16:12:00.000-08:00

http://www.qj.net/qjnet/xbox-360/microsoft-pulling-the-plug-on-original-xbox-games-on-live.html

According to the source below, Microsoft has chosen to discontinue Xbox live support for Xbox1 games. This is a sad day for those of us who like to play Xbox1 games on live (or download content for it). While I do agree that Microsoft should look forward to the future and focus on the present, I don't think that it would hurt Microsoft to maintain a separate server for Xbox1 games. Microsoft probably has a good reason for this, but I doubt that it's really good enough. So in the meantime, when I get a chance, I'm going to try and save my downloaded content on my PC using my Debug Xbox if possible. I don't want to lose my Unreal Championship content or the patches I downloaded (because it improves the game's frame rates and gameplay experience). If you can, I'd encourage you to do the same.

"So, what does this have to do with Cxbx?" Not much, but it means that I guess we can forget ever seeing the day that Cxbx will ever access it. This is one reason why I've been working on Unreal Championship so much; to see if we could one day connect to Xbox live. If Xbox live dies, we could probably create some sort of way of faking it for Cxbx and a real Xbox using our own server(s). Not sure how much work that would require, but we'll see once we get an Xbox Live compatible game playable.

I love Xbox1, but I hate Xbox 360. It can never replace my favourite console (of this century).... RIP Xbox Live...

(November 2002 - April 2010)

Shogun.

More on Petit Copter (Ingame)

2010-01-30T15:07:00.000-08:00

Okay, last night I was curious as to why Petit Copter kept crashing the way it does. I initially thought it was DirectSound related, but it turns out that it was really a problem with our implementation of EmuIDirect3DDevice8_SetRenderTarget. The fix was so easy, I wanted to slap myself! After that it went ingame.

After going ingame, it turns out that the game is more complex than I thought in some ways. It turns out that the game does actually use vertex shaders! Although that's not really a problem as Petit Copter's vertex shaders were really simple to convert. When I first got Petit Copter ingame, I noticed that the only thing I could see was the helicopter's rotor. This was because Cxbx compensates for the Xbox's ability to use negative numbers to identify vertex shader constants (c-96 to c96), so Cxbx adds 96 to the vertex shader constant ID of each shader instruction to fix that. This caused bugs in games using XDK 4361 and earlier (so far) and caused 3D not to render. So what I did was add 96 in EmuIDirect3DDevice8_SetVertexShaderConstant and everything that used vertex shaders in XDK 3911 - 4361 worked fine. It's a dirty hack and I'm not sure if it's a good idea to leave it there, but oh well, time will tell.

"So, how well does it run in game?" Well, everything is smooth ingame. No framerate issues as the graphics are really simple. "If everything is smooth, why can't it be considered playable yet?" Good question. There's another bug somewhere, and I can't figure out what it is. So far, it's exclusive to this game. There's a stack corruption problem in this game (might be the generated exe or CxbxKrnl.dll causing it) and it's really hard to track! If I can fix that, then the game will be considered playable. The bug is completely random. Sometimes you'll get a crash immediately, other times it won't show up for about 30 seconds if you're lucky. So if you want, watch the youtube video (link below).

Cxbx WIP: Petit Copter [Part 2] (Ingame)

Hope you enjoy it.

Shogun.

XDK 3911: Random stuff...

2010-01-24T16:19:00.000-08:00

Me and our newest programmer (Defiance) have been investigating problems with games and other apps using XDK 3911. It looks like the problems we face with games using this XDK are much bigger than we originally thought. Below is a list of problems I've been able to dig up and how I have addressed or how I plan to address them.

1. The biggest thing so far is the lack of accurate deferred render state emulation. Ever had that EmuD3DDeferredRenderState not found error? Yeah, it has to do with that (sort of). Now that I have 3911 XDK samples to test with, troubleshooting issues with this particular XDK will be much easier. I was testing the basic tutorial examples as they are easy to debug with Cxbx, and noticed that the texture in the Texture tutorial was black! I had assumed that there was a problem with texture loading (there is, but not with this sample), but it turns out that the deferred render states were not being set properly. The example explicitly disables lighting (Direct3D enables it by default), but it wasn't doing it. I disabled lighting manually and it worked. For XDK 3911, instead of directly changing the deferred render states table directly, it calls a function to handle it (D3DDevice_SetRenderState_Deferred), and this function only exists in XDK 3911 and earlier so far. Because of this, Cxbx gets the location of D3D__RenderState (EmuD3DDeferredRenderState) then reads and updates deferred render states until the next draw call. To find it, what Cxbx does is calculate the location of the deferred render state pointer by locating IDirect3DDevice8_SetRenderState_CullMode and then calculating the offset from that function to the list of deferred render states. It appears to work fine for every XDK we support so far except 3911. Since I don't yet understand how Cxbx calculates the offsets, I'll have to use a more hacky method of correctly emulating the deferred render states. This means HLEing IDirect3DDevice8_SetRenderState_Deferred itself. Even though that the render states are supposed to be deferred, I'll set them on the fly and write code to defer them later. It's possible I might have to do the same for the deferred texture states as well (I hope not), but this will diagnose MANY problems you are having with any games released around November 2001 (yes, that means DOA3 and Oddworld). When the deferred render state location code is correct, I'll remove this function as emulating it will no longer be necessary.

2. There is yet another problem plaguing 3911 games. There appears to be a problem related to loading textures with a specific D3DX texture loading function. This is stopping many 3911 games from working (Star Wars: Obi-Wan, Fusion Frenzy, and many more). I haven't had a chance to debug this extensively, but the problem is known and will be addressed hopefully soon.

3. As much as I hate to say this, there's a chance you might be experiencing more "X-Ref only" errors with 3911 titles. Why? Because for DSound, I've added a new X-Ref that will help me quickly identify and fix missing DSound APIs, DirectSoundEnterCriticalSection. AFAIK, this is called in every Xbox DirectSound API. There are some missing DirectSound functions that can be executed by Cxbx and not crash leading to further problems. So when a DirectSound function call is missed, I can easily find out what it is thanks to the breakpoint that I placed before the message is displayed. Yes it will get annoying as heck, but it's for your benefit!

4. One more thing, I finally got around to adding the XGRAPHC library support for 3911. I'm surprised no one did it before o_O. I added every XG function that Cxbx emulates (except for one), so that will fix alot of problems right there.

I wanted to say more, but I can't remember what else I was going to say, lol. So I just wanted to let you all know what I've been up to lately. So stick around, and see what I have in store for you all.... hahahahahahahaha!

Shogun.

Alter Echo

2010-01-22T08:51:00.000-08:00

I forgot to post about this (as it happened 2 weeks ago). I'm a bit sleepy so I'll make it quick. I got the game Alter Echo (XDK 5233) to show some stuff. I don't know what's going on (I'm assuming it's a problem with palletized or swizzled texture formats). I'm assuming what happens is it shows a loading or some other intro screen and then shows a dirty disc error as it shows more gibberish after this and halts. I'll have to find out what it's doing later on. There's a chance that the hex values of a certain D3DFORMAT definition might have changed and Cxbx is trying to use the wrong texture format. Never did get around to fixing that. I'd like to say more, but I'm too busy and tired. Cheers.

Shogun.

General Heed was right, OpenAL "IS" a good idea.

2010-01-16T13:22:00.001-08:00

It's been a while, but I was working on Cxbx today adding some stuff for XDK 3911 so hopefully I can get you all to stop begging me for DOA3 (me and our newest dev, defiance, are trying to fix the problem with it). In the mean time, I was adding the necessary things to get Halo to work properly. I noticed that there was no implementation of IDirectSoundStream::SetPitch. Assuming that changing the pitch of a DirectSound buffer would be standard in DirectSound, but I was wrong! It's not part of the DirectSound API at all o_O!

After taking a quick look around the net and remembering what General Heed said, it looks like there is some functionality that would be quite useful in OpenAL. I also found out that it supports DSP effects too, but appears to be specific to certain Creative Sound Blaster cards (which I do not have). So later on, I'll be looking into OpenAL as an alternative to DirectSound (unless XAudio proves to be a better choice, but I doubt it now). So thanks for the suggestion General Heed. Listening to the people is a good idea!

Shogun.

Need to slow down a bit.

2010-01-06T15:17:00.000-08:00

First I want to say thanks for everyone encouraging me to make Cxbx greater and greater every day! For the past 4 days, I've been working on Cxbx non stop because sometimes I get a bit too excited and over do it. What I plan to do is not stop working on Cxbx, but slow it down a bit to a steady pace; such as dedicating a few hours a day for Cxbx while getting my other priorities done.

Either way, I do have a few things I want to share with you all. A combination of things I haven't told you all yet to things I plan on doing in the future.

We do have another person working diligently on Cxbx in his spare time. Even though he's just getting started, he's learning rather quickly and slowly but surely beginning to make progress. As details surface, I'll share them with you.
I'm adding another game to the list, Alter Echo (XDK 5233). I can't really tell what it's trying to do (8-bit textures are not fully supported yet). It's only classified as Intros at this point, but it's still progress.
Patrick got me a copy of the Flair SDK. This will greatly speed up Cxbx progress very much!
I finally figured out why Panzer and Robotech: Battlecry keep giving us crazy 3D graphics. The problem is that these games are using quads to render 3D geometry. I can understand why Panzer does this since it was once a Sega Saturn game (which used 3D quads for rendering) so that would make things easier for the developers to use the Xbox's ability to render 3D quads. While standard PC Direct3D does not support this, OpenGL does [natively]. Another reason why I'm porting to OpenGL.
Speaking of OpenGL, I'm going to start the port really soon. The next release will likely not use OpenGL, but after the next release, releases should be much more frequent.

So for now, I'm going to take a small break. Rest assured, I do have more plans!

Shogun.

Ever had problems with Cxbx's video playback?

2010-01-04T12:33:00.000-08:00

Okay, this is for everyone who has had problems viewing videos with Cxbx lately. I don't know how many of you are having problems with Cxbx's video playback lately, but I know I have... for a long time! Ever since I updated my video card drivers for my laptop (I have an NVIDIA GeForce 8400 GS Mobile 128MB) back in August, I noticed that Cxbx's video playback was broken. Even though my GPU supports DirectDraw's hardware accelerated overlay surfaces (or at least it claims to), it still never worked anymore! This was driving me crazy because it meant less screenshots to show you guys (it's great to have proof).

"So, what did you do to fix it?" Well, I made quite a few changes to get this working again (and a few extra changes to get it working right without problems for some games). The first thing I did was force Cxbx to update the overlay surface in software using a YUV -> RGB conversion (which Cxbx already did support). After initializing DirectDraw, Cxbx will check for hardware YUV overlay support. If it is detected, it will use the hardware mode automatically. If not, then it does the conversion in software and writes the pixels to the backbuffer. To disable it, I just commented out this in EmuD3D8.cpp: g_bSupportsYUY2 = true; While the hardware accelerated method was a good idea, it did have a few drawbacks which are just now beginning to surface. To further illustrate, I'll show the pros and cons of each:

1. Hardware YUV

Good:

- Fast

- Automatically updates itself (no need to call D3DDevice::Present)

Bad:

- Usually too fast! Can cause "robotic" audio

- Can cause crashes (Unreal Championship)

- Can't take screenshots easily

2. Software YUV

Good:

- More accurate speed wise (at least for me)

- Can take screenshots with print screen button

- More compatible

Bad:

- Can be too slow depending on your hardware

- Does not update automatically (requires hack, but easily fixed)

A good idea would be to give the user the option to use hardware or software YUV overlay updates for maximum compatibility to the user's liking.

More on the "hacks" used to get this working properly. This was really easy to do. One thing I noticed was that when trying to play videos with Dead to Rights and PacMan Worlds 2 was that before playing the video, all the parameters would be NULL. So if there's no surface passed in for the first parameter, don't update the overlay or else you'll crash and burn. The second thing is that I noticed that when I disabled the hardware overlay flag, some videos would play and others still wouldn't show up. That's because the Xbox expects each frame to show up without the need to call D3DDevice::Present. So for every time that the overlay surface is updated and Present or Swap is not called, call Present after the overlay update. And as you can see above, the results were great!

One more benefit is that since the fact that most videos play at about 30 FPS, they will generally play at that frame rate, resulting in better sounding audio (still a bit choppy sometimes, but less robotic). So there you have it. I'll see to it that there's an option to use hardware and software overlays at your discretion so you won't go through the same problems I did.

Shogun

PacMan Worlds 2

2010-01-03T19:32:00.001-08:00

The funny thing about this is that someone on ngemu was recently asking me why this game didn't work (about 2 or 3 days ago). Little did I know, the progress with Dead to Rights got this game to show the intro videos. Actually, I made this progress yesterday, but never got around to posting it until now (tbh, I couldn't, but that's for a totally different blog update).

More about PacMan. Since it was by Namco, it uses the Namco engine just like Dead to Rights (it even uses the same XDK, 4432). This also means it shares the same bugs. I haven't been able to track down what's really going on here, so any more immediate progress on these games isn't guaranteed.

"Why is there a white line in front of each screen?" That's because there's a full screen quad covering it up. It's supposed to be rendered behind the overlay, but there's a bug in Cxbx causing it to be displayed over the scene. This is also a problem in Panzer and Dead to Rights. I don't really have too much else to say, but I'll see what else I can pull up now.

Shogun.

Dead to Rights

2010-01-02T11:47:00.000-08:00

I know it's late, but Happy new year! Anyway, I'll cut straight to the chase today and I'm going to make this quick. I got the game Dead to Rights to go in-game today (with an asterisk), but chances are you probably won't be playing it by the next release. Why not? The bug fix for this game (which technically isn't a fix) will break every other game. In order to get in-game, I had to disable calls to IDirect3DDevice8_DrawIndexedPrimitive. There's yet another undiscovered bug inside of EmuIDirect3DDevice8_DrawIndexedVertices. So far, I don't know what it is or how to fix it yet. Once again, a fullscreen quad is overlapping the 3D scene just like in Panzer Dragoon Orta. I also had to disable overlay updates to prevent crashing like in Unreal Championship (that's one reason why you see a white screen in the background).

This game may not be as visually impressive as many others, but this game uses alot of functionality that Cxbx did not originally support so even though it only took me less than 2 days to get this far, the difficulty of emulating this game is still not to be underestimated! Even though I'm not yet successful in getting this game playble yet, it was a good experience for me and showed a few areas where Cxbx was lacking. See? Emulating an Xbox game with a PC port CAN be beneficial! Until next time.

Shogun.

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

2009-12-31T21:33:00.000-08:00

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

2009-12-28T15:33:00.000-08:00

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

2009-12-08T18:30:00.000-08:00

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

2009-12-04T11:42:00.000-08:00

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

2009-12-03T11:35:00.000-08:00

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.

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

2009-11-29T12:19:00.001-08:00

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

2009-11-24T14:28:00.000-08:00

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

2009-11-22T19:47:00.000-08:00

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.

2009-11-19T19:16:00.000-08:00

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

2009-11-16T22:44:00.000-08:00

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

2009-11-14T13:02:00.000-08:00

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)

2009-11-13T13:41:00.000-08:00

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?

Updated the OpenXDK includes in the import folder. I forgot to fix that.
Updated the resource files Cxbx.res and CxbxDll.res. I didn't realize those changed at first.
Updated the libjpeg.lib file.
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!

2009-11-11T19:37:00.000-08:00

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

2009-11-11T17:43:00.000-08:00

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

2009-11-09T14:18:00.000-08:00

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

2009-11-06T12:38:00.001-08:00

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.

2009-11-05T14:33:00.000-08:00

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 January 11, 2012)

2009-11-04T21:32:00.000-08:00

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: 58
Playable: 5
Ingame: 9
Menus: 11
Intros: 29
Nothing: 4

Newly added: Panzer Dragoon 1

Newly Updated: Myst III (Ingame)

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: (Intros)

15. Zapper
Status: (Intros)

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: (Intros)(*)

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

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.

2009-11-04T11:41:00.000-08:00

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

2009-11-03T18:29:00.000-08:00

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!

2009-11-02T23:12:00.000-08:00

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

2009-11-02T11:22:00.000-08:00

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.