-
Notifications
You must be signed in to change notification settings - Fork 627
Subsystems of OpenTK
This is OpenTK's mathematical subsystem. Vectors, matrices, trigonometry, you name it. OpenTK.Math is the foundation for the rest of the library's mathematical operations, and is vital to the graphics and sound subsystems.
The audio subsystem exposes API to play and record sound in 3D space. At present, it uses OpenAL to do so. It's one of the more decoupled subsystems, and as such, it's already been broken out of the legacy code.
At present, it serves as a concept implementation of a subsystem using ADL, and needs both review, testing, and discussion from anyone adopting a subsystem.
This subsystem is the biggest and most widely used of them all. Our graphics subsystem exposes various graphics APIs to the end user, allowing them to draw things to their heart's content.
The graphics subsystem can be considered one of the most operation critical ones, and we'll need multiple people to adopt the various profiles inside of it. In the future, we also hope to exposed Vulkan as an available API under this subsystem.
This subsystem contains, in separate namespaces, OpenGL APIs for the various versions in the main OpenGL specification.
Much like OpenTK.OpenGL, this subsystem contains a similar layout, but for OpenGL ES.
Much like OpenTK.OpenGL, this subsystem contains a similar layout, but for OpenGL SC. Being that it wraps a security critical API, this package should mirror security and safety stringency.
Much like OpenTK.OpenGL, this subsystem contains a similar layout, but for Vulkan.
Current adopter: @daerogami This subsystem provides window creation utilities to the subsystems that require them (i.e. to allow interoperability between Graphics and GLFW.) This will be done through the Graphics Library Framework (GLFW.)
Current adopter: @DylanFPS dmp9biz@gmail.com
The Compute subsystem exposes OpenCL to the end user. It has never been completed, and only generic scaffolding exists to support it. It is a low-priority subsystem, but would be nice to finally implement.
Input is a vital component of any game or graphical application, and as such OpenTK has traditionally exposed certain controls for accepting user input. They have, however, been tightly tied into the platform's windowing system, and we'd like to explore the possibility of offering an abstraction over this to decouple ourselves from the underlying platform.
This subsystem is part of a suite of supporting tools that help us work with OpenTK. The binder consumes API specifications in XML format, and generates C# source code that the rewriter later uses to create working implementations.
Being an internal subsystem, it is not packaged for public use.
The rewriter is one of the more arcane parts of the library, and it acts as a secondary compilation step where it manipulates the IL of the compiled assembly, creating custom optimized implementations of the methods the binder has generated. It utilizes indirect calling and some lesser-known techniques to support various forms of generics.
Being an internal subsystem, it is not packaged for public use.
The translator takes the raw API definition from a source (typically the Khronos repository) and translates them into a common format used by the binder. At present, it rolls a lot of the translation itself, and would benefit from XSD and a more modern way of transforming XML from one format to another.
Being an internal subsystem, it is not packaged for public use.
The Core subsystem is the shared hub of code that all subsystems have access to. This includes things like exceptions, abstract base classes that multiple systems use, instantiation patterns, et cetera. The Core subsystem should not depend on any other subsystem, and should be safe to include in any project.
It is meant for internal use, and shouldn't be installed by users directly.