Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Major redesign #54

Closed
29 tasks done
gecko0307 opened this issue May 25, 2019 · 2 comments
Closed
29 tasks done

Major redesign #54

gecko0307 opened this issue May 25, 2019 · 2 comments

Comments

@gecko0307
Copy link
Owner

gecko0307 commented May 25, 2019

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:

dagon-new-package-layout

  • 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.
  • Use official bindbc-freetype instead of custom binding.
  • Use latest versions of other bindings.

This will be a breaking change. See editor.d for an example of new user-side code.

Status:

  • Window creation, event system
  • Scene menegement
  • Asset management
  • Deferred renderer
  • Forward renderer for transparent objects
  • Entities
  • Tweens
  • Built-in shapes
  • *.obj
  • *.iqm (will be implemented as extension)
  • *.asset
  • Animated models (will be implemented as extension)
  • Images
  • Textures
  • Materials, shaders
  • Environment maps
  • Sun lights
  • Area lights
  • Shadows
  • Terrain
  • Sky
  • Water
  • Particles
  • Decals
  • Post-processing
  • Text rendering
  • Nuklear GUI
  • Freeview controller
  • First person controller
@leotada
Copy link

leotada commented Jun 11, 2019

Is there a way to use a rendering engine like this?
May be useful.
http://diligentgraphics.com/diligent-engine/

@gecko0307
Copy link
Owner Author

gecko0307 commented Jun 11, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants