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.

Cxbx svn r163

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.

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!

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

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!

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

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!

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!

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

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

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!

1. 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?
2. 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.
3. 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

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

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.

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.

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)

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)

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

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

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.

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.

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.

1. 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.
2. 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.
3. Patrick got me a copy of the Flair SDK. This will greatly speed up Cxbx progress very much!
4. 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.
5. 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?

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