No, actually ATI is worse off - mainly related to unsupported texture formats (and combinations thereof), but also weird behaviour in the area of index & vertex buffers (which I now emulate somewhat differently than before).
I'm going to try and fix most of this though, as what I said before : The ultimate goal of this exercise is to get everything running like it did before, just with less patching.
As a nice side-effect I can already see this allows specific scenarios to run better than before (or actually run at all) so that's a nice & welcome bonus! (Note, that it might not help at all for games, but let's just see how we fare before jumping to premature conclusions!)
Oh, I can't believe I missed this. Nice progress on NV2A emulation.
How are you handling screen updates? I can't get the threading + OpenGL in my emulator to work properly to save my life. Otherwise, it would be working. Are you still patching Present and Swap? Or are you emulating VBlank yourself?
Yeah, present/swap is still patched, as is much of the state-setting - but once I figure out a way to access the Xbox g_pDevice struct version-independently, I can remove many of those too (like all 32 SetRenderState variants, and most get/setters for RenderTarget, DepthStencilSurface, etc etc) as all these don't really access the GPU yet.
All they do is set a few state variables, trigger a dirty flag, push some commands to the pushbuffer and that's about it. Since I let CreateDevice run unmodified (this just needed a few patches on CMiniport), most of the normal initialization (framebuffers, default render states, etc) the pushbuffer is also initialized, and is allowed to be filled.
I use a separate thread to reset the pushbuffer start pointer, so that busy-loops are quickly ended, allowing the original code to continue just as if the GPU handled the instructions.
Right now this 'resetter' thread ignores all pushbuffer commands, but once I have everythig running like before (and get this darn big patch committed) I intend to start interpreting the pushbuffer commands, and emulate it at that level. This means that all Draw[Indexed]Vertices[UP] can then be left unpatched too!
As a sidenote, I've also devised another method to emulate quadlist and line-loop drawing (still under d3d8) which doesn't need any vertex buffer patching (yeah!).
This improves a few cases that where showing garbled textures, so that's a big win too.
Oh, and I let the Xbox code have it's own resource-memory, so Register is not patched anymore too. I unswizzle (and do P8>RGB conversion) only when updating the native textures. This was quite a big thing actually, especially for cube & volume textures - getting all offsets right (for all mipmap levels, for all formats) took me a while, you can imagine!
Right now, I'm working to restore some missing graphics, then I have to re-implement overlay support, and by then I hope to get some games running again.
Once I get there, I'll commit this monster-patch and let you all see how I did this (it's not really all that difficult once you see it).
The change was quite small - we fixed two small problems that made Dxbx fail on (32 bit) Windows 7 machines, that's all.
The good news is, that with these two fixes, Dxbx can run a few XDK samples under Windows 7. (We didn't test toroughly, but the few games we can run on XP don't work, alas.)
The bad news is, that my new (lower) form of emulation breaks on Windows 7, as it somehow doesn't let us trap the execution of illegal (ring0) instructions anymore.
(If anyone knows why the Windows 7 API AddVectoredExceptionHandler doesn't handle STATUS_PRIVILEGED_INSTRUCTION anymore, please tell!)
At any rate, I'm currently working on improving the memory management code - as it turns out, having reliable memory allocation code is of paramount importance for reliable emulation. (No real surprise there.)
Right now, apart from 2 cases, all XDK graphics samples run again. There are still some speed issues (I recreate vertex buffers on every draw - not very efficient) but after adding a cache this should perform well enough.
Oh, and I got overlays working again (both hardware and software emulation). Turok reaches it's menu again, but it's completely messed up for some reason. Other games do nothing yet, so I still have a few issues to fix.
Anyone wanting a peek at the code can request the patch, just mail me.
That's it for now - I'll be back with some more screens and explanations later.
Yeah, I read these too, but there's nothing conclusive in there (and no mention of a change in AddVectoredExceptionHandler behaviour).
Talking about Windows 7 - it seems to be full of odd (I wouldn't call it buggy) behaviour: The UndecorateSymbolName API turned out to be very picky on the arguments you pass it. Before, we called that particular API with a set of flags that seemed sane at the time we wrote it, but on W7 that messed up the output completely! After a little bit of prodding we found out that the UNDNAME_NAME_ONLY flag shouldn't have any other flag beside it, or W7 would just leave our portions of symbol names, or generally just turned the output into a complete mess. Luckily, the UNDNAME_NAME_ONLY flag alone is also enough on XP, so I'm guessing Vista will be fine with that too.
The things you have to deal with sometimes.... really tiring....
technet.microsoft.com is a perfect source of help not only for the amateur users ranging from issues like forum threads on compatibility fixes to what you can do in any of Win Xp, Vista, & 7; but also for the developers where there are articles on the different programming possibilities and issues in each OS.
Using the IgnoreException Fix
Right there, 4th from bottom of the exception list is "PRIV_INSTRUCTION". Maybe what you're wanting to do can be done, but that they changed the wording of the exception.
I searched for the API term "AddVectoredExceptionHandler" within the "Search all sources" box under the "Troubleshoot an Issue" headline. Not hard, :heh:!
@ObiKKa : Thanks for doing some research, but alas this doesn't give me any more insight.
It looks like the behaviour of AddVectoredExceptionHandler has changed in Windows 7, but I can't find a (reliable) description of any possible changes in this API. All I know is what I see; Different behaviour compared to WinXP - no more trapping of STATUS_PRIVILEGED_INSTRUCTION (or so it seems).
For now, I'm going to ignore this, as I have no easy access to a W7 test machine. There's enough work to do already on XP, so I'll try and concentrate on that first.
(I'm currently taking a break from Dxbx - I've been working on it for about 3 hours every night for more than half a year now, so you can imagine I need a few days rest...)
Well, this code does compile - but it's not suiteable for a new release.
I submitted this, since Shadow_tj was being hindered by the fact that my patch wasn't available from the SVN. So we settled for a intermediate solution : I copied the source-tree, but the second version I updated with my latest sources. This way, we can keep adding bits and pieces to the original version, and let more people have a look at the changes that I did to arrive at a somewhat lower level of emulation.
I'm currently doing a little experiment, to see if I can remove most of the leftover D3D patches by emulating pushbuffer commands entirely. I'm starting simple - I'm trying to get the CreateDevice sample running with this (which does nothing much more than initialize the D3D Device and calls Clear and Swap). There are a few problems to solve, like when I should actually create my native D3D Device, and how I should read the Xbox render target and other state. But I *think* this could work, I have encountered no real showstoppers as of yet. So these are very interesting developments, as it would mean we end up with zero D3D patches - which would be very valueable with regard to LTCG titles! But let's not jump the gun, it's still an experient, and it would mean decoding & emulating some 300 GPU commands, so lots and lots of work! (But quite interesting, as it borders on real low-level emulation!)