Rambles about code, games and other things

So, I had a job interview last week and the company I was interviewing for looked over my current project on github. They seemed quite happy with what I’d done but said they thought my gamescreen class could use some work - in particular the collision related code. They asked what I thought I could do to improve it and I mentioned that some sort of physics engine could help. But, I wasn’t able to expand on what classes this should have.

So, I thought it would be a good idea to study up on this so I don’t get caught out in such a way again. The code in question is here. (I’m sick of the formatting in tumblr. And I managed to wreck the DNS for my new website - so pastebin it is for now).

My improvement ideas are to have a physics engine class that contains an array of pointers to all entities currently in the game. Also a collision class (or even just a struct, really, or a pair) that contains pointers to both entities in the collision. This could potentially contain information about the relative points of collision, though I don’t need that for this particular little game.

This does mean that all my entities should inherit from the same object for this to work. They currently do, but that object is Sprite. I think there should be an intermediate object in between so the physics info doesn't trickle down into what should just be a rendering class.

The physics engine class could have a process collisions function which would test each object against each other object to see if they are colliding. If there is a collision it would create a collision object and add it to a collisions array.

Then the function should loop through the collision array and call the (currently non-existent) resolution function for each object in the collision.

So far this all sounds great - the only thing really getting in the way are the animations. Either I would have to pass the animation array to the physics class and then each object, or I will have to change how animations are handled. 

If I was just making a game, I don’t think I’d bother, but since I’m trying to learn how to structure an engine then I think I ought to. So, before I embark on this physics overhaul I will need to investigate how to decouple the animations from everything.

Well - this took me a lot longer than I thought it would. The goal was to enable the ability to draw strings of a certain font and colour within my game. I could have just made an image of each of the words I want to appear in the game (since there aren’t many), but for a larger game, or a game that needs to be translated into lots of languages, this would mean a lot of content development. Also, the goal of this project is to learn things, and I would learn nothing from using images for all my words.

I had used bitmap fonts in OpenGL once before, but using tinyXML and an OpenGL framework/engine that I did not write. So I wanted to see if I could do it on my own (though heavily referencing what I did before).

I created a Text class that is responsible for drawing text. I should really have called this the font class, since I am not actually storing the text to be drawn, rather the information I need about the font. The Text class inherits from the SPrite class.

The first thing the Text class must do is load in the font image and the xml. The image was easy enough, since I already had the ability to load images. Loading the xml took me a lot longer. 

I decided to use RapidXML after a bit of research because it was called the “fastest” implementation with the least overhead. With my lofty goal of being an engine programmer at some point, and the idea being to practice making my projects as fast as they can be, this sounded like a good idea. 

Well, you can see my frustrations in my previous post. I was stuck on that problem for quite some time. Just as I was ready to give up and try a different api, I discovered my error. I had tried to read from the document tag twice, instead of once from the doc tag, and once from the child of the doc tag.

The error is on line 2 of the following code - the program kept segfaulting on line 3. And RapidXML does not throw any errors outside of its parse function.

xml_node<> *font = doc.first_node("font"); font = doc.first_node("chars"); xml_node<> *character = font->first_node("char");

The fix seems so small - properly reading from the doc’s child tag (”chars”):

xml_node<> *font = doc.first_node("font"); font = font->first_node("chars"); xml_node<> *character = font->first_node("char");

Anyway, once I fixed that, the rest of the code worked completely perfectly. Onto the drawString method. The idea here is to modify the underlying sprite variable, draw a character and repeat for each character before the function ends.

This involves modifying the x,y coordinates of each corner of the sprite, as well as the centre position of the sprite and the UV coordinates. This part of the code I had from the last time I tried this - which I believe was written by my coworker at the time: Sam Cartwright. 

My current version of the code is as follows. Pretty sure I can make this faster by getting rid of that vector.

glm::vec3 centrePos = m_oCentrePos; float curX = 0; const char* currentLetter = a_szToDraw; //not sure if better to put NULL or 0 here instead of the null terminator character. probably no difference. while(*currentLetter != '\0') { //loop through all letters to find current. Got to be a faster way. A map? for(std::vector<Character>::iterator it = m_characters.begin(); it != m_characters.end(); it++) { if((*it).value == *currentLetter) { Character& thisChar = *it; //move the position of the sprite m_oCentrePos.x = centrePos.x + curX + thisChar.width*0.5; //update the width and height and align bottom of the letters UpdateCornersGrounded(thisChar.width, thisChar.height); //change the UVs setSpriteUVCoords(thisChar.x/(float)m_uiTextureWidth, 1.0 - (thisChar.y+ thisChar.height)/(float)m_uiTextureHeight, (thisChar.x + thisChar.width)/(float)m_uiTextureWidth, 1.0 - (thisChar.y )/(float)m_uiTextureHeight); Sprite::Update(0); Sprite::Draw(VBO, IBO, shader); curX += thisChar.width; break; } } currentLetter++; } m_oCentrePos = centrePos;

Originally I was not taking into account the width of the current letter when setting the centre position (and I also had the y coordinates the wrong way around), which gave me this delightful result:

I also wasn’t placing the bottom of the letters at 0 on the y co-ordinate. These were all relatively minor fixes though!

Not having such good luck today. I thought I’d try loading in bitmap fonts for the game, but so far I’ve spent all day arguing with rapidXML to try and get it to parse a damn file.

The process is, load the file myself, put it through rapidxml’s parser then step through to get to the nodes I need. RapidXML has a requirement that the string containing the xml file data needs to stay alive throughout the entire process. And for some reason after parsing this string seems to lose data and cuts of 90% of the file. But it’s all read in correctly before parsing! And I’m not receiving any error messages. I’m so confused.

Here’s my code if anyone wants to have a look:

char szBuffer[128]; std::ifstream ins(a_szXMLName); char c; ins.get(c); while(!ins.eof()) { buffer += c; ins.get(c); } strcpy(szTextFromFile, buffer.c_str()); xml_document<> doc; try { doc.parse<parse_no_data_nodes>(szTextFromFile); } catch(parse_error p) { std::cout << p.what() << std::endl; const char *w = p.where<char>(); } font = doc.first_node("chars"); xml_node<> *character = font->first_node("char");

Well, today I added a simple state machine stack to my game in order to easily change between screens. It almost worked first time, which made me feel pretty good. I created a base Screen class as well as a GameScreen and a MainMenuScreen so I could test it out. The main function contains a stack of screen pointers so I can update and render the top screen on the stack and keep the other screens loaded if I need to.

I didn’t really learn much from this process - it was all pretty straighforward.

One thing I did learn, though, was in which order class member variables were constructed in initialiser lists. In the GameScreen class the player object relies on the playerbullets vector having already been constructed. C++ does some odd things sometimes - so I wasn’t sure how to make sure the playerbullets vector was created before the player. I thought it wouldn’t be so simple as listing the playerbullets vector first in the initialisation list of the class constructor, and I was right.

Turns out member variables are created in the order they are defined in the class. And someone provided a nicely worded reason why this is so, I won’t try to paraphrase:

The reason for which they are constructed in the member declaration order and not in the order in the constructor is that one may have several constructors, but there is only one destructor. And the destructor destroy the members in the reserse order of construction.

Once again, if you’d like to download the project, please click here.

Today I thought I would tackle animated sprites in my little opengl project. Despite having taught my students how to do these in 2013 I was a little rusty (they also had a graphics framework to help them out). It didn’t take too long to get back into the swing of it though.

To start with, I modified my Sprite class to add a function that would modify the UV (or st) co-ordinates, so I could draw pieces of loaded textures instead of always the whole texture.

Next, I created an AnimatedSprite class to inherit from my Sprite class. I added a whole heap of extra variables (probably too many, to be honest, though I use them all): the number of frames per row, the number of frames per column, the width and height of each frame, the total time the animation will take, the current frame, the current time, and some booleans to determine whether or not to loop the animation or to kill it.

All the work is done inside of the update function. I simply add to the current timer, if that exceeds the time per frame then it is time to change frames. Update the frame number, adjust the UVs accordingly and do a check to see if the animation has finished. If it has finished and it is looping then simply return the frame counter to zero, otherwise trigger the “running” boolean.

I also went through and fixed my code to be const correct (though I’m still not passing everything by reference - do you need to do that even for simple types?)

//add to sprite timer m_fCurrentTime += a_dDeltaTime; //if timer goes past certain value if(m_fCurrentTime >= m_fTimePerFrame) {     m_fCurrentTime = 0;     //move to next frame     m_iCurrentFrame++;     if(m_iCurrentFrame >= m_iNumCols * m_iNumRows)     {         if(m_bLooping)             m_iCurrentFrame = 0;         else             m_bStillRunning = false;     }     //update UVs     Sprite::setSpriteUVCoords((1.0*(m_iCurrentFrame%m_iNumCols))/m_iNumCols, (1.0*(m_iCurrentFrame/m_iNumRows))/m_iNumRows, (1.0*(m_iCurrentFrame%m_iNumCols + 1))/m_iNumCols, (1.0*(m_iCurrentFrame/m_iNumRows + 1))/m_iNumRows);     } Sprite::Update(a_dDeltaTime);

You can download the whole project from here

Well - nothing terribly interesting to me in this update - a chunk of rather inefficient gameplay code.

I have now added audio to the project via fmod - so far different laser noises for the player and enemies. I will have to add some background music at some point.

I also changed my player movement to adhere a bit more realistically to physics. Pressing forward now modifies the acceleration and the player sprite will have it’s velocity adjusted accordingly. Friction will slow it down until it eventually comes to a rest. I might change the enemies to move in this way too - then I can try and implement collision resolution between the two.

I did implement collision detection, just basic AABBs - though I feel my calculation of these is awfully slow. I need to find a better way of doing it. I have loops everywhere right now...

Also just amended this so the players and enemies wrap around on the screen once their centre positions move out of screen space.

Next things to add - explosions, player lives, score, menu system, music, particles(?).

Since my last blog post I've actually moved from Sydney to Amsterdam! My partner received a job here, so we both moved over :) This does mean that I'm now unemployed. Which I thought would be good, so I can play all the games I've been too busy for and code all the things I want to. However staying at home with no one to bounce ideas from is not something I enjoy. Thus I'm very keen on finding some work to stop me from going crazy!

In the mean time, (as well as exploring this beautiful new city) I have been working a little on that little OpenGL practice project - so far just added bullets. I spent quite a bit of time updating from glfw 2 to glfw3. Since I didn't upload any of the glfw library files to the repository and I couldn't find the correct compatible library files online I was forced to update to the latest version of glfw. Not a big deal, I have used glfw3 before and the basic walkthrough on their website is quite good. 

However I managed to get stuck for an evening on a rather simple problem. I have created an init function for my program. This does most of the setting up, loading shaders, initialising systems, etc. This particular problem was about window creation. With glfw3 you have the ability to create multiple windows - so the create window function returns a handle to the window you just created. You need* to use this window handle in other glfw functions - for example checking for keyboard input. So I created a window handle pointer in main, set it to nullptr, then passed it into my init function, with the intention being for the init function to create the window and effectively fill the pointer.

GLFWwindow* window = nullptr; init(window);

However when I ran this, when I came back to the main function the window pointer was always still null.

I am ashamed to say how long it took me to work this out (maybe I can blame jetlag?). This is actually, somehow, not a problem I have encountered before. Eventually I worked out that the pointer was being passed by value. While you can change the contents of the address being pointed to - any changes to the actual stored address only applies within the function. I needed to pass the pointer by reference to fix my problem. Which meant my function needed to change to:

bool init(GLFWwindow*& window)

Which should have been obvious. I just haven't ever needed to do this before - which really surprises me. How can I not have come across this scenario before??

Well, no matter. I'm never going to forget this ever again.

One of my old students showed me a nifty piece of code that will represent a bitfield: http://pastebin.com/NCyhFtuK

However I had not seen the notation before where there is a colon and a number following a variable declaration. I guessed it was specifying the number of bits that variable should take up (since that would make this piece of code make sense). 

Unsurprisingly that is exactly the case - and this syntax is also referred to as bitfields: http://msdn.microsoft.com/library/ewwyfdbe 

This only works inside structures, classes or unions - outside of these situations it will cause a syntax error.

It's possible to have unnamed bitfields to create padding.

struct Stuff {      int num1 : 3;      int           : 3;      int num2 : 3; }

With some compilers the bitfields are aranged in memory so that they do not cross word length boundaries of the underlying type. So there can be gaps between variables in memory. 

Right, I haven't updated this in sooo long. Since I last posted I've been to Melbourne for almost 2 weeks, and Amsterdam for a week. And my students had all their assessments due - busy times!

At least I've finally found some time to do some coding, even if it's miniscule amounts.

I opened up my OpenGL practice project to see what I'd done last time. Not much, really. Just basic set up of opengl and drawing a single texture to the screen.

I decided that today I'd change the way I was placing the sprite so I would be using matrices instead. So I gave my sprite a global transform matrix (world matrix). And I created an orthographic projection matrix in the main file. No need for a view matrix in 2D (I think). Well, at least I don't plan on having the camera move around in this project.

I amended the shaders so that they take in both a world matrix and a projection/view matrix. 

Now, instead of calculating the positions of the vertices in world space on the CPU like I did with the students this year (as they hadn't done shaders yet) I calculate them on the GPU, like it should be done. So, I pass to the shader: vertex position, projection matrix and world matrix of the sprite. Then multiply the vertex position by the world matrix, then the projection matrix. (Effectively converting it from local model co-ordinates, to global co-ordinates, to screen co-ordinates).

One important thing I learned today, as I changed my sprite to always initialise around the origing, was that if you multiply an unsigned int by an int, then you get an unsigned int. I was trying to multiply the width of my sprite by -1, which then just gave me the max value of an unsigned int. I had assumed it would implicitly convert to an int, but it turns out unsigned int takes priority. 

Anyway, apart from me switching out the sprite, the running project doesn't look a whole lot different, but feel free to have a look at my code if you like!

OK, well it's about time I actually started posting my own projects somewhere for others to see (also somewhere I won't lose them).

So far I've just posted a bit of an OpenGL test I had hanging around. The shader loading code is from the book: OpenGL 4.0 Shading Language Cookbook. The texture loading code was written by a teacher at AIE, so I probably shouldn't have posted it. Perhaps my next step can be to replace that.

This code obviously needs some tidying up and fleshing out. I would like to place the OpenGL initialisation into the common library I've created. And possibly also the Vertex and Index buffer objects. 

I'm not sure whether it is better for all sprites to share buffers, or for each sprite to have their own buffers. I think I will need to research this next.

Next step is to add some camera code so I can change my screen coordinates. I will use orthographic projection while I'm working in 2D, but I'll try to make it easy enough to change to perspective for later on.

Imagine, for a minute, that you are allergic to peanuts. Not in the way that they kill you almost instantly, but that they just make you feel sick after you eat them.

Now, imagine that when you were a child, all the ice cream in the world contained varying amounts of peanuts. And imagine that you really love ice cream.

There are ice creams with high peanut amounts that you can't even go near without wanting to vomit - you've always avoided those. And there are ice creams with less peanuts that you have eaten regularly and put up with the sick feeling afterwards just so you can enjoy the ice cream taste.

Then there are some ice creams that barely have any peanuts in them. These are the ice creams you eat the most often. You've even started to get used to the queasy feeling they give you. You're tough, it doesn't really bother you. Small price to pay for awesome ice cream.

Some other people who are also allergic to peanuts - they do complain though. You look at them with scorn, obviously they are not tough enough to endure the queasiness. You wish they'd just shut up so you can get back to enjoying ice cream in peace.

Then, frozen yoghurt is released. The people who aren't allergic to peanuts point it out to those allergic people who have been complaining. But, frozen yoghurt isn't really the same. It's a poor excuse for a frozen dessert. All sugar and no substance. And you don't even want to get started on the stores - all fluoro colours, bright lights and staff happier than kids TV presenters. No ice cream fan would be caught dead inside one.

The people allergic to peanuts keep complaining about the peanut ice cream. The non-allergic people keep pointing to the frozen yoghurt. You still think there is too much yelling, and you wish everyone would be quiet.

But then, one day, some ice cream comes out that has no peanuts in it. You eat it, and it's amazing! Same ice cream taste but without the queasy feeling. So, ice cream without peanuts is possible after all! You eat the peanut free ice cream almost every other day.

For a while, that's enough. But then you go to the ice cream parlour and see all the different varieties of peanut ice cream. You've only got one peanut free flavour to try. You start to think that this isn't fair.

The allergic people are still loudly complaining about the lack of peanut-free ice cream. The non-allergic people now point to the one flavour of peanut ice cream and the frozen yoghurt. The allergic people scoff at the non-allergic people and call them stupid and flavour-ist. More yelling ensues. 

You are torn. You really want more peanut-free ice cream. But you also think that yelling at the non-allergic people is a bit wrong. They can't help it, they don't know what it's like to feel a bit sick each time they take a bite of otherwise delicious ice cream.