Rendering has always been a missing part in the C API. This PR fixes this and adds all methods required to get sprites on the screen.
This PR implements:
A FutureResult equivalent for the C API
Methods for the DefaultRenderingSystem, related to textures and entities
TextureInfo support
Methods to retrieve component ids of all built-in components
C struct equivalents for all built-in components
This PR fixes:
405
Concerns:
Is the new LifetimeExtender.h going to work well since we have global static stuff going on?
Should we make it clear for the user that TextureInfo (among other objects) aren't really "created" and "destroyed" per se, but rather tracked using LifetimeExtender.h with a ConcurrentSharedPtr?
Is error handling good enough in NrtFutureResult and NrtTextureInfo?
It looks like Audio already got some components-related code going on. In the future, how should we harmonise the C API for manipulating components?
Rendering has always been a missing part in the C API. This PR fixes this and adds all methods required to get sprites on the screen.
This PR implements:
FutureResultequivalent for the C APIDefaultRenderingSystem, related to textures and entitiesTextureInfosupportThis PR fixes:
405
Concerns:
LifetimeExtender.hgoing to work well since we have global static stuff going on?TextureInfo(among other objects) aren't really "created" and "destroyed" per se, but rather tracked usingLifetimeExtender.hwith aConcurrentSharedPtr?NrtFutureResultandNrtTextureInfo?Stuff to do: