The lastest on Shogun's branch.

Well, I'm really glad that I've managed to make it this far. I don't mean to sound... you know, but when I first saw the first screens of Panzer, I never dreamed that I would someday carry on sir Caustik's work and get it ingame, haha. Sometimes I miss being a noob! (Yes, that's right... "noob") :D

Anyway, here's the latest. I've managed to increase the stabilitiy of Panzer Dragoon ORTA for the most part except for a few but rare random crashes related to threads (not while in game luckily). So far, the framerates aren't very fast.

I think I have an idea about the overlapping quad covering the 3D scene. My guess is that it's really supposed to be transparent (Alpha Blended) to simulate fading in/out for 3D scenes. This reminds me of the time when I was working on Smashing Drive. The transparency overlay quad didn't work on my WinXP machine, but worked fine on my notebook PC running Vista. The problem may be related, but that can't be verified now because I don't have my WinXP desktop here in Washington (State), it's at my cousin's house still in Indiana.

I've added the Direct3D API IDirect3DDevice8::SetStipple (Xbox extension) and a missing texture state again (D3DTOP_BLENDFACTORALPHA, 15). So far, that appears to be the end of any missing Direct3D function calls. That's a big relief!

The main thing stopping our progress now is this missing low level DirectSound Buffer call to either CDirectSoundBuffer::Pause (as stated in my last update) or CDirectSoundBuffer::GetStatus because when looking at the dissassembly of them both, they look the same! I had the same problem with Robotech: Battlecry (XDK 4721), so fixing one will fix the other. Initially I was having trouble adding it because when Cxbx would locate my OOVPA for it, it would crash. This had me scratching my head for quite some time now. I discovered a few minutes ago that when I moved the XREF IDs higher up in the list, then they work fine. That's really strange, and I hope it doesn't cause any future problems because if it does, then we can forget about Metal Gear Solid 2 (and no I don't care about the fact there's a PC port, I still want to see it emulated)!

Before I conclude this blog update, I just want to address one more thing. This question/suggestion has come up on more than one occasion for a long time now (in fact, someone asked me about this today!)... can Cxbx use a more up-to-date API such as OpenGL or at least Direct3D9? If so, when? Good question. Right now, an OpenGL 2.1 implementation is looking much better. Direct3D9 would also be a major improvement. I'll show you the pros and cons of both.

1. Direct3D9
Good:

• Easiest to debug. More debugging tools (i.e. NVIDIA's PerfHUD).
• Requires less code wrapping/hacking.
• Easier to manage.

Bad:

• Still lacks many features native to NVIDIA's hardware.
• Less control over some settings (i.e. some games get CreateDevice failures when VSync is enabled).
• Not portable.

2. OpenGL
Good:

• Closer to the hardware we're emulating. Some Xbox Direct3D features are only exposed via OpenGL.
• VSync can be enabled/disabled without problems.
• Better texture support for those unusual formats (IIRC).
• Locking/updating resources are much faster.

Bad:

• Harder to manage (i.e. lots of extensions to deal with).
  
• Lots of data type converting can get annoying (i.e. DWORD dwARGB -> float4 fRGBA).
• No native support for YUV surfaces. Will have to convert YUV -> RGB manually which may increase overhead.

So far, OpenGL is looking better now. But then again, we can always use Wine's Direct3D -> OpenGL implementation as suggested by Caustik and Nisse (a glass of wine sounds pretty good right about now!), and add Xbox specific extensions ourselves.

That's what's happening with Cxbx today. Until next time.

Shogun.