Joined
·
425 Posts
Here comes yet another installment of our (not-so-regular) Dxbx progress updates ...
It might seem quiet on the Dxbx side, but that's only because I'm working on a rather large rewrite of our function-detection algorithm. I'm making good progress, but it's time-consuming work.
I can tell you however, that with my current scanning code, I detect about 6 times as many functions as before (6600 in Turok!). Of those, 99,8% matches Cxbx's locations (as always, I'm using Turok as base for comparison). The other 0,2% that doesn't match Cxbx seems to be either wrong detections in Cxbx, or glitches in our patterns.
You might have noticed that I'm talking about function-detection again, as opposed to symbol-detection. The detection of non-function symbols (such as symbols that represent global variables, data structures or functions without pattern-data) I was talking about earlier, isn't lost however. It's just that the scanning code I'm currently writing, views those more as a side-effect than as a primary goal.
Once I finish this code, Dxbx should have better function-detection than Cxbx currently has - this helps both projects ofcourse, as our output can be used to improve Cxbx's function scanning too.
After that, we'll be working on the correct translation of interfaces.
Dxbx, being written in Delphi, handles interfaces as pointers, and does automatic reference-counting on them. Cxbx, being written in C, doesn't have this behavior, and as such doesn't do much reference-counting.
When translating interface-using code from C to Delphi, we have to pay special attention so that we get identical usage of interface-pointers and no unnecessary reference-counting anywhere. Shadow_tj and me have devised a way to do this with as little (and clean) code as possible, but it's a cumbersome job too.
Once that is in place, we'll be focussing on translating everything Direct3D related to finally get some graphics showing - I don't know when this will be, but it's not far in terms of lines of code
Because of everything above, we probably won't be releasing a new build around christmas like we did last year. Rest assured that we'll publish this as soon as Dxbx becomes (somewhat) usable. In the mean time (and if Shadow_tj can find the time) we might publish a XdkTracker build including all our dumps for you all to enjoy
That's all for now. Until the next update!
--PatrickvL.
It might seem quiet on the Dxbx side, but that's only because I'm working on a rather large rewrite of our function-detection algorithm. I'm making good progress, but it's time-consuming work.
I can tell you however, that with my current scanning code, I detect about 6 times as many functions as before (6600 in Turok!). Of those, 99,8% matches Cxbx's locations (as always, I'm using Turok as base for comparison). The other 0,2% that doesn't match Cxbx seems to be either wrong detections in Cxbx, or glitches in our patterns.
You might have noticed that I'm talking about function-detection again, as opposed to symbol-detection. The detection of non-function symbols (such as symbols that represent global variables, data structures or functions without pattern-data) I was talking about earlier, isn't lost however. It's just that the scanning code I'm currently writing, views those more as a side-effect than as a primary goal.
Once I finish this code, Dxbx should have better function-detection than Cxbx currently has - this helps both projects ofcourse, as our output can be used to improve Cxbx's function scanning too.
After that, we'll be working on the correct translation of interfaces.
Dxbx, being written in Delphi, handles interfaces as pointers, and does automatic reference-counting on them. Cxbx, being written in C, doesn't have this behavior, and as such doesn't do much reference-counting.
When translating interface-using code from C to Delphi, we have to pay special attention so that we get identical usage of interface-pointers and no unnecessary reference-counting anywhere. Shadow_tj and me have devised a way to do this with as little (and clean) code as possible, but it's a cumbersome job too.
Once that is in place, we'll be focussing on translating everything Direct3D related to finally get some graphics showing - I don't know when this will be, but it's not far in terms of lines of code
Because of everything above, we probably won't be releasing a new build around christmas like we did last year. Rest assured that we'll publish this as soon as Dxbx becomes (somewhat) usable. In the mean time (and if Shadow_tj can find the time) we might publish a XdkTracker build including all our dumps for you all to enjoy
That's all for now. Until the next update!
--PatrickvL.
