Roadmap

[EduApps-CDG]

OpenDX Roadmap:

OpenDX Specific

• Implement on a Open Source game (future)
• Support Android devices (future)

DirectX Reimplementation

Phase 0: Structure [In Progress]

• Device detection
• Window creation through CreateWindow
• Test GPU-specific functions in Direct Rendering Manager
• Make samples work (Depends on D3D9)

Phase 1: D3D9.dll Implementation [In Progress]

• Core D3D9.dll functionality (In Progress)
  • Implement basic rendering capabilities
  • Integrate shader support
  • Develop texture mapping functionality
• Input and Output Handling
  • Implement input device support (keyboard, mouse, gamepad)
  • Develop basic sound output functionality
• Error Handling and Debugging
  • Implement error handling mechanisms
  • Integrate debugging tools for troubleshooting
• Compatibility Testing
  • Conduct compatibility tests with DirectX 9 applications
  • Address and resolve compatibility issues

Conceptual stage

Phase 2: D3D10.dll Implementation [Planned]

• Core D3D10.dll functionality
  • Implement advanced rendering techniques
  • Enhance shader support with geometry and compute shaders
  • Develop support for multi-threading
• Graphics Optimization
  • Optimize rendering algorithms for improved performance
  • Implement support for advanced anti-aliasing techniques
• Input and Output Enhancements
  • Expand input device support for specialized peripherals
  • Enhance sound output with support for advanced audio effects

Phase 3: D3D11.dll Implementation [Future Development]

• Core D3D11.dll functionality
  • Implement tessellation for detailed 3D models
  • Enhance shader support with hull and domain shaders
  • Develop support for deferred rendering techniques
• Advanced Features
  • Integrate ray tracing capabilities for realistic lighting and reflections
• Performance Optimization and Stability
  • Conduct performance profiling and optimize critical code paths
  • Enhance stability through rigorous testing and bug fixing

Phase 4: D3D12.dll Implementation [Future Development]

• Core D3D12.dll functionality
  • Implement low-level access to hardware resources for improved performance
  • Enhance multi-threading support for modern CPUs
  • Develop support for advanced memory management and resource binding
• Cutting-Edge Graphics
  • Implement support for real-time ray tracing for high-quality visuals
• Cross-Platform Compatibility
  • Investigate options for porting OpenDX to other operating systems (macOS, Windows)

Misc

Dxdiag

• User Interface (In Progress)
  • System Tab
  • Translation (Help needed)
• Functionality
  • DirectX version detection

Ongoing Tasks

• Community Engagement
  • Regularly update documentation and tutorials for contributors and users
  • Foster an active and inclusive community through forums and social media
• Continuous Integration and Testing
  • Implement automated testing for each new feature and bug fix
  • Establish a robust continuous integration pipeline for code validation
• Performance Monitoring and Optimization
  • Continuously monitor OpenDX's performance in real-world scenarios
  • Address performance bottlenecks promptly through optimizations and enhancements

[LouChiSoft]

Hi, love the idea and I hope you can go somewhere with this. An open source version of DX for Linux that runs natively would be so useful for the gaming industry as a whole I think. But I do have some questions:

• Why start with D3D9? Other than some exceptions to the rule, aren't most DX games with active player bases running DX11? On top of that as time goes forward more and more people will be working with DX12. Wouldn't it make more sense to start with 11 and then decide from there whether going back for DX9 or going forward for DX12 would be more usable for users?
• You mentioned better performance than using Wine of DXVK, etc. I know in concept by removing a translation layer you have the advantage in the performance department but is there any examples of that being the case? I know the project is in it's infancy, but any concerte examples proving this would lend legitimacy to your claim
• How do you intent to test on consumer hardware? My assumption with be some kind of custom fork of Mesa?

I hope this project really gets some traction, I could simplify so much in game development.

[EduApps-CDG]

Hey, Lou! I'm starting with DX9 because recent versions of DX share a lot of similar functions. Yes, it's correct that new games should come with DX12 and you make me think about it.

Only removing the abstraction layer won't give too much performance. But we can make some optimizations in the code so it can run faster. You want an example, right? In the sense of abstraction, we can say that Java Runtime is just like wine when it comes to execution. Before you run your program, it needs to load the environment, in the case of Java is the Java VM and in Wine we have system DLLs like OLE32 that DX depends on. If the intention is to run it natively, why don't we simplify and optimize it for our needs? Just by removing unnecessary code we already have a (minimal) performance impact. I know it's a bad example but I guess you understood what I'm trying to say.

How can I test it in consumer hardware? Just like everyone does in the open source community. By having feedback, I can fix bugs found in specific hardware.

[LouChiSoft]

Hi, I realise I wasn't super clear in my statement. Hopefully this will clear things up.

You want an example, right? In the sense of abstraction, we can say that Java Runtime is just like wine when it comes to execution. Before you run your program, it needs to load the environment,

Sorry, I didn't mean I wanted a theorectical example. I was asking if you are going to work on a simple application that can prove OpenDX will run on Linux. Even something extremely simple such as a floating/rotating cube and directional light that compiles and runs for both Windows and Linux with little to no changes for the graphics side of things will help prove this is possible.

How can I test it in consumer hardware? Just like everyone does in the open source community. By having feedback, I can fix bugs found in specific hardware.

Similarly to the point above, saying you will collect feedback is a theoretical answer. But I was wondering what your plan to physically test the drivers will be. From my point of view forking and adding support to Mesa makes sense since it already supports so many different cards and once you get support for some cards into Mesa, that is actually something someone can download and test.

Hopefully that clears things up a bit more, thanks

[AshthorneGaming]

I think DX9 is a decent place to start because a lot of software from that era struggles on modern operating systems. Most DX11 software has an alternate OpenGL or Vulkan option.

[sfzaw]

Agree with previous statement. DX9 should be the priority heres few crucial reason

1. Game preservation - https://www.pcgamingwiki.com/wiki/List_of_Direct3D_9_games
2. vulkan not supported on many laptop gpus including older iGPU. many of these hardware are coming to linux from windows for obvious reason and finding out that their favorite old games wont run properly on linux. consider them millions in numbers
3. one of the most popular dx version that set up milestones for later dx versions
4. far more important than other dx versions as newer dx gpus usually includes vulcan as alternative than dxvk
5. suspended development of gallium nine - https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg224815.html

I am curious though, is the project abandoned?

[Ahmed-Dzair-Dev]

I with the idea of starting from dx9 .