This second post this week, is to make up for the very very high likely-hood that there will be no post next week due to work and such.

It’s gotten to the stage where the editor could do with drawing some stuff, stuff like markers to show the position/size of the currently selected node, and this raises an interesting problem. It would also be good for game-nodes to be able to draw debug graphics, from anywhere in their update loop (or functions called from that).

So, I have need of a way to store rendering commands for later use, my idea was to have some form of buffer that is cleared every frame, and methods to add common shapes to that buffer (rectangles, circles, etc.). Due to the way that scenes work in Tyr (there can be more than one scene active at the same time) I need a buffer per-scene, and a global buffer, for things like the editor who will want to draw out-side of a nodes update loop.

Now, the simplest method of drawing shapes with OpenGL is with the glBegin and glEnd methods, basically, you call glBegin, passing it a mode (To draw lines, quads, triangles, etc.) and then repeatedly call glVertex, glTexCoord, glColour, describing the geometry you’d like to draw. So I decided to create a class that holds to std::vectors, the fist one is a list of commands (to be passed to glBegin) and an index into the second buffer, the second buffer will hold only floats, used to express the colour and vertex positions of the items I wish to draw. I made the decision that any primitive drawn by this debug-drawing code will have all vertecies drawn in the same colour, to save on the amount of information I’m saving (and to stress that this is for debug-only drawing, since it will be rather slow).

Primitives are added to this buffer by calling one of several methods (DrawRect, DrawCircle, etc.) all of which take a RGBA colour, and the relevant per-primitive information, this calls internal methods to add commands to the command list and float to the float list, this is all done so that the drawing code can be as simple as possible.

void Renderer::Render( DebugBuffer* pBuffer )
{
	glDisable(GL_TEXTURE_2D);
	glDisable(GL_DEPTH_TEST);
	glBindTexture(GL_TEXTURE_2D, 0);
	g_ShaderManager.Bind(INVALID_SHADER);

	size_t commandIndex = 0;
	size_t floatIndex = 0;

	while(floatIndex < pBuffer->m_FloatList.size())
	{
		GLuint startIndex = pBuffer->m_CommandList[commandIndex++];
		TYR_ASSERT_MSG(floatIndex == startIndex, "Start index does not match current float index");
		GLuint command = pBuffer->m_CommandList[commandIndex++];

		// Grab the colours
		GLfloat red	= pBuffer->m_FloatList[floatIndex++];
		GLfloat green	= pBuffer->m_FloatList[floatIndex++];
		GLfloat blue	= pBuffer->m_FloatList[floatIndex++];
		GLfloat alpha	= pBuffer->m_FloatList[floatIndex++];

		// We should end before the next set
		GLuint nextStartIndex = commandIndex < pBuffer->m_CommandList.size() ?
								pBuffer->m_CommandList[commandIndex] :
								pBuffer->m_FloatList.size();

		// Draw it
		glBegin(command);
		for(;floatIndex < nextStartIndex;)
		{
			float x = pBuffer->m_FloatList[floatIndex++];
			float y = pBuffer->m_FloatList[floatIndex++];
			float z = pBuffer->m_FloatList[floatIndex++];

			glColor4f(red, green, blue, alpha);
			glVertex3f(x, y, z);
		}
		glEnd();
	}
}

This is the code that renders a DebugBuffer, it simply loops through the commands, grabbing the needed floats from the float buffer that are then used to render the primitive. Each command knows the index of the first float that it needs to access (the red value for the colour) and by looking ahead to the next command, we can get the total number of floats that command uses.

The system as it stands seems to work quite well, as I mentioned earlier, each scene has it’s own debug buffer and there is a global one too, the rendering order is scene (and child nodes), the scene’s DebugBuffer and finally the global DebugBuffer, so that the debug information is always available (I may have to alter this when I add support for post-process effects, as those will want to be applied before the debug rendering. I also need to extent this method to allow the rendering of text, but I’m not entirely sure how to go about doing that one yet. This system is rather new (it was implemented mostly on Saturday night) so it may change over time when it is used more extensively.

There was no blog post last week, sorry about that, but truthfully I’d not really done enough to justify one, it was a week of research more than coding, but I did find the answers to some questions (mostly about efficient sprite rendering).

So, this week I decided to take a bit of a break from the Asset Manager, and take the time to actually implement textures properly, loading the compiled textures and sending the image data off to OpenGL turned out to be rather easy, OpenGL supports rendering DXT compressed textures via the ‘ubiquitous’ GL_COMPRESSED_RGBA_S3TC etc. extentions, these aren’t part of the official spec, but being labelled as ‘ubiquitous’ means that most hardware supports them, so I decided it was safe to use them.

I then moved on to dragging my sprite renderer slightly into the modern era by switching from ye-olde fixed-function rendering to using shaders, I created a simple sprite vertex and fragment shader (it’s about 4 lines long) that basically just replaces what the fixed-function version did (render a texture, multiplied by a colour, at positions specified by the vertices).

I’d never set-up shaders in OpenGL before, and a fair amount of the documentation I found used the ARB extentions to load and compile the shaders, howver, combining a few different websites (mainly this one) I managed to come up with a solution that works.

In the process of attempting to get shaders working, I made much use of my logger class, and have extended it so that, when asserts are enabled, it will trigger a break-point whenever it logs an ‘Error’ or ‘Fatal’ level message.

I’m having fun working on the main engine again, so I’ll likely not work on the Asset Manager this week, instead I want to attempt to make it easier to move, rotate and scale sprites around the small test scene I’m making.

For some time now, I’ve had the urge to make a game engine, nothing too fancy and not really with a view to release it to the public, just something to both help me make games faster and to improve my programming skills by making it.

So, when I finished LibCT 2.0, I decided that I’d start work on a small 2D, cross-platform engine: Ragnarok Engine. I decided on making a 2D engine because, well, I quite like 2D games, I like making them too so that’s a good start. Secondly, my graphics programming skills are limited and I don’t want to (at this time) dive into the rabbit-hole that comes from attempting to write a decently performing 3D graphics engine. I decided it would be cross platform because I actually like some of the things it imposes, I like that the code will be compiled on different compilers that give different warnings, I like having to section-off the low-level, platform specific code, to me this forces me to make the code better, now obviously I always try to get the code that good but we’ve all been at the point where we just write a quick hack to get something working and say we’ll go back and fix it later, but later never comes.

Since the engine will be cross platform I decided to write the renderer in OpenGL, I may decide to add a DirectX renderer in the future, but for now I’ll just stick with one API. The development plan for this engine is pretty simple, I intend this to be an engine for me to use, so it may not be suitable for people who are just beginning to code, it aims to make common things simple, and un-common things possible. I will generally use the most basic implementation of something (for example, the sprite renderer) until it becomes a problem, then I’ll improve it, this is so that the engine can develop on all fronts at a similar pace, and thus I can start using it to make games with sooner (I feel you never really appreciate an API until you’re forced to use it).

So far, I have some of the basic libraries fleshed out, maths, graphics, scene. The scene library is the most recent one, it exists to provide scene-graph functionality, in the form of nodes. The current plan is for the nodes to have properties that can be set through an editor, that will run along-side the game allowing for the easy creation of scenes which can be loaded at run-time.

Thinking about the editor led me down an interesting path, the editor will know about certain property types, floats, ints, vectors, colours etc. and be able to edit the properties of any node. The game-code will create it’s own nodes, perhaps one for the player or enemies. The editor should know about these nodes too so they can be placed in the scene, which leads to an issue, originally the editor was going to be part of the engine, and the game-code would merely link to the engine libraries, however, if this were to be the case the editor wouldn’t know about any game-specific node-types. Now, I could make the game-code compile to a .dll and tell the editor to load that at run-time, which may work, but I’d prefer not to use .dlls, and telling the editor which .dll to use could end up slightly messy.

The solution to this problem seems to be to compile the game-code into a lib, and have, in the same solution as the game-code, all the engine libraries including the editor, and have one project that links all those libraries into an executable, then to run the editor you can launch the executable with a certain command-line argument. This solves the problem nicely, the editor knows about the game-specific nodes and we avoid .dlls. The only problem here is that this leads to each game having it’s own editor, however, I decided to turn this into a strength.

Whilst it is the engine that parses the command line arguments and decides if it’s the editor or a normal game that needs to be run, I passed the creation of the editor to the application, which is the class all games will sub-class, this virtual function allows the game to create a custom-editor, derived from the base editor, that may contain things not useful or wanted in all game editors, but of great use for that specific game.

The only down-side to this that I can currently see (note I’ve not even begun to implement it) is that it makes setting up a new game kinda complex, but since it’s only me doing it, and I can most likely script it, I think it’s a decent trade-off.