Great article and fantastic work, though the commitment to stick with the ancient DCC software of the era (genuinely admirable), is an immense amount of pain, for no real gain that I wouldn't dare to try. Modern Blender can be extended to import/export legacy formats like DirectX 8 .x and N64 Homebrew for example have great asset tools all working in modern Blender, with a big community behind them. FBX was originally a (Kaldera) MotionBuilder format only back in that era and 3ds Max support for it didn't come until around version 8/9.
I'd say there's a way to build a modern asset pipeline for the OG Xbox where you can leverage USD (well supported in all modern DCC), and then build tooling/viewers around it to process/split/export everything out to DirectX 8 .x in a much more manageable way. Makes artist collaboration a lot easier (modern tools with guardrails inplace), and can measure and keep metrics on everything (every KB counts with 64MB RAM).
All these old versions of Maya, 3ds Max and Visual Studio are just a total liability now. Licences for them can't be activated, and even if they can, it's a lot of backflips to get Autodesk to help. 3dsMax/Maya 8 and earlier barely work on Windows 10/11 now (Vista changed a lot for desktop apps) and even Visual Studio 2005 needed to be patched to support Vista!
FWIW Blender 5.1.2 (i.e. the latest one) can import and export DirectX .x files using an addon you can download from[0] (from inside Blender itself).
Though i'd stick with Blender 2.79b for such projects because Blender 2.8 (i think) switched to a PBR pipeline that looks "wrong" when targeting non-PBR renderers (in theory you can recreate the original shading using material nodes or whatever they're called, but setting up materials in modern Blender is already more involved than Blender 2.79b without taking nodes into account). Most of the tools you'd need for making game assets (mesh editing and UV editing primarily) haven't changed much anyway to the point where you can follow most Blender mesh editing tutorials with it :-P. I'm in a few retro gamedev Discord channels and apparently i'm not the only one using 2.79b because of the changes in 2.8+.
> Dive and read the official documentations for that hardware (pure RTFM kid), at this case the SDK/API docuements. And red through the samples that comes with the SDK, compile them, and learn even more tricks from them.
Unfortunately nxdk does not have (any) great docs and it is much lower level than what you'd (probably) get with the official SDK - you basically have to write your own GPU driver for example (though i think nowadays there is a partial implementation of OpenGL that has enough functionality to port a modern-ish Quake engine).
I made a simple engine[0] some time ago for OG xbox using nxdk and i basically had to figure out what registers do what using old versions of Nouveau from when it had GeForce3 support - and whenever that wasn't enough, i was just trying random stuff :-P. And unfortunately xemu (currently the most complete OG xbox emulator) is not very accurate when it comes to failures, so very often you get stuff that work on it not actually working on the real hardware.
On the other hand, in case anyone cares, nxdk is basically the only "legal" way to make stuff for OG xbox and various communities (like on Discord) do not allow posting binaries/ISOs made with the original XDK. And from a more practical perspective, at least personally i prefer to use a Unix/Linux-based development environment :-P.
(unfortunately i'm also having some weird issue with my engine in that i get weird flickering on the real hardware that i do not get on the emulator that seem to be based on wrong values ending up to the renderer - but only with optimizations enabled and only on the xbox hardware - if i compile the engine for Linux, be it 32bit or 64bit, it works fine and no matter which tool i tried - valgrind, sanitizers, etc - and good old "pouring through the code" i cannot find what the issue is -- which makes me think it a compiler bug as nxdk relies on Clang and i'm not sure the Clang devs test Pentium 3 much - and unfortunately, unlike GCC, you can't enable only individual optimizations, you can only use the -O<n> optimization levels, so i can't even figure out what exactly breaks things that could have been a hint in case it is something in my code)
This was a great read and also a bit nostalgic. I still love my OG Xbox (crystal edition) and am still surprised by the development that is active for my first ever self owned console.
Great article and fantastic work, though the commitment to stick with the ancient DCC software of the era (genuinely admirable), is an immense amount of pain, for no real gain that I wouldn't dare to try. Modern Blender can be extended to import/export legacy formats like DirectX 8 .x and N64 Homebrew for example have great asset tools all working in modern Blender, with a big community behind them. FBX was originally a (Kaldera) MotionBuilder format only back in that era and 3ds Max support for it didn't come until around version 8/9.
I'd say there's a way to build a modern asset pipeline for the OG Xbox where you can leverage USD (well supported in all modern DCC), and then build tooling/viewers around it to process/split/export everything out to DirectX 8 .x in a much more manageable way. Makes artist collaboration a lot easier (modern tools with guardrails inplace), and can measure and keep metrics on everything (every KB counts with 64MB RAM).
All these old versions of Maya, 3ds Max and Visual Studio are just a total liability now. Licences for them can't be activated, and even if they can, it's a lot of backflips to get Autodesk to help. 3dsMax/Maya 8 and earlier barely work on Windows 10/11 now (Vista changed a lot for desktop apps) and even Visual Studio 2005 needed to be patched to support Vista!
FWIW Blender 5.1.2 (i.e. the latest one) can import and export DirectX .x files using an addon you can download from[0] (from inside Blender itself).
Though i'd stick with Blender 2.79b for such projects because Blender 2.8 (i think) switched to a PBR pipeline that looks "wrong" when targeting non-PBR renderers (in theory you can recreate the original shading using material nodes or whatever they're called, but setting up materials in modern Blender is already more involved than Blender 2.79b without taking nodes into account). Most of the tools you'd need for making game assets (mesh editing and UV editing primarily) haven't changed much anyway to the point where you can follow most Blender mesh editing tutorials with it :-P. I'm in a few retro gamedev Discord channels and apparently i'm not the only one using 2.79b because of the changes in 2.8+.
[0] https://extensions.blender.org/add-ons/io-directx-x/?utm_sou...
> Dive and read the official documentations for that hardware (pure RTFM kid), at this case the SDK/API docuements. And red through the samples that comes with the SDK, compile them, and learn even more tricks from them.
Unfortunately nxdk does not have (any) great docs and it is much lower level than what you'd (probably) get with the official SDK - you basically have to write your own GPU driver for example (though i think nowadays there is a partial implementation of OpenGL that has enough functionality to port a modern-ish Quake engine).
I made a simple engine[0] some time ago for OG xbox using nxdk and i basically had to figure out what registers do what using old versions of Nouveau from when it had GeForce3 support - and whenever that wasn't enough, i was just trying random stuff :-P. And unfortunately xemu (currently the most complete OG xbox emulator) is not very accurate when it comes to failures, so very often you get stuff that work on it not actually working on the real hardware.
On the other hand, in case anyone cares, nxdk is basically the only "legal" way to make stuff for OG xbox and various communities (like on Discord) do not allow posting binaries/ISOs made with the original XDK. And from a more practical perspective, at least personally i prefer to use a Unix/Linux-based development environment :-P.
(unfortunately i'm also having some weird issue with my engine in that i get weird flickering on the real hardware that i do not get on the emulator that seem to be based on wrong values ending up to the renderer - but only with optimizations enabled and only on the xbox hardware - if i compile the engine for Linux, be it 32bit or 64bit, it works fine and no matter which tool i tried - valgrind, sanitizers, etc - and good old "pouring through the code" i cannot find what the issue is -- which makes me think it a compiler bug as nxdk relies on Clang and i'm not sure the Clang devs test Pentium 3 much - and unfortunately, unlike GCC, you can't enable only individual optimizations, you can only use the -O<n> optimization levels, so i can't even figure out what exactly breaks things that could have been a hint in case it is something in my code)
[0] http://runtimeterror.com/pages/iv/images/8a37dc59c6f6adbbb98...
This was a great read and also a bit nostalgic. I still love my OG Xbox (crystal edition) and am still surprised by the development that is active for my first ever self owned console.
I'm having trouble reaching it. Luckily archive.org got it a few days ago: https://web.archive.org/web/20260707044812/https://mamoniem....