search

gecko0307 / dagon

3D game engine for D
https://gecko0307.github.io/dagon
Other
321 stars 30 forks source link

Vulkan support #68

Closed ghost closed 1 year ago

ghost commented 3 years ago

It would be really cool if Vulkan was supported in dagon. This would allow dagon to run on Apple devices, and there are active bindings for Vulkan (ErupteD). This would be way later down the line because of the amount of work that would have to be put in, but I think it is essential to implement support for Vulkan.

gecko0307 commented 3 years ago

It is possible that the engine will be ported to wgpu some day in the future, or to similar API. I'm against using Vulkan directly, there should be an intermediate layer with multiple backends.

ghost commented 3 years ago

It is possible that the engine will be ported to wgpu some day in the future, or to similar API. I'm against using Vulkan directly, there should be an intermediate layer with multiple backends.

Why are you against using Vulkan directly? Just curious.

gecko0307 commented 3 years ago

Doing that will tightly bind the engine's logic to Vulkan's structures and execution models in their current state of affair, which is IMO a bad thing in the long run, because the API is new and will most likely change. Due to the specificity of Vulkan's architecture, it can't be easily "added" to an existing single-API engine like Dagon (OpenGL functionality doesn't map one-to-one to Vulkan, the engine would be heavily adapted and rewritten in many places). So before adopting Vulkan, Dagon should be decoupled from OpenGL first, there should be some mid-level graphics library with platform-specific code at the backend. I had a plan to write it in the past, but currently I don't think that's practical anymore because there is wgpu, and it is exactly what I need.

Another point is design. Using a low-level API directly is a good idea if the application has predictable behavior and can be optimized in every possible way, which means it's codebase won't provide a framework-style environment for customization and extending. Dagon is a bit different, I tried to design it in such way that there's little hardcoded behavior. It can be used in different ways, it's even possible to ignore 3D functionality and make GUI apps with it. In such context, I think rewriting the engine to Vulkan is excessive, there will be tiny benefit. On the other hand, rewriting it to wgpu will take a lot less effort and will make more sense because of automatic support for all major APIs, not only one.

ghost commented 3 years ago

Yeah, that makes sense.

aviallon commented 2 years ago

Why not using gfx rs instead ? I think it is more mature than wgpu.

gecko0307 commented 2 years ago

Does it have C interface? I thought it was native Rust library. wgpu's internals, AFAIK, have been forked from gfx-hal, so I think they are now close in terms of stability (I didn't really compare them, though). Of course it would be nice to have a choice, but wgpu currently seems like the only cross-language option.

aviallon commented 2 years ago

https://github.com/gfx-rs/portability

aviallon commented 2 years ago

And wgpu is actually built on top of gfx-rs, which is lower level.

gecko0307 commented 1 year ago

Closing the issue due to the fact that, if such a port will ever happen, I won't use Vulkan directly anyway.