Next Generation Emulation banner

1 - 1 of 1 Posts

423 Posts
Discussion Starter #1
As I've been working on Dxbx for about two years now, here a bit of history on Dxbx :

The Dxbx project was started by Shadow_Tj, and was meant to become a 1-to-1 translation of Cxbx (which is written in C) to Delphi.
When I joined the Dxbx project, it was not very far translation-wise; the code that translate Xbox1 executables (XBE's) to windows-native (PE) executables was not working yet, the kernel thunk table wasn't applied correctly and the way the translation was going, it would mean lots of manual labor.

In that light, I first fixed the executable-conversion, made the kernel thunk table loading work, and started on working out a few translation guidelines.
At a certain moment in time, we where able to use the Cxbx kernel DLL, which made us suddenly run actual games! This was faking it to ofcourse, as the actual emulation was running from Cxbx's code, while the intention was to have all emulation code in Delphi.

So we started on translating the Cxbx emulation kernel itself, and quickly realised that there where two parts of Cxbx that where either troublesome to convert to Delphi (the symbol-information structures) or plain incomplete (the kernel thunk table). Later on we encountered another difficulty : Delphi handles interfaces differently from C - which meant we had to find a solution for that too.

Currently, we've overcome most of these problems; I found a way to call into interfaces while avoiding the automatic reference-counting that Delphi does, I implemented many more kernel-API's and have (just yesterday) finished my own symbol-detection engine.
Those symbol-detections are important, as the High-Level emulation that Cxbx (and thus Dxbx) uses, runs most code natively on PC's - but some functions can never work, as a PC just doesn't have the hardware the Xbox1 has. So this code has to be patched, for which we need to know the location of the offending functions of course.

Together with ongoing translation-work on the actual patches, we're now at a level the Dxbx can run a few small test applications - as you can see in our screenshots thread. (Mind you, this is all Delphi, no Cxbx code is involved in this anymore!)

As for the future : We will continue to improve the quality of the translation of Cxbx code (as there are still some bugs in there that somehow prevent us from running more applications). Also, I'll have to start digging into the detection of sound interfaces, as they are the main difference when I compare the debug ouput of our reference-game (Turok) between Cxbx and Dxbx.
1 - 1 of 1 Posts