Monday, November 16, 2009

Cxbx and OpenGL: Time to shed some light on this topic...

Okay, this question has come up many times (even more ever since I started that poll on getting opinions on an OpenGL port of Cxbx). Will Cxbx be ported to OpenGL? That's part of my plan, yes. For those of you wondering why I'd do such a thing, I'll give you an explanation as to why.

Ever since Cxbx has been released, you'll notice that it has been using Direct3D 8.0; notice a problem already? Direct3D 8 has been depreciated a long time ago and it doesn't really have any good debugging tools anymore. IMO, the driver support for Direct3D 8 isn't that great either. To top it off, PC standard Direct3D8 (and 9) does not contain all of the functionality we need to emulate the Xbox. Fortunately, OpenGL does! Using OpenGL will allow us to have a much cleaner implementation for certain functions if implemented properly. Some say that because OpenGL isn't COM oriented, an OpenGL port would be too hard. No, not really.

Ever heard of Wine? We can always use the WineD3D implementation instead. This way, we can basically have our own customized Direct3D library, and add all the custom functionality that standard Direct3D lacks... and still be using OpenGL the whole time! I've already picked up the idea and have been planning my implementation of WineD3D into Cxbx. It would be easiest to just take the needed code from WineD3D and create a custom library and call it WineX or something like that. Thank God it's GPL :)

So there you have it. An OpenGL port is planned, but as of now, it's still not a top priority. But once implemented, we can easily test it against XDK samples to ensure accuracy and speed when necessary.



  1. This comment has been removed by the author.

  2. hum great news ! what are the missing functions that D3D 8 doesn't have for XBox emulation ?

  3. @Yann, Xbox's superset of Direct3D 8.0 contains many functions that resemble OpenGL so to speak. Mostly render states that are exclusive to OpenGL. For instance, two sided lighting, stipple patterns, back fill modes, logic operations, possibly raster operations, and multiple primitive types aren't supported by Direct3D at all. Also, there are some functions, such as pushbuffer functions, aren't part of any standard graphics API.

    I can't remember them all off the top of my head (there are lots of them!), but there are many functions that would make OpenGL more ideal. So in general, you can basically think of Xbox Direct3D as a superset of OpenGL 1.5 instead of Standard Direct3D sometimes because of all the similarities it even has it's own version of immediate mode.

    Example(s) of OpenGL derived functions:
    - D3DDevice::SetVertexData[234][if]()
    - D3DDevice::SetRenderState_LogicOp()
    - D3DDevice::SetStipple() <- Panzer uses this.
    - D3DDevice::SetRenderState_EnableDxt1()

    The list goes on and on :)

  4. ok :-D it's good idea to use OpenGL. Think you that a linux port is posssible ? CXBE can be compiled on linux so maybe CXBX too (with OGL)?

  5. I'm not too sure about the Linux part. The Windows version is heavily dependent on the Win2k kernel, but I'm sure we can use Wine handle the kernel APIs for us. I need to start learning more about Linux. I have SUSE, but I haven't installed it on any machine yet.

  6. Oh hey, if you need some ideas about how an OpenGL port might work, there's an OpenGL Wii Emulator called Dolphin. I know Wii emulation is probably way different than Xbox Emulation, but there must be some similarities between the two emulators since they're both OpenGL. You might want to take a look at the emulator, it might be able to help you a bit with your OpenGL port.

    Here's a link to it if you're interested:

    Hope that helps! =D

  7. An emulator is more than just the API it uses for Gfx and sound actually. The hardware architecture of the Wii and Xbox are completely different in every way that I can imagine. Also, Cxbx uses HLE, and Dolphin uses LLE. Instead of emulating the actual hardware like Dolphin does, we need to emulate Xbox Direct3D instead. WineD3D has already done a near complete wrapper of Direct3D to OpenGL making our lives easier. So there wouldn't be anything to gain from it here. I appreciate the link and concern, but WineD3D should cover all of our needs :)