More on Innocent Tears & [Native] XInput support.

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.

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!

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

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.

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)

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

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.