Port to Direct3D 9

[PatrickvL]

Currently, Cxbx is using Direct3D 8, which imposes a few limitations that are lifted with Direct3D 9. Dxbx (here on GitHub) already contains much of the required changes, so we can start by porting that back to Cxbx (see https://github.com/PatrickvL/Dxbx/search?utf8=%E2%9C%93&q=DXBX_USE_D3D9&type= for all related Delphi code).

Because a port like this is going to be a lot of work, it's wise to do this using either a compiler define as a switch, or using a runtime setting (either via lots of if statements, or the right way, by moving all drawing code towards a C++ class).

Area's that will be hit:

• texture formats
• calls to drawing API's
• conversions of d3d resource buffers
• shaders

[LukeUsher]

Note that we should strive to completely remove DirectX8 support as it is no longer supported by Microsoft and could cause issues with future versions of Windows and/or visual studio.

DirectX9 is still supported in the Windows 10 SDK, so that's not a problem, although D3DX is deprecated so we should (eventually) work towards removing our use of those APIs too.

[blueshogun96]

I personally recommend at least OpenGL 2.1 since the NV2A's hardware registers more closely match it. Plus the need to manually patch vertices for unofficially supported primitive types is quite inefficient and causes major issues, especially for Robotech Battlecry. With OpenGL, texture and other resource updates appear to be more practical, and several more texture formats available. Non power of two textures also won't be a problem as well as longer vertex shaders being possible. Some shaders we cannot convert due to D3D8's limitations.

Furthermore there's features that OpenGL has supported that Direct3D has never truly supported until now, especially when it comes to synchronization. Example, D3DDevice_KickPushBuffer() and _BlockUntilIdle() are the equivalents of glFlush and glFinish, respectively. OpenGL also supports fences. But of course this is just from a high level perspective. There's more, such as a cheap and dirty way to emulate _BeginPushBuffer() needed by MGS2 and Spy vs Spy, but I want to hear what everyone else has to say.

[bhodg22]

Soemtimes when I run JSRF on windows 10 i get slightly different results, character might be missing parts or parts of the level are missing, sometimes the shaders are also different, try running the games a few times

[bhodg22]

Have you had a look at the JSRF issues? some people were testing under windows 7 and 10 there

[LukeUsher]

Not only is this a ridiculous amount of comments in such a short time (please, just update the first one rather than post this many times in a row) the information you have given is not at all useful and is just plain wrong.

Windows 7+ have full support for DirectX 8, if it didn't, much more older software and games would fail than they do now. It is true behavior differs in Cxbx-Reloaded based on Windows version, but a large portion of that is the amount of undocumented functionality we use in the kernel, which Microsoft can change the behavior of at any time without warning. We have an issue for that already #3.

That said, it's also likely the issues are caused by differences in the installed graphics drivers, perhaps they interpret certain data structures differently. The fact these issues exist at all are proof that we still don't have our graphics emulation quite right yet, the same problems would exist (but perhaps manifest differently) regardless of the API we use.

Also, regarding the C++ packages: If these are missing or incorrect Cxbx-Reloaded wouldn't even start, it wouldn't even get as far as the GUI, so that has nothing to do with the problem either.

Regarding the Cache files: That is a valid concern and it is possible that there are some filesystem bugs remaining in Cxbx-Reloaded, however, this has nothing to do with what API we use either.

I (we) appreciate bug reports and helpful comments, but posting this many comments in one go just spams the issue tracker, and is not helpful at all.

[LukeUsher]

DirectX makes calls to the driver which then accesses the hardware. But this still doesn't mean the issue is with the directx API we use, there are countless differences between Windows versions. Even differences in memory layout can effect Cxbx execution, things really aren't quite right yet and they manifest in many different ways. The graphics corruption is the emulator doing something wrong, it just had a bigger impact on some versions of Windows than others. Once we solve the root of the problem it will render fine on all operating systems, but we are still investigating the root cause.

[PatrickvL]

Could be that Windows 10 allocates normal and aligned memory differently, which could in turn result in different behaviour when buffer overruns occur. Thread switching could be different. Timers could have different granularity and/or precision, etc. There are numerous possible reasons. But I believe it doesn't matter, as there's clearly a vertex buffer and/or shader regression at play here; We haven't found the cause yet, but games like Futurama and Turok, and also the dashboard, once didn't show the glitches we're experiencing currently. I suspect that once we fix that regression, most vertex related render bugs will disappear, regardless which Windows version you're running Cxbx on.

[PatrickvL]

Are you saying you're going to do the port to direct 3d 9? Be prepared to spend a LOT of time on shader conversion then. But you've got my blessing to pick this up and get Cxbx ported to 9!

[ObiKKa]

Hey to newcomer. Nice to see more and more people possibly joining this team! By the way, let me teach you a few tips. Just press the 'Prt Scr' (Print Screen) key at the top right of your keyboard and you'll capture what's on screen; then paste it in a good image editing software like the freeware paint.net (basic paint version on Windows is crap), maybe irfanview; or even the free online 'sumopaint' tool (Kinda like classic Photoshop. Can save files to your PC.).

Then just crop to the emulator's perimeter and save the image then send them over here. No need to take photos with a mobile phone/device. Easy, huh?

• New reply to below's response: Yep, tried it just now. Lol, I hadn't known that.

[PatrickvL]

Doesn't Alt+PrintScreen grab just the active window? No need for cropping then

[LukeUsher]

On that note, alt + the print screen key captures only the active window, so no need to do the cropping

[blueshogun96]

Okay, since this thread is constantly derailing (and blowing up my inbox with notifications), let me attempt to bring it back on track one more time by suggesting OpenGL instead of Direct3D once again.

There was a wrapper that someone had been working on back in the early 2000s called dxglwp, which translates Direct3D8 calls to OpenGL 1.x. Although it was never a full implementation, I do believe it's worth considering since it's not only open source, but it does work well enough as a starting point. Furthermore, it can be used as a means to implement a library that essentially would be the equivalent Xbox Direct3D, where we can natively support most Xbox exclusive features right out of the box. No more need for primitive patching, no more missing synchronization functions and no more missing render/texture states that Direct3D does not, never has nor never will support. Not to mention the possibility of translating xvs/xps1.1 to GLSL since we can have a MUCH easier time debugging that. And if we ever need D3D9 for anything specific, there's OpenGL extensions that can give us interoperability with Direct3D9.

Although the approach I had in mind would utilize a handful of NV specific things, not too much would ultimately be vendor specific. We could even take the entire D3DPIXELSHADER_DEF structure and create a register combiner from it without the need to convert to a fragment program if we wanted, while converting the existing vs1.1 code to arbfp1.0 if need be.

Of course, this is all just an idea. I started on it once but was too lazy and unfocused to continue it. Plus I don't know for sure how thread safe it would be. You see, the talk of jumping to a different API happens all the time (even back in the day when sir caustik was active), but when is it actually going to happen? :)

Shogun.

[x1nixmzeng]

There are several compatibility-layer libraries out there. Valve did this to port DOTA for SteamOS and open-sourced their library: https://github.com/ValveSoftware/ToGL

Here's a recent library to convert between DirectX 9 and Vulkan, which superseeds OpenGL: https://github.com/disks86/VK9

[Logitech-byte]

hmm... on demul, the dev. was forced to emulate games throw DX11 because DX10 to DX8 it have serious problems in the past. Now it's up for you guys. It will be amazing if DX8 get's fixed, a lot of people don´t have DX11 yet. (I think)

@PatrickvL the keyboard in italy the print screen button doesn´t exist or is changed to italian name or move to a nother position 👍

[mirh]

I think you are looking at the wrong wrappers up there.
https://github.com/crosire/d3d8to9
https://github.com/adolfintel/wined3d4win
These are likely to be interesting to the project

@HyperScorpio Stamp R Sist

[donwayo]

Could this be implemented in such a way that switching between DX8, DX9, and OpenGL can be done at runtime? For example in a plugin-like way.

[PatrickvL]

Well, everything is possible, but for now it's unlikely.

For HLE graphics, we're using Direct3D 8. This HLE code could be converted into using Direct3D 9. Either using conditional compilation (so we can choose to compile for 8 or 9), or by just replacing everything (but then we can't do it gradually - we must submit the conversion in one big change).

For LLE graphics, it's very likely that the first implementation will be a port of xqemu's NV2A renderer, which is using OpenGL. Once that works well enough, we can start considering Vulkan - and that could be build as a configurable renderer (so run with either OpenGL or Vulkan).

However, my gut feeling about plugins is, that they are more trouble than it's worth. For the forseable future, I think we'll just compile everything in, and use settings to choose (like we already do, using the HLE/LLE GPU flag).

[mirh]

Pcsx2 has no problems into choosing (at runtime!) either dx9 or dx10/11 backends, for the records.
Not sure why conditional whatever-ing instead of duplicating the thing and developing it in parallel?

[BelleNottelling]

@mirh pcsx2 is also a much more developed emulator that has gotten more love than Cxbx-Reloaded 😁. Direct3D 9, openGL, Vulcan, and any other graphical API aren't really something I would expect work on for a while, remember most games can't even get to the menu and even less are in game. Efforts right now should be on emulating more of the xbox kernel, improve conversation of different things (such at textures) and getting as many games as possible to boot. (Like what's the point of using a newer graphics API if most games don't get far enough for any difference to be seen)

[PatrickvL]

More work on this issue was done here : #1071 - this Pull Request introduces a new Build Configuration (called "Debug_Direct3D9") and a load of #ifdef CXBX_USE_D3D9's to select between Direct3D 8 or 9. Also aliasses are defined so both paths can reference the same symbols. This won't compile fully yet, but at least it's a step in the right direction.

[PatrickvL]

Note : the d3d8to9 suggestion @mirh made has also been applied, meaning that our Direct3D 8 based code is forwarded to Direct3D 9, allowing more recent drivers to be used.
Even so, it's still advisable to convert our code-base to using Direct3D 9 directly, because it offers more features that Xbox has (and Direct3D 8 lacks).

[mirh]

Well, I guess like retroarch guys would still quite love having direct D3D8 support /s

[LukeUsher]

This is done now in development builds