Xbox Dashboard (3944)

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.

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.

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

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

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

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.