You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In upcoming Dagon 0.11, which will be a step towards 1.0, I'm rethinking some architectural concepts and parts of the API. This work is done in dagon-ng branch. Main points are the following:
Less coupling in module structure. Currently it's a total mess with modules from different packages randomly depending on each other. New structure will have strict layout with modules only depending on lower-level packages:
Renderer reimplementation. It should be possible to easily switch different renderers and output modes (for example, to visualize gbuffer). In current Dagon it is nearly impossible for the user to implement his own renderer without rewriting much of the engine. My idea is to break up the renderer to pipelines and stages which will allow easy extending and reuse of built-in rendering functionality. Also deferred renderer will be improved and optimized.
Reduce shader switches to improve performance. Use entity groups whenever possible.
Post-processing filters will also be ported to stages.
Nuklear integration and Freetype fonts support will be moved to subpackages (dagon:nuklear and dagon:ftfont). Subconfigurations are cumbersome and not very intuitive, so all functionality that depends on additional external libraries should be plugged in explicitly. Core Dagon will depend only on SDL.
I'm not a fan of using third-party rendering lib, here's why:
Additional layer of complexity and obscurity. Pure OpenGL has strictly defined behaviour, it is well documented and supported, while an abstraction layer must have its own bugs and quirks to cope with.
OpenGL is high level enough. Maybe Vulkan or Metal require an additional abstraction layer for convenience and productivity, but OpenGL doesn't. There's little benefit of using an abstract API other than supporting several graphics APIs.
Does macOS support matter that much? It's the only desktop platform that doesn't have decent OpenGL these days. That sucks of course, but that alone is not such a big thumb down for OpenGL. I've written an article on this topic for those who care.
Non-D dependencies can be hard to install on Linux (I already receive complaints about Nuklear). On Windows we can ship all the DLLs with the application, which is very convenient for the user. On Linux we can't do that beacuse shared libraries normally should be installed using the package manager or compiled from source.
In upcoming Dagon 0.11, which will be a step towards 1.0, I'm rethinking some architectural concepts and parts of the API. This work is done in dagon-ng branch. Main points are the following:
dagon:nuklear
anddagon:ftfont
). Subconfigurations are cumbersome and not very intuitive, so all functionality that depends on additional external libraries should be plugged in explicitly. Core Dagon will depend only on SDL.This will be a breaking change. See editor.d for an example of new user-side code.
Status:
The text was updated successfully, but these errors were encountered: