More Outrun 2 Progress

Okay, just a quick update on Outrun 2.  I made a very basic implementation of the XFileMediaObject interface, and guess what?  I've actually gotten it to the menus in just a few hours of extra fixes!  So far, there doesn't appear to be any severe issues, just a few texture related bugs here and there.  Sound and music works too (most of it).  As far as the sound goes, it sounds a bit better in Release mode.

"Nice screens, but what's stopping it from going ingame?"  Okay, what's happening is that it continuously fails to create some random index buffer.  Not sure whats causing the failure, but it keeps returning D3DERR_INVALIDCALL so that could mean all sorts of things, really.  I'll have to investigate this issue more later.  It's really late and I just busted my butt all day for you guys!  I'll sleep on it and see what I can come up with next time.

Shogun

Outrun 2 Progress

Wait, what?  I haven't updated this blog in a year?  Hm, I can't believe it's been this long...

Well, haven't had anything too interesting to report until now though.  I'll start off by saying this once again... I've had a rather ridiculous amount of requests for Outrun 2 (XDK 5849, the very first title using it [that I know of] that does anything on Cxbx) and various other SEGA titles.  It's not that I'm not interested in these games, it's just that SEGA's Xbox titles are not exactly easy to emulate!  They're ALWAYS problematic in one way or another, therefore they aren't easy to emulate.  Outrun 2 is no exception, but I'll get to that in a minute.  Surprisingly, Outrun 2 is much easier to work with than I originally thought.  It was just a matter of adding missing functionality and fixing a bug or two in the existing implementation(s), and unlike most SEGA titles, the problems are rather easy to identify this time.  Keep in mind, this isn't Outrun 2 SP [DX]; I don't have that version... YET!

"So, what's stopping it from working, and when will this become playable?" Good question(s).  I've determined that it's an audio related issue.  Outrun 2 uses some Xbox exclusive high level code to stream audio.  No one has ever implemented the XMediaFileObject interface or any of it's relatives, so unless I do it myself, it's not going to get done.  There is no PC equivalent so I have to emulate everything myself.  For loading and streaming .wav files (even if they use the Xbox ADPCM codec), emulating this is a piece of cake.  For .wma files and other supported audio files, it may not be as easy (unless I can find some documentation on the file format).  Games like Whacked and Quantum Redshift, I could just leave out the functionality and the game would work fine, but not for Outrun 2, obviously.  So I'll have to take some time out to learn about audio loading/streaming with these APIs and write some test code to verify Cxbx can do it properly.  Good thing I have my handy Debug Xbox sitting next to me. But Lord, where's caustik when you need him??  lol.  So until this is fixed, I can't guarantee this game will be on our playable list in the future.  Don't worry, I'll keep trying!

One more thing, you may have noticed the fluctuation of framerates on those screenshots above.  It's because (like most Japanese titles) the game is using D3DDevice::BlockUntilVerticalBlank() to stall/synchronize threads for audio and other time sensitive threading procedures.  While I support and recommend this approach personally, Cxbx's previous implementation wreaks havoc on the host's CPU usage!  On the console, this is not an issue, but on Windows, this is a problem.  Since DirectDraw is the only way to accurately keep track of vertical blank (via IDirectDraw7::WaitForVerticalBlank), that's what we've been using.  Unfortunately, this causes us problems when used in many different threads and bogs the whole system down.  So instead, I've been using Sleep(1000/60) where 60 is the theoretical refresh rate Cxbx is running at.  I'll add a menu option to switch between the functionality just in case you need one over the other.  But for Outrun 2, it fixed the frame rate issue and should for a few other titles using the same methods.

So, that's all I have to say about Outrun 2 at the moment.  Looking forward to making more progress on this game because it's a rather high priority game for me.  Thanks for reading!

Shogun.

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.