Sunday, April 25, 2010

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.


Sunday, April 18, 2010

Cxbx compat list is over 30 now!

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 :)


Friday, April 16, 2010

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?


Monday, April 12, 2010

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.


Saturday, April 10, 2010

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!


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 :)


Thursday, April 8, 2010

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?


Friday, April 2, 2010

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.