Tuesday, December 21, 2010

Random update(s) & OpenGL project updates.

Yup, that's right. I'm still kicking! And now that I have a spare moment, I thought I'd share some good news with you all. Nothing spectacular, but hopefully this might interest someone out there :)

As you can see here, the game known as Innocent Tears is showing stuff. This screenshot was not taken by me, btw. It was taken by Bill_gates (no, not THE bill gates, the one on ngemu!) and I don't have this game for myself (yet) but since it uses XDK 4627, I think getting it working passed this screen won't be too hard.

The next thing I wanted to mention was that I finally figured out what was causing Azurik to hang in XP. Turns out it was an Xbox exclusive flag being set that matched a PC flag. The flags MEM_NOZERO (Xbox) and MEM_ROTATE (PC) have the exact same values and causes failures when used with MEM_COMMIT. So all I had to do was omit that flag, and bam, it works again. Why this flag combination works on Vista and later is beyond me, but meh, I'm glad I solved the problem on XP. Azurik still looks rather horriffic going ingame (I've never seen such major distortions in any game to date), and Cxbx generates some funky pushbuffer results for it. No clue how I'm going to emulate this game properly :(

One more thing, I started writing my Xbox Direct3D -> OpenGL 1.5 driver last week in my spare time. So far, it works okay, but it still has a long way to go until it is ready to handle Cxbx. It wasn't really hard or anything, just having to fix annoying bugs to get it to work and trying to support the large array of features and formats is going to take time. It's not intended to replace the actual Direct3D .dlls, but it's (right now) a customized .dll that I aptly named d3d8_xbox.dll that is called instead of d3d8.dll, but you still have to link it with the project. Right now, I'm just testing it against DXSDK examples to make sure it works okay. Here's what I did so far:
  • D3DDevice creation and OpenGL initialization for windowed and fullscreen modes. Also uses glew to initialize the required extensions, saving me precious time and headache.
  • Primitive rendering via D3DDevice::DrawVertices[UP] and D3DDevice::Begin/End. Right now, it uses immediate mode because my vertex array code kept crashing, but for now, getting it to work is the primary concern. Any calls to D3DDevice::DrawPrimitive[UP] are redirected to the above by default. Indexed geometry is not yet supported. Also, every primitive type is supported, so no more primitive patching for non standard primitive types like D3DPT_LINELOOP, D3DPT_QUADLIST and D3DPT_QUADSTRIP! This should run much faster in Robotech: Battlecry and Panzer since they rely on Quad rendering heavily. Also, I'm going to stick with immediate mode for D3DDevice::Begin/End since that's basically what it is, and speed isn't critical for these related APIs.
  • Very basic push buffer emulation via D3DDevice::BeginPush/EndPush. Once again, I'm using immediate mode for it. Works like a charm.
  • World, View and Projection matrices/transformations. I found another D3D -> OpenGL wrapper out there and got the idea for how to do it from that project (dxwgl, IIRC). Before then, I couldn't figure out how to do it. The solution was simple once I understood how it worked.
  • Lighting. It works, but only when I don't set the light position :/ I wonder why that is... Btw, is there an OpenGL equivelant to the "Range" field in D3DLIGHT?
  • Textures and surfaces work, but I only wrote support for D3DFMT_X8R8G8B8 and D3DFMT_A8R8G8B8 so far. Textures use the standard 2D texture, but surfaces use texture rectangles since they are more efficient for such an operation. Special care has to be taken into consideration when dealing with surfaces to make sure they behave properly when rendering normal 3D geometry with certain render states. For instance, I have to disable almost every render/texture state prior to rendering it, but it pays off with speed. My surface code is about 4x faster than Direct3D itself, even when using immediate mode!
  • Various render states. I haven't finished adding all the renderstates, but many of the renderstates not supported by standard Direct3D have been implemented, so we no longer have to worry about those!
There are many more features to go, but give me a month, and hopefully it should be working at a satisfactory level. The big thing that troubles me is converting the vertex/pixel shaders to OpenGL vertex/fragment programs. I can use NVparse and do this easily, but then we'll be limited to NVIDIA cards and ATI users will be left out, or is there an equivelant library for ATI users? If not, I'll try to use the ARB versions for both. Okay? If it works, then we can kiss many of our compatibility problems goodbye!

So, there you have it. This is everything I've been up to so far. I'm still having it rough IRL (well, not too bad since I have stable housing now) but at least I have a bit more free time atm (but I can't spend it all on Cxbx unfortunately). Isn't open source a great way to go?


EDIT: I found this today: http://realmforge.tigris.org/source/browse/realmforge/trunk/src/Axiom/RenderSystems/OpenGL/ATI/PixelShader.cs?revision=5&view=markup

It's in C#, but maybe a bit of hope for the ATI users for a working vs/ps1.1 -> ATI vertex/fragment program conversion.


  1. Hey! You sound happier than usual. Have you gotten a job, or something? Is somebody else supporting you financially?

    This conversion to the OpenGL wrapper sounds cool, though. Hope it can work... A great and very clever way for you to take a different direction than PatrickVL and his DXBX, coz then we'd get two distinct and unique emulators. Cool! Of course, I know you'd been wanting to do it in OpenGL in order to keep a strong compatibility base into the future.

    To others: Innocent Tears is a Tactical Strategy, or Strategic RPG based game that was released on the Xbox only in Japan (Bugger about the Jap-only language. Anyone interested in fan-translation?). It was actually going to be released for the Dreamcast but was carried over to the Xbox after the DC was discontinued.

    One user said at www.play-asia.com/paOS-13-71-4q-49-en-70-1uo.html that this game's not as good as Shining Force. But it's all polygonal, not sprite-based characters on 3D backgrounds, like most other SRPGs even today. Lots of cool anime quality in there. Mobygames.com hasn't even got any screenshots of it, but there are plenty of good ones at www.rpgamer.com/games/other/dc/innocenttears/innocenttearsss.html and http://au.dreamcast.ign.com/objects/014/014163.html.

    AND BLUESHOGUN, your blog here was the 2nd most popular choice when I googled 'xbox innocent tears'!!! Congratulations!!

  2. 2nd most popular? That's a surprise!

    Well, I'm still unemployed, but no use moping about it :) I'll find something one of these days.

  3. Perhaps that OpenGL wrapper means this particular CXBX might be utilised by somebody else in the future to work on powerful handheld consoles and/or portable computing devices that accepts OpenGL. Especially the open-source handhelds such as those from GamePark Holdings (GP2X, GP2 Wiz, but only on a more powerful one in the future), and OpenPandora (maybe not enough grunt to run a given CXBX-based emu, so a sequel maybe). A PSP2...?

    That's because somebody told me that the DXBX couldn't possibly be platform-translated over to non-Win systems, because it used the DirectX API, which those ones doesn't support.

  4. blueshogun96- what is your particular problem of installing windows 7 ? i know its late to ask but im curious.

  5. The only problem I encountered with the ARB vertex shader assembly is, that it doesn't support the RCC (clamped reciprocal) opcode - you need the NV extension for that. (Although I think it can be replaced by a RCP + MIN + MAX to get the same clamping behaviour).

  6. PS : That wrapper you talked about is probably this one : https://sourceforge.net/projects/dxglwrap/
    It's an (incomplete) implementation of the D3D8 interfaces, doing it's rendering via OpenGL.