DiligentGraphics / DiligentEngine

A modern cross-platform low-level graphics library and rendering framework
http://diligentgraphics.com/diligent-engine/
Apache License 2.0
3.63k stars 331 forks source link

Poor API design choices affect real usability #261

Closed perkele1989 closed 1 year ago

perkele1989 commented 1 year ago

This issue may come across as rude or nitpicky, for which I respectfully apologize in advance. Creating a well-supported, mature, cross-platform rendering API that makes good use of modern practices is a titanic task to say the least, and expecting there to be a perfect open source alternative for this unrealistic.

A lot of the API design choices in this library make it difficult for me to consider it as a viable option for big projects. In particular, the (ab)use of macros to keep C and C++ codebases compatible, as well as elsewhere (including examples) makes it difficult and finnicky to integrate this project.

The fact that examples use auto everywhere has been a source of frustration, as my IDE at least can't find Diligent references very well (likely due to macro abuse).

Using your own mandatory refcounted utility everywhere also clutters things up and obfuscates memory usage a bit. I already have quite extensive custom memory management (including refcounting types) in the project that I'm integrating this into. I believe to serve the purpose as well as it possibly can, a rendering API should keep these things at a bare minimum (i.e. work with raw pointers or references), with options to support custom memory management instead. Right now it feels like Diligent spills over a lot in terms of area of responsibility (and competes with core engine stuff), although I realize the issue of having to keep resources around is especially difficult with modern APIs, and their reliance on fences etc. to signal that resources are free.

Maybe my usecase is not optimal for what this project is intended to serve, however I'm looking for a high level (modern) rendering API with implementations for DX12, Vulkan etc. that does precisely this and nothing more. Basically a RHI.

Due to these issues, I'm considering to instead go with BGFX to get a running start, and then create other implementations for Vulkan, DX12 etc. down the line, basically creating my own RHI.

Has these sorts of issues been addressed or discussed previously?

Respectfully,

TheMostDiligent commented 1 year ago

By all means please go for BGFX. We don't want to force anyone to use such poorly designed project as ours.

perkele1989 commented 1 year ago

If your response reflects the level of emotional stability one is to expect from the authors of this project, then that is to be considered a red flag when considering to use this for serious projects.

Best,