Start of the graphics rework

This week I started working on the graphics component of the engine, which is probably going to be the biggest task of the project. There’s a lot of code to look at and trying to understand what is going on has been the biggest challenge yet.

The first thing I worked on was the LowLevelGraphicsSDL class which implements some immediate mode drawing functions (through the opengl fixed function pipeline), the creation and management of the main rendering context and the creation of textures and vertex buffers. This class is also used for retrieving opengl information like the availability of vertex buffer objects or the possibility to use shaders. The last part was a surprise since I’ve always taught that the engine required shaders. Turn out thought that if these are not available, or the game’s graphical quality is set to the minimum (very low), it will run without them. It’s a pretty bad experience – basically a horror game without lights – but at least it’s playable.

Next, I worked on implementing the SDLTexture class which went smoothly with only a few problems that were resolved in little time, though I haven’t yet had the opportunity to fully test it so more problems will probably appear in the future.

To check for bugs in the opengl calls I’ve implemented a couple of macros that call glGetError and print a message when necessary. In the meantime, someone else implemented the same thing, but with more features in graphics/opengl/debug.h so in the future mine will be replaced.

The last thing I completed this week was the VertexBufferVBO class which was a similar experience to the texture class mentioned above. This class is one of two vertex buffer classes, the previous one implemented in terms of vertex buffer objects (an opengl construct, usually shortened as VBO), while the other one, VertexBufferOGL, is implemented without VBOs and can be used in opengl versions under 2.0.

After working on the previous task, I started working on shaders. The engine used CG, a toolkit made by nvidia that has now been deprecated, for what I assume is the ability to work in opengl versions under 2.0, where opengl’s shaders were not yet available. CG’s shading language is similar to GLSL (and more so to HLSL, the directx equivalent), but the two are not compatible so in the future I will have to translate them. Between the two there’s not much difference, except for different data types and different names for some operations. In engine code a big difference between using CG and GLSL is that CG’s shaders can be bound independently. This is in contrast to opengl in which the vertex shaders and the fragment shader must be linked before they can be used.
This task was the most difficult this week and made me realize that I understood far less about the graphics system than I though. Although some opengl operations are very similar to what I’m familiar with, others I haven’t fully understood, which has caused me some headaches. For now, I’ve given up and since they are not necessary for the game to start, I will come back to them in the future, once I’m more familiar with how the engine works.

Next week I will keep working on graphics and hopefully get some part of the game to display, although I don’t yet have a clear idea of what that would require.

Thanks for reading.

Leave a Reply

Your email address will not be published. Required fields are marked *