-
Notifications
You must be signed in to change notification settings - Fork 0
Engine Subsystems
This page contains a list of the various subsystems of Argus in its current state.
Basic utility library used throughout the engine, with some responsibility for abstracting platform-specific implementations of low-level features like threading or filesystem access. Some of its more important features include memory allocation, math structs/helpers, logging, and handle management.
Helper library for shader processing. Currently exposes a single function for converting a set of GLSL shaders to their respective representations in SPIR-V. This helper is written in Rust and exposed via FFI and a simple C++ wrapper.
Miscellaneous procedural macros for use in Rust code across the project.
Provides procedural macros for automated type/field/function binding for the scripting module. This encompasses two other crates, scripting_bind_macros and scripting_bind_types, which provide the actual macro and type definitions respectively.
Central engine subsystem responsible for bringing up/tearing down other modules, executing update/render callbacks, and dispatching events.
Basic entity-component-system implementation. Currently not in use by any other part of the engine.
Subsystem responsible for resource management. Other subsystems may register loaders for specific resource types which will be automatically used when such resources are loaded.
Subsystem providing a framework for a scripting engine. Provides functions for loading scripts, invoking functions from them, and binding C++ types and functions. Also provides a framework for plugins which may register themselves to handle these functionalities.
Temporary module for initializing script bindings registered via scripting_rustabi. This is necessary due to the Rust ABI utilizing proc-macros for binding registration in lieu of each module explicitly registering its own bindings during initialization. Eventually this will be folded into scripting once it has been rewritten in Rust.
"Window Management" subsystem responsible for determining display capabilities and creating/destroying windows as well as abstracting window events for dispatch to other subsystems.
Subsystem providing an abstract scene graph implementation as well as interfaces for interacting with render surfaces and attaching viewports of scenes to them. Also provides representations for textures, shaders, and materials as well as helper functions for compiling scene graphs down to a flat structure.
Subsystem responsible for abstracting input events. Allows other subsystems to map physical keys/buttons/axes to arbitrary strings which are then passed back to event listeners instead of physical input information.
Stub module, for the time being. Will obviously be responsible for audio playback.
Stub module, for the time being. Will obviously be responsible for constructing and rendering user interfaces.
Subsystem providing an abstract game world representation. Currently provides constructs like sprites, background layers, static objects, and actors.
Scripting backend for the Lua language.
Currently mostly stubbed. Intended to provide a scripting backend for the AngelScript language.
Render backend targeting modern OpenGL. Requires support for OpenGL 3.3, but can use OpenGL 4 features as well as extensions if available.
Render backend targeting modern OpenGL and written in Rust. This is a direct rewrite of render_opengl and will ultimately supercede it.
Render backend targeting OpenGL ES 3.0.
Render backend targeting legacy OpenGL. Requires support for OpenGL 2.0 as well as GL_EXT_framebuffer_object and GL_EXT_framebuffer_blit (which are apparently supported by virtually all cards supporting GL 2.0).
Render backend targeting Vulkan. Currently a work-in-progress and is generally less performant than the GL/GL ES backends.
Simple bootstrapper for the engine. Accepts a single command line argument specifying the namespace to be used. It will attempt to load client.json as a resource under this namespace and proceed to spin up the engine according to the configuration inside.
A number of *_rustabi modules are provided to expose Rust bindings to modules otherwise written in C++. For the most part these are just ergonomic shims over the respective C ABIs (which in turn are shims over the C++ ABIs).