Open pplux opened 7 years ago
Will be added.
TextureFormat::Enum
will be added to capture callback.
The problem with virtual void capture(uint16_t width, uint16_t height) {
and void performCapture(void *raw_mem, TextureFormat::Enum f);
is that they don't give you any internals from renderer. This might seem like it would work with GL, but it would not since all gl* API calls are inside bgfx::gl namespace. This definitely wouldn't work with D3Dx, VK, Metal where you have device concept.
There are several problems with the current capture implementation for video recording:
The lack of buffering, glReadPixels will block anyone that reads the memory, that probably should be done on a different thread (not the call itself, but the actual read of the memory). I'm aware this is in the pipeline of bgfx development.
Not capturing in the best format available forcing the driver to do format conversion, for example, on Android the best format to capture is RGB565, although, RGBA is supported by the specification that doesn't imply is the best format to capture. The best format can be queried with
On every android I have tested, GL_UNSIGNED_SHORT_5_6_5 and GL_RGB was the result, showing a huge performance boost.
Not allow for platform specific, or user specific methods to bypass default capture method. On android, it is possible to use hardware accelerated video encoder with a given surface to record video. I've tested this with bgfx, and works flawlessly, but the lack of multiple window support for android doesn't allow to render and capture at the same time (We were able to capture bgfx, but not showing render result at the same time)
I'm inclined to solve issue 3, and with that give the user the opportunity to work at his/here own risk. For example the capture interface could be something like:
with an overridable capture method the user have all the control, it can solve problems (1), (2), and (3) and preserves the default implementation.