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.