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

PacMan Worlds 2

The funny thing about this is that someone on ngemu was recently asking me why this game didn't work (about 2 or 3 days ago). Little did I know, the progress with Dead to Rights got this game to show the intro videos. Actually, I made this progress yesterday, but never got around to posting it until now (tbh, I couldn't, but that's for a totally different blog update).

More about PacMan. Since it was by Namco, it uses the Namco engine just like Dead to Rights (it even uses the same XDK, 4432). This also means it shares the same bugs. I haven't been able to track down what's really going on here, so any more immediate progress on these games isn't guaranteed.

"Why is there a white line in front of each screen?" That's because there's a full screen quad covering it up. It's supposed to be rendered behind the overlay, but there's a bug in Cxbx causing it to be displayed over the scene. This is also a problem in Panzer and Dead to Rights. I don't really have too much else to say, but I'll see what else I can pull up now.

Shogun.

Dead to Rights

I know it's late, but Happy new year! Anyway, I'll cut straight to the chase today and I'm going to make this quick. I got the game Dead to Rights to go in-game today (with an asterisk), but chances are you probably won't be playing it by the next release. Why not? The bug fix for this game (which technically isn't a fix) will break every other game. In order to get in-game, I had to disable calls to IDirect3DDevice8_DrawIndexedPrimitive. There's yet another undiscovered bug inside of EmuIDirect3DDevice8_DrawIndexedVertices. So far, I don't know what it is or how to fix it yet. Once again, a fullscreen quad is overlapping the 3D scene just like in Panzer Dragoon Orta. I also had to disable overlay updates to prevent crashing like in Unreal Championship (that's one reason why you see a white screen in the background).

This game may not be as visually impressive as many others, but this game uses alot of functionality that Cxbx did not originally support so even though it only took me less than 2 days to get this far, the difficulty of emulating this game is still not to be underestimated! Even though I'm not yet successful in getting this game playble yet, it was a good experience for me and showed a few areas where Cxbx was lacking. See? Emulating an Xbox game with a PC port CAN be beneficial! Until next time.

Shogun.