Week 17/2013: GLSandbox
Last week I was continuing work on the new OpenGL 2 graphics foundation.
With most of the GL2 graphics classes on such a level that all basic functionality is present, I proceeded to try them out in a test application called "glsandbox". So far I've verified that the following features are working: VBOs and different vertex formats, indexed and non-indexed drawing of primitives, changing GL state and operating the state stack, loading textures from QImages, mipmap generation, texture parameters, vertex and fragment shaders, uniforms, building a complete shader program with uniforms and samplers, changing the render target, render-to-texture, resizing the window, and 3D matrix math.
Here's a screenshot from the glsandbox as it looks currently. As is the tradition, it draws a spinning cube with some effects. In this case, the cube on the right uses a texture that mirrors the contents of the whole framebuffer.
I'm quite happy with how the code is turning out. My goal is to put together a set of easy-to-use but powerful and efficient classes that enable a very versatile set of rendering techniques.
Playing around with graphics code has always been one of my favorite pastimes so glsandbox is proving to be a great motivational boost. However, I don't intend to linger here much longer. Now that the GL2 classes seem to be working as expected, I will soon integrate this (lightly) into the client's GUI and begin work on the new UI widgets. The integration will have some challenges, as the old GUI code manages GL state using a different set of principles, and the objective for the moment is to retain all of the old GL/GUI code in its current form, only using the new GL2 graphics in new UI widgets.
During the week I also fixed a Snowberry bug related to profile duplication. We will probably release a 1.10.2 patch in the near future.
With most of the GL2 graphics classes on such a level that all basic functionality is present, I proceeded to try them out in a test application called "glsandbox". So far I've verified that the following features are working: VBOs and different vertex formats, indexed and non-indexed drawing of primitives, changing GL state and operating the state stack, loading textures from QImages, mipmap generation, texture parameters, vertex and fragment shaders, uniforms, building a complete shader program with uniforms and samplers, changing the render target, render-to-texture, resizing the window, and 3D matrix math.
Here's a screenshot from the glsandbox as it looks currently. As is the tradition, it draws a spinning cube with some effects. In this case, the cube on the right uses a texture that mirrors the contents of the whole framebuffer.
I'm quite happy with how the code is turning out. My goal is to put together a set of easy-to-use but powerful and efficient classes that enable a very versatile set of rendering techniques.
Playing around with graphics code has always been one of my favorite pastimes so glsandbox is proving to be a great motivational boost. However, I don't intend to linger here much longer. Now that the GL2 classes seem to be working as expected, I will soon integrate this (lightly) into the client's GUI and begin work on the new UI widgets. The integration will have some challenges, as the old GUI code manages GL state using a different set of principles, and the objective for the moment is to retain all of the old GL/GUI code in its current form, only using the new GL2 graphics in new UI widgets.
During the week I also fixed a Snowberry bug related to profile duplication. We will probably release a 1.10.2 patch in the near future.
Comments
As you may recall, I have been working on the map data components, revising their design to suit our future plans for Doomsday. The first phase of this work, the implementation of component level object-oriented encapsulation and hierarchical relationship/lifetime management was completed and merged to the master for Build 845. There were some initial teething problems but those issues are now mostly resolved.
The Doomsday architecture (and in particular, the DMU API) affords us the opportunity to remodel the map components and their relationships entirely, behind the scenes, while still communicating with the game plugins in terms they are familiar with.
The single most fundamental change introduced thus far is a revised definition for map lines and their sides. In the id Tech 1 model, "linedefs" and "sidedefs" are two independent, however, intrinsically linked concepts. This conceptual relationship being replicated at a code level, also. This relationship model, given the geometric purpose and use of said components has myriad shortcomings, particularly at a code level.
In the revised model, all lines in the map have two conceptual and actual sides. Always. These sides are not independent objects but are instead "sub components" of the line itself. So where previously one had to always be mindful that a line may or may not have a side on one or more sides -- the programmer can now expressively always reference the no longer conceptual sides of a map line.
Other highlights include the introduction of inter object messaging mechanisms (allowing the map components to communicate change notifications directly to one another) and various bug fixes to the BSP builder and map geometry construction (meaning improved support for map hacks).
This past week I have also spent some time cleaning up the BSP builder and addressing some of the design issues which had crept in over the past few releases. This work was merged to the master today.
With this first phase complete and the implementation of the BSP builder clarified, I can now move on to the next job -- extracting the map geometry generation from the old renderer. This is what I intend to focus on over the coming week.