Why 3D is bad for me
The goal of this project was always to make a game. Specifically, to make a top-down, side scrolling shump type of game. The previous old code entries talked about ripping out superflous stuff and pulling the project back to the essence of what 2004 me was trying to achieve.
I started looking into modernizing the codebase to a newer version of OpenGL, one that moves away from immediate mode and into the realm of shaders. I created a new branch called
opengl-upd and set to work, ripping out the current stuff and adding in magical things that I was basically learning as I went from a ‘modern’ OpenGL tutorial.
It turns out that for me, someone who hasn’t touched graphics programming of any kind since the late 2000’s the leap is huge. Rendering was broken for a very long time in that branch. Getting a triangle up took a while and I eventually got the (untextured) models loaded and showing - however the camera system was totally screwed.
As part of this update, I realised I’d broken one of my core tenants in this project - that of refactoring - keeping the existing stuff working as I evolved the code. The old rendering system just wasn’t compatible with the newer code so I had a black screen for a long time - something which wasn’t desirable.
Sitting back and reflecting on this I realised that I was spending a lot of time learning OpenGL and not actually progressing with the original goal of having a working game. This was compounded by my lack of 3d tools knowledge (MilkShape 3D is defunct now) and I realised I’d have to learn Blender and other tools. It got me thinking, if I was doing all this - I could just quit and use Unreal or Unity as it has all the 3D features I’d want, for free.
Stripping it back
With this in mind I decided to abandon the OpenGL update branch and go back to something more basic. I want to get some simple game built here, not mess about with tech and tools forever.
Not only am I abandoning ‘modern’ OpenGL, but I’m going to abandon OpenGL entirely in favour of a sprite-based system using SDL2.
Swapping over to sprites allows me to crudely draw my own graphics and render them up relatively quickly, allowing me to focus on building out the game itself instead of worrying about graphics tech.
The goal here is to be able to rip out the 3D stuff and swap to sprites without breaking what’s there - thankfully there’s actually very little there right now.
I could approach this in two ways; the first would be to have a combined approach, whereby sprites are rendered alongside the 3D stuff. The second would be to keep them completely separate. I decided that for my own sanity, I’m going to keep the concepts totally separate - I’ll keep the 3d stuff running until the sprite systems are at parity, then I can remove the 3d stuff entirely.
To do this, I’ve implemented a runtime toggle - basically when the game starts up it reads a configuration file and runs in OpenGL mode or SDL (Sprite) mode.
Based on this mode, we now instance either a
GLRenderWindow or a
SDLRenderWindow. Both of which are entirely separate and deal with their own types of rendering.
We still have a problem, however. A lot of the old code that was ported over to the component system means that components are responsible for rendering themselves. So the Camera, Model and even the Collision components have some OpenGL code in them. This code is easily lifted and shifted into a specific
Renderer system for the type of stuff we’re doing. It also means that the rendering code becomes consolidated in one place and that components lose their awareness of how they get rendered. This is a good thing.
Next up, we need a set of classes and components to mirror the current 3D components. These will be:
Sprite- To hold the sprite info (equivalent to
SpriteManager- Equivalent to
ModelManager, allows loading of sprites from config
SpriteComponent- Associates a
Camera2Component- A 2D camera component
SpriteRenderer- Renders sprites
Time to get cracking on all this. Hopefully I’ll have something to show soon.