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.