Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current OGL graphics implementation uses a standard
gs_command_buffer_t
as its command buffer. This works since OGL is not thread-safe, and so the command buffer here is simply used to defer API calls onto a single thread. However, this scheme is not ideal, as different graphics APIs have their own concept of a command buffer which is managed on a per-API basis. Furthermore, such APIs allow for legitimate thread safety when using such command buffers, and so we need not defer calls like the OGL implementation. Sincegs_command_buffer_t
is decoupled from the graphics subsystem, there is no way of handling such command buffer work on a per-API basis. Currently, the user simply creates a new command buffer withgs_command_buffer_new()
, and thus the graphics implementation has no way of managing it appropriately. As such, introducing a generic graphics command buffer type for the graphics interface would allow users to define their own custom graphics command buffer when writing graphics API backends.Hence, I've introduced a new
gs_graphics_command_buffer_t
type that allows for this sort of behaviour to be possible. I've also added ags_graphics_command_buffer_new()
for creating such a command buffer, and I've changed the appropriategs_graphics_XXX()
functions to use this command buffer instead of the default one.Currently, for the default OGL implementation, this new type and function simply alias to the default
gs_command_buffer_t
. In the future, when alternative graphics backends are implemented, a simple#ifdef/#ifndef
check can be used to choose the correct command buffer type for each API. I've also tested this change with the existing gs_examples (ex_core_graphics
) and haven't encountered any issues.