After finishing the new I/O subsystem, I’ve been working with the renderer itself, trying to take the entire good job done in Casandra, and replacing all the bad things with good ones. One of the problems I had with Casandra’s rendering pipeline was the lack of support for multiple render targets, and the poor flexibility for attaching multiple viewports into a same target, or even sharing a same view port between multiple render targets.
So, the last week I’ve been implementing this new render targeting system, focusing on flexibility and portability, without losing the most important thing I want for Cassini: an “easy to use” interface. The only supported render targets at this moment are windows objects, but render textures will be added in the near future.
The input system has also been drastically improved, allowing to attach keyboard objects into different render windows, and grab input data from the current active window, or to do whatever you like to do with input handling, even by creating your custom input handler and attaching it to the window.
With the new render targeting system almost finished and running in both Linux and Windows platforms, I’ll start with the most complex engine component: the render subsystem. I’m currently working with the OpenGL driver, but I’d like to have at least a technology preview of a functional D3D driver for the first alpha.
Once I’ve finished the first alpha of the engine, I’ll probably start developing a GUI editor with different viewports over QT or GTK; this will make development easier to test, and also an excellent way to test the multiple render target functionality.
I leave showing a test sample with four different render windows, each using a dedicated render context, rendering the same scene (a stupid wireframe cube for debugging purposes), but with a dedicated viewport; each render target has a different background color. And the last sample shows a simple render target with four different attached view ports.
Multiple viewports in a single render target.