Next Generation Emulation banner

1 - 3 of 3 Posts

·
Premium Member
Joined
·
423 Posts
Discussion Starter #1
Well then, if you where wondering how Dxbx is progressing, here's the current situation:

Dxbx, being written in Delphi, suffers somewhat from the logging code that we have. The thing is, that Delphi does a few things 'behind the curtains' so to speak, which in the case of logging means that there's a whole lot of stack reservation & automatic cleanup going on - even if the logging is turned off!
First, we thought it would be a good idea to solve this via conditional compilation, but that would require us to release two builds, and frankly I'm against that.
So now, I've designed a new method of logging, that's much more lightweight, as it doesn't impose us with Delphi's 'magic' stack-cleanup code anymore. This means that Dxbx will run a bit faster now, especially when logging is tuned down. At the same time, we can now render the log better - indentation & various 'ToString' conversions can now be done automatically (no manual work needed anymore).
Also, we can now tune the logging to various aspects - we'll add a configuration tab for this with a few presets, so you can for example trace just the memory-management code, or only the Xapi calls, or just the kernel calls related to IO, or emulate Cxbx behaviour, or just turn the whole damn thing off, or whatever you want.

Also, we're testing Dxbx on all kinds of homebrew and people are helping us to find commercial titles that 'do something' already. This gives us a nice list of things to focus on.

One thing I've been working at, is fixing drawing bugs in XSokoban. I chose that specific homebrew, as it had at least 3 problems :
The first problem is, that texts are being drawn using quads, and although we emulate these, there's something wrong in there that makes Nvidia based chipsets draw it erratically - most vertices are randomly jumping around (the strange thing is, that ATI chipsets have no problem with that - it could be stride-related, I don't know yet).
The second problem is (or WAS, actually) that after the first frame no more textures where being drawn. First we thought this could be due to dangling locks on the texture resources, but that didn't turn out to be the case. Instead, it turned out to be related to our lack of pixel shader emulation (more on that later) - we had the same code as Cxbx in the case of having an incompatible pixel shader active, which brutally switches off texture-mapping! As XSokoban doesn't turn texture-mapping on by itself, it stayed off after that, so once I turned that hack off, the textures reappeared!
The third problem is, that depth-checking (ZEnable) is being turned off continuously for some yet undetermined reason, resulting in overdraw that makes this homebrew unusable to play. Sure, hacking SetRenderState_ZEnable to always set a True value fixes the drawing, but I suspect XSokoban is passing us a variable that should be True when appropriate, but is always False for some yet unknown reason. As this could indicate a serious shortcoming in our emulation, I'll keep on digging on this one.

As for the pixel shader emulation I was talking about : I've started on reverse-engineering the binary Xbox1 pixel shader definition. Cxbx already had a bit of code for this, which I expanded upon in Dxbx. Now that I have a better understanding of that the various fields mean, I've started on writing a converter that outputs pixel shader assembly that would ideally represent the original shader close enough to actually do the same thing. (Coincidentally, I can use XSokoban to test this too.) It's a lot of work, but luckily I can cheat a little by looking at the Xeon code _SF_ posted years back, as it does about the same thing (the only difference is, that Xeon targeted HLSL, while I'm using plain old Direct3D 8.0 version 1.1 pixel shader assembly). I hope to make some good progress with this the coming weeks.

And as always, there's also the symbol detection part that I'm not satisfied with yet. We do have thought out a new way of doing it that should be faster and more reliable, but I still can't find the motivation to work on that BORING (but yet very important) piece of code - as I hate the breakage it's going to cause... In the past I've been working on that for months at a stretch, and I'm still too fed up with that to pick it up again.
So for now, we'll just have to work with what we've got, and just accept the fact that not all symbols are detected correctly.
I'm aware that this causes Dxbx to mess up with titles like Turok, Halo, Futurama, and many others. But with the ones that do work somewhat (almost all homebrew, and games like Rayman Arena, Myst and a few others) we have enough work already in improving emulation of those. This work will help us for the time when the symbol-detection improves enough to support more titles, as many potential bugs won't show up then anymore, as we're fixing them here and now already (like what I wrote about above, the various XSokoban issues and pixel shader emulation).

Okay, this has once again become a way too big a post, so I'll just sign off here. Cheers!
 

·
Registered
Joined
·
55 Posts
Wow. You guys got alot of stuff going on! Sounds like you have a handle on the situation. I especially like hearing about the progress on the pixel shader emulation. Thanks for the update.:thumb:
 

·
Registered
Joined
·
45 Posts
Hey Patrick, good to hear that, even though I've been reading every single commit to Dxbx.

Have you talked to Defiance? I think he's done some good work with pixel shaders recently.
 
1 - 3 of 3 Posts
Top