Fixing my collision errors + cleaning up

So I’ve made a promise to myself to write a post once a week. I actually started this 3 weeks ago then promptly went to Spain on holidays and missed two weeks. And I’m still not quite in the habit of doing it yet, so I seem to be leaving things to the last minute and writing my posts up on Sunday evening. In fact with my last post I managed to not finish before a house guest arrived, then frantically tried to get it done while the house guest was out one night seeing the sights of Amsterdam.

I’m happy that I do at least end up motivating myself to do some work once a week (in fact once I do get going I really enjoy myself) but I really need to work on not leaving it until the last minute. Because when I do that I rush and make mistakes.

Which brings me to today’s post. It seems my attempt at collisions was not quite perfect. For some reason the bullets were not being removed on collision, and in my search to find out why I discovered other minor bugs and ended up tidying up a bit.

Firstly I noticed that ships were being hurt by their own bullets as they were shooting them (because the bullet and shooting ship overlap for a brief time). To solve this I decided that the bullet should store a reference to the ship that shot it, and when checking collisions I should just discount any bullets that come from my own ship. I added a ShipObject pointer to bullet and the following code to the ShipObject Update function:

else if (collisionTag == BULLET_COLLIDER) {
    BulletObject* bullet = dynamic_cast<BulletObject*>(m_colliderComponent->m_pOtherCollider->m_pGameObject);
    if (bullet->m_pOwner != nullptr && bullet->m_pOwner != this) {
        m_healthComponent->TakeDamage(bullet->GetPower());
}

I also added a “power” variable to the bullets, so that I can change how much damage is done by enemy and player bullets. So in the above code the power of the bullet is obtained and passed to the health component.

I then noticed that some components of the game objects remain active even when the game object itself is deactivated, and my tests to see if game objects or components are active were just all over the place. So I added the following function to GameObject:

void GameObject::SetActive(bool a_bValue)
{
    if (m_bActive != a_bValue) {
        m_bActive = a_bValue;
        for (unsigned int i = 0; i < m_components.size(); i++) {
            m_components[i]->m_bActive = m_bActive;
        }
    }
}

This way the components are all set accordingly when a GameObject becomes active or inactive. I also made sure I was checking the active boolean in all Updates and other relevant functions. Also I added some code to the AddComponent class so that newly added components are set up with the active flag set the same as it is on the GameObject they are being added to at the time.

After all this my bullets were STILL not being removed after hitting a ship. I spent an embarrassingly long amount of time trying to work out why. In the end it turned out to be the first line of the IsCollidingWith function in the ColliderComponent. I was setting the pointer to the “other collider” (which I’m also using as a flag to determine whether there has been a collision) to be null.

What an idiotic thing to do – since I check every collider against every other collider right now then the other collider pointer is being overwritten with the very next collider I check. Really it only worked if the last collider I check against a particular collider results in a collision. To fix it I just reset all the “other collider” pointers before going into my collision checking loops.

The last thing I changed was to cache the references to the components I need in each class. Previously I was calling GetComponent multiple times per Update loop, which seemed like a not very good decision performance wise (since I’d have to check references to each component in the component list for that game object, and these are not stored very closely together in memory.

So in each of my derived GameObject classes I added a pointer to the Components it uses – then created a “setComponentPointers” private function, that is called at the end of the AddComponent function. The GetComponent call is done in here, like so:

void ShipObject::setComponentPointers()
{
    m_spriteComponent = dynamic_cast<SpriteComponent*>(GameObject::GetComponent(SPRITE));
    m_colliderComponent = dynamic_cast<ColliderComponent*>(GameObject::GetComponent(COLLIDER));
    m_healthComponent = dynamic_cast<HealthComponent*>(GameObject::GetComponent(HEALTH));
}

Next week I think I might take a look at trying to separate out the game logic code from the engine code. Also perhaps try to make it a bit easier to use the engine code, to foolproof it a bit somewhat. It would be great for the gameplay coder to not have to write the setComponentPointers function – right now they have to kind of add components in two places (using the AddComponent function as well as setting up the pointers in the GameObject class and making sure they are filled properly by the setComponentPointers function). It would be awesome if, after calling AddComponent, a gameplay coder never had to worry about doing anything else…

Feel free to have a closer look at my code on GitHub and let me know any suggestions you might have in the comments below.

Adding collisions to my little engine

Wow, it’s been a whole month since I last posted. Somehow it feels like so much longer. I’ve been so busy because my game was released on PS4 and Steam, and we’ve been so busy promoting it (which included a trip to Germany).

But, finally I’ve been able to do a bit of work for myself again. I’ve decided to add collisions to my project. They were already there in my previous iteration, but the existing implementation does not work at all with the component based system I’ve been working on. So, time for a refactor.

Before I started I moved the position, rotation and scale variables into the base GameObject class. There were way too many components that needed this information, and having to retrieve this from one component and pass it to the others was just getting ridiculous. The Unity game engine actually has a Transform component that stores this information and every GameObject includes a Transform component by default. I thought that was overkill for my little project, but I might change that again later on because it might be good to keep all the transform information together in memory.

Continuing with the theme of Unity being my main inspiration, I decided to create a ColliderComponent. Right now this is really an AABB collider, but eventually I think this will just be the base class for a series of colliders. I incorporated my existing AABB implementation into this component.

bool ColliderComponent::IsCollidingWith(ColliderComponent *a_pOtherCollider)
{
    m_pOtherCollider = nullptr;
    if (!m_pGameObject->IsActive()) {
        return false;
    }
    if (m_collisionTag == a_pOtherCollider->m_collisionTag) {
        return false;
    }
    if (max.x < a_pOtherCollider->min.x || min.x > a_pOtherCollider->max.x)
        return false;
    if (max.y < a_pOtherCollider->min.y || min.y > a_pOtherCollider->max.y)
        return false;
    //store the other collider
    m_pOtherCollider = a_pOtherCollider;
    return true;
}

There are a few things going on in this function. The lower half should look familiar – it’s basically just the existing AABBvAABB code from my previous implementation, just checking that the corners of the bounding box intersect.
Above that I’m checking to see if m_pGameObject is active. This is a variable I added to the base Component class – it’s a reference to the GameObject that the component is attached to. This made it easier to share information between Components (especially the transform information I mentioned earlier).

The CollisionComponent also has a collisionTag. I only have 3 tags right now: BULLET, PLAYER and ENEMY. No Bullets should collide with one another, and enemies should also pass through one another (for now), so I’m simply checking that nothing with the same tag should collide. Ideally there would be some sort of lookup table here to see what is allowed to collide with what, but that’s definitely a task for another time.

If there has been a collision I store the other collider, currently as a public variable so that I can check it in the gameplay scripts.

To call this function I created a PhysicsManager. The PhysicsManager stores references to all the CollisionComponents and has the following Update function:

void PhysicsManager::Update()
{
    //check all colliders against all other colliders. 
    //Is there a faster way to do this?? 
    //Obviously methods exist, should do some research
    for (unsigned int i = 0; i < m_colliders.size(); i++) {
        for (unsigned int j = 0; j < m_colliders.size(); j++) {
            //process collisions
            m_colliders[i]->IsCollidingWith(m_colliders[j]);
        }
    }
}

So basically it just runs through all the colliders and sets the “other” collider if there has been a collision. This collider is then checked in the GameObject gameplay code like so:

//check collisions here?
ColliderComponent* colliderComponent = 
    dynamic_cast<ColliderComponent*>(GameObject::GetComponent(COLLIDER));
if (colliderComponent->m_pOtherCollider != nullptr) {
    //ok, this means there has been a collision
    //check if collision is ship object or bullet
    if (dynamic_cast<ShipObject*>(
        colliderComponent->m_pOtherCollider->m_pGameObject)) {
        //inflict damage
        healthComponent->TakeDamage(10);
    }
    else if (dynamic_cast<BulletObject*>(
        colliderComponent->m_pOtherCollider->m_pGameObject)) {

        //inflict damage
        healthComponent->TakeDamage(10); 
    }
}

So here you can see I’m checking if the other collider is set and then checking to see what the game object is that we’ve collided with. In hindsight I should probably be checking the physics tag at this point, rather than doing a bit of a hacky dynamic cast. Also the damage is hardcoded in right now, but really I should be retrieving the weapon power of the bullet for the last line and applying that in place of “10”.

The last thing to note is that I am now calculating the bounding boxes of the objects every frame in the update function of the ColliderComponent instead of calculating this twice a frame and having to process the result in the main Update loop in the GameScreen.

Here is the ColliderComponent Update function:

void ColliderComponent::Update(const double a_dDeltaTime)
{
    min.x = max.x = m_pGameObject->m_position.x;
    min.y = max.y = m_pGameObject->m_position.y;

    glm::mat4 globalTransform = 
        glm::translate(glm::mat4(1), glm::vec3(m_pGameObject->m_position.x, 
                       m_pGameObject->m_position.y, 
                       m_pGameObject->m_position.z)) *
                       glm::rotate(glm::mat4(1), 
                       m_pGameObject->m_fRotationAngle, 
                       glm::vec3(0, 0, 1)) * 
                       glm::scale(glm::mat4(1), 
                       glm::vec3(m_pGameObject->m_fScale, 
                       m_pGameObject->m_fScale, 1));

    for (unsigned int i = 0; i < 4; ++i)
    {
        glm::vec4 temp = globalTransform * m_corners[i];
        if (temp.x < min.x)
            min.x = temp.x;
        if (temp.y < min.y)
            min.y = temp.y;
        if (temp.x > max.x)
            max.x = temp.x;
        if (temp.y > max.y)
            max.y = temp.y;
    }
}

So, here’s the recalculation of the bounding box each frame. Having to recalculate the globalTransform once per object per frame seems like a silly idea. Especially since the SpriteComponent is also making this calculation. It seems like the globalTransform should also be a part of the GameObject (or Transform) so it’s only calculated once per frame. And possibly it might only get recalculated if the position, rotation or scale have changed.

So that brings me to the end of my Collision refactor. I was happy to get this all up and running in only a few hours, but I definitely feel that I made some poor decisions, especially in terms of performance. I think my next job will be to fix up some of the issues I’ve already mentioned, as well as do a little research into a better way to process the collisions.

If you have any suggestions then please let me know in the comments, and as always, you can find my code on github.

Absolute value of a float

I did a job interview a while ago where I was asked, as the first question of a phone interview, how I would calculate the absolute value of a float. I didn’t answer this very well at all, in part due to the fact I wasn’t aware the interview I was going into was going to be a technical one, but more due to the fact that I didn’t have the greatest understanding about how a float actually works. I knew vaguely that it stored the mantissa and exponent, but had no idea about how many bits each took up or where those bits were located. And I just assumed that all negative numbers would be handled in two’s complement, similar to integers.

I did so horrendously bad at that interview in general that I went out and bought a book called Write Great Code: Volume 1: Understanding the MachineI’m only up to chapter 4 so far, but wow, this book is great. I feel like it should be required reading for all computer science undergrads, and wish I’d been taught a lot of this stuff much earlier.

So chapter 4 deals with floating point representation, and the question of finding the absolute value of a float that has been haunting me since the interview now seems a lot easier to tackle.

I’ve learned that single precision IEEE floating point format does indeed store a mantissa and exponent, but the mantissa uses 23 bits, followed by the exponent with 8 bits, and the remaining bit simply handling the sign:

2000px-ieee_754_single_floating_point_format-svg

So, finding the absolute value of this now seems super easy, we just need to zero that sign bit:

float myFloat = -1.45;
float absFloat = myFloat & 0x7FFFFFFF;

Ok, so that actually doesn’t work. Binary operators don’t actually work on floating point variables in C++. I guess that makes sense, really, the interview question would have been way too easy otherwise.

Casting to an int isn’t going to work, because that just rearranges how the value is stored (no mantissa or exponent there) not to mention losing any information following the decimal point.

After a quick Google I saw someone mention using a union. That sounds like a nice solution, let’s try that.

union hackCasting{
    int myInt;
    float myFloat;
};

hackCasting myUnion;
myUnion.myFloat = -1.45;
float absFloat = myUnion.myInt & 0x7FFFFFFF;
std::cout << absFloat << std::endl;

Which gave me the output of 1.06913e+09. Hmm. Clearly something is going wrong there. Oh, an inherent cast by creating a new float (absFloat) and storing my int calculation there.

union hackCasting{
    uint32_t myInt;
    float myFloat;
};

hackCasting myUnion;
myUnion.myFloat = -1.45;
myUnion.myInt = myUnion.myInt & 0x7FFFFFFF;
std::cout << myUnion.myFloat << std::endl;

Hurrah, a correct result of 1.45. (And a change to using an unsigned int after finding a comment by Tim Schaeffer on StackOverflow. Not sure if it’s actually Mr Schaeffer, but helpful all the same!)

So, question complete – take that interview question.

Enemy interactions

Sooo long without an update. My excuses include: laziness, being so close to releasing a game in my day job leaves no mental energy for home projects, travel, and working with a mentor outside of work hours to better understand data oriented development.

I have slowly been refactoring the Enemy class. Not long into my first attempt I saw how similar the PlayerObject and EnemyObject were going to be, so I created a ShipObject to stop myself from repeating code. I moved the component updating and shoot code into the ShipObject which leaves the Player update all about input handling:

GLFWwindow* currentContext = glfwGetCurrentContext();
PhysicsComponent* physicsComponent = dynamic_cast<PhysicsComponent*>(GameObject::GetComponent(PHYSICS));
if (physicsComponent != nullptr) {
    if (glfwGetKey(currentContext, 'W')) {
        physicsComponent->AddForce(glm::vec2(150, 150));
    }

    if (glfwGetKey(currentContext, 'A')) {
        physicsComponent->AddRotation(3);
    }

    if (glfwGetKey(currentContext, 'D')) {
        physicsComponent->AddRotation(-3);
    }
    if (glfwGetKey(currentContext, GLFW_KEY_SPACE)) {
        shoot();
    }
}

ShipObject::Update(a_dDeltaTime);

So now for the Enemy. With all the rest of the clutter gone all I have left is the “AI” of the enemy following the player and shooting when within range. So the problem here is that the Enemy needs to know the position of the Player. In the old code I just passed the player’s vec3 position into the Enemy’s update function as a constant. However with my new GameObject approach I couldn’t really justify modifying my EnemyObject to use different Update parameters.

I briefly toyed with the idea of making the Enemy listen for changes to the Player’s position with some sort of Observer pattern. Despite wanting to practice that pattern a little, it seemed like a huge amount of overkill. So for now I’ve created a GetPosition function in PlayerObject, and the EnemyObject now contains a pointer to the PlayerObject in order to use this function when necessary.

I still don’t really like this since the EnemyObject now has full read/write access to the PlayerObject’s position (hmm, why am I even passing back the actual position in GetPosition? Why don’t I make a copy to pass back? Still, even with this improvement the Enemy has access to all the PlayerObject’s public functions – like adding components).

With that decision out of the way all that was left was adding in the “AI”. It remains basically unchanged from the original code – just modified to work with the new component system:

PhysicsComponent* physicsComponent = dynamic_cast<PhysicsComponent*>(GameObject::GetComponent(PHYSICS));
glm::vec3 playerPos = m_player->GetPosition();

glm::vec3 toPlayer = playerPos - physicsComponent->m_position;

float aimAngle = atan2(toPlayer.y, toPlayer.x);

if (aimAngle*180.0 / 3.14159 > physicsComponent->m_fRotationAngle + 90)
    physicsComponent->AddRotation(3);
else if (aimAngle*180.0 / 3.14159 < physicsComponent->m_fRotationAngle + 90)
    physicsComponent->AddRotation(-3);

if (physicsComponent->m_fRotationAngle + 90 > 180)
    physicsComponent->AddRotation(-360);
else if (physicsComponent->m_fRotationAngle + 90 < -180)
    physicsComponent->AddRotation(360);

physicsComponent->AddForce(glm::vec2(50, 50));

if (glm::distance(playerPos, physicsComponent->m_position) < 200) {
    ShipObject::shoot();
}

ShipObject::Update(a_dDeltaTime);

One thing I’m contemplating is creating a component similar to Unity’s “transform” component. This can store the position, rotation + scale. And then each other component should have access to the transform. This way I can remove all the code that looks like this:

SpriteComponent* spriteComponent = dynamic_cast<SpriteComponent*>(GameObject::GetComponent(SPRITE));
PhysicsComponent* physicsComponent = dynamic_cast<PhysicsComponent*>(GameObject::GetComponent(PHYSICS));
if (spriteComponent != nullptr) {
    if (physicsComponent != nullptr) {
        //Is there a better way to get these components to work together? I feel it's likely           to happen a lot.
        spriteComponent->m_position = physicsComponent->m_position;
        spriteComponent->m_fRotationAngle = physicsComponent->m_fRotationAngle;
    }
}

So, next step (unless there’s anyone who thinks this is a bad idea) is to create a transformComponent. Then perhaps I can finally get to collisions!

Thanks for all the comments from last time – they definitely give me a lot to think about and I think I will implement some of the suggestions soon.

Once again, all my code is on github if you’d like to read it without the ugly WordPress formatting.

Object Pooling

I began today with the intention of implementing the EnemyObject and getting that to work with in the GameScreen alongside the PlayerObject. However after a rather short time I decided that those two classes needed to interact so much that it was going to be a pain to make that work and then refactor once I’d moved all the Components into GameScreen when I was ready to implement object pooling.

Clearly that means I was ready for a bit of a refactor to make object pooling work – so off I went. Firstly I made arrays for each of my Component types in my GameScreen:

PhysicsComponent *m_pPhysicsComponents;
SpriteComponent *m_pSpriteComponents;
HealthComponent *m_pHealthComponents;

Then initialised these in the constructor. At this point I debated whether or not to set up each of the components with the correct data using their parametrised constructors (I actually had no idea that’s what non-default constructors were called) or if I should just use default constructors and then afterwards call some init function. I decided that having an init function meant that all the variables were getting set twice, so I decided to go for the parametrised constructor option. Mind you I’m now regretting that decision:

m_pPhysicsComponents = new PhysicsComponent[14]{ 
 { glm::vec3(400, 300, 0), 1.0f, 0.0f, 0.97f }, 
 {},
 {},
 {},
 //yeeeeep, this is shit
 { glm::vec3(), 1, 0.0f, 1, false },
 { glm::vec3(), 1, 0.0f, 1, false },
 { glm::vec3(), 1, 0.0f, 1, false },
 { glm::vec3(), 1, 0.0f, 1, false },
 { glm::vec3(), 1, 0.0f, 1, false },
 { glm::vec3(), 1, 0.0f, 1, false },
 { glm::vec3(), 1, 0.0f, 1, false },
 { glm::vec3(), 1, 0.0f, 1, false },
 { glm::vec3(), 1, 0.0f, 1, false },
 { glm::vec3(), 1, 0.0f, 1, false }
 };
 m_pSpriteComponents = new SpriteComponent[14]{ 
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(51.0f, 86.0f), "ship.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(51.0f, 86.0f), "cylon.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(51.0f, 86.0f), "cylon.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(51.0f, 86.0f), "cylon.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(5.0f, 15.0f), "laser.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders, false },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(5.0f, 15.0f), "laser.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders, false },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(5.0f, 15.0f), "laser.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders, false },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(5.0f, 15.0f), "laser.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders, false },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(5.0f, 15.0f), "laser.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders, false },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(5.0f, 15.0f), "laser.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders, false },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(5.0f, 15.0f), "laser.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders, false },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(5.0f, 15.0f), "laser.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders, false },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(5.0f, 15.0f), "laser.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders, false },
 { glm::vec4(1.0f, 1.0f, 1.0f, 1.0f), glm::vec2(5.0f, 15.0f), "laser.png", m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders, false }
 };
 m_pHealthComponents = new HealthComponent[4]{
 {100},
 {30},
 {30},
 {30}
 };

So now that the components are stored in GameScreen I need to pass pointers along to the GameObjects so they can still access the components they need. This was pretty easy for the players and enemies since I also had access to them in GameScreen:

m_player = new PlayerObject(m_pBulletManager, m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders);
m_player->AddComponent(m_pPhysicsComponents);
m_player->AddComponent(m_pSpriteComponents);
m_player->AddComponent(m_pHealthComponents);
m_gameObjects.push_back(m_player);

for (int i = 0; i < 3; i++)
{
 m_gameObjects.push_back(new EnemyObject(m_pBulletManager, m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders));
 m_gameObjects[i + 1]->AddComponent(m_pPhysicsComponents + i + 1);
 m_gameObjects[i + 1]->AddComponent(m_pSpriteComponents + i + 1);
 m_gameObjects[i + 1]->AddComponent(m_pHealthComponents + i + 1);
}

Getting the components into the BulletObjects was a bit more complex. I decided I would need to pass a pointer to the position of the first bullet related component in each component array to the BulletManager. Good idea, however I’d need to limit the number of BulletsObjects the BulletManager could create since I didn’t want to run out of Components. This meant a small refactor to pool the BulletObjects in the BulletManager too.

I also needed to change how I was shooting the bullets. Previously I’d been creating the bullet (and thus the components) in the Shoot function which meant I could just grab the position and rotation of the player and initialise the bullet with that info. However now I’d need to update the PhysicsComponent with this data *after* it had already been created. At this point I decided to make the position and rotation variables in PhysicsComponent public since I was clearly going to need to set them outside of the constructor. I added a shoot function to my bullet to accomplish all this:

void BulletObject::Shoot(int speed, float a_fRotationAngle, glm::vec3 a_startPos)
{
 if (m_physicsComponent != nullptr) {
  m_physicsComponent->m_fRotationAngle = a_fRotationAngle;
  m_physicsComponent->m_position = a_startPos;
  m_physicsComponent->AddForce(glm::vec2(speed, speed));
  GameObject::GetComponent(SPRITE)->m_bActive = true;
 }
}

As you can see in the last line – I’ve added a boolean to my Component class to determine if the component is currently active (since components hang around all the time now it makes sense to be able to turn them off when we don’t want them). So I start all the components in my bullets off as inactive – then turn them on when they are shot. There’s also a check in the BulletManager Update function to set them back to inactive when a bullet goes off screen.

I’ve implemented a rather basic system in BulletManager to handle looking for an inactive bullet that can be shot:

void BulletManager::Shoot(int speed, float a_fRotationAngle, glm::vec3 a_position) 
{
 //clearly need to make this 10 a const (or a variable if I pass it in, I guess)
 if (m_uiNumActiveBullets < 10) {
  while (true) { //is this bad? 
   //My teachers (and I) always taught it was bad coding practice
   // but otherwise I'm wasting a boolean and an extra check
 
   ++m_iLastAssignedBullet;
   if (m_iLastAssignedBullet >= 10) {
     m_iLastAssignedBullet = 0;
   }

   if (!m_bullets[m_iLastAssignedBullet].IsActive()) {
    m_bullets[m_iLastAssignedBullet].Shoot(speed, a_fRotationAngle, a_position);
    break;
   }
  }
 }
}

So basically I keep track of where I last assigned a bullet since it seems likely that the following position in the array will also be an inactive bullet. There’s probably a much better way of doing this – but for now it will do.

For completeness sake – the BulletManager constructor now looks like this:

m_bullets = new BulletObject[10]{
 //ok, this is shit - gotta find a better way of doing this.
 { m_uiVBO, m_uiIBO, m_pShaderProgram },
 { m_uiVBO, m_uiIBO, m_pShaderProgram },
 { m_uiVBO, m_uiIBO, m_pShaderProgram },
 { m_uiVBO, m_uiIBO, m_pShaderProgram },
 { m_uiVBO, m_uiIBO, m_pShaderProgram },
 { m_uiVBO, m_uiIBO, m_pShaderProgram },
 { m_uiVBO, m_uiIBO, m_pShaderProgram },
 { m_uiVBO, m_uiIBO, m_pShaderProgram },
 { m_uiVBO, m_uiIBO, m_pShaderProgram },
 {m_uiVBO, m_uiIBO, m_pShaderProgram}
 };
 for (unsigned int i = 0; i < 10; ++i) {
 m_bullets[i].AddComponent(m_pPhysicsComponents + i);
 m_bullets[i].AddComponent(m_pSpriteComponents + i);
 }

Which is called like so, in the GameScreen class:

m_pBulletManager = new BulletManager(m_uiSpriteVBO, m_uiSpriteIBO, m_pShaders, 
 m_pPhysicsComponents + 4, m_pSpriteComponents + 4);

This code clearly still needs some work (so many hard-coded values…) but it only took me about 2 hours to implement all this and get it up and running successfully. I’m pretty happy about this since I have often become lost and confused during refactors like this over the past year – getting tangled up half way through and needing a colleague to help me get untangled. I also seem to be getting faster since I know it’s taken me at least double the time to do something like this in the past.

If you have any comments on what I’ve done then please let me know. As always, my code is on github.

Putting some pieces together

Well, it’s been a long while since I’ve posted. I went to GDC in San Francisco and had a blast! It was great to meet up with old friends, meet some new friends and learn a lot. I didn’t get the chance to go to that many talks – but when I did I enjoyed noticing how much more I understood than last year. Progress!

Anyway, immediately after GDC I came down with the flu and productivity of any kind at all was out of the question. But now, finally, I’m feeling more like myself again and I can get back to learning (and working).

Before going to GDC I thought I’d try to start putting things together to make sure they worked (though I’ve had no time to write about my changes until now). So I started working the PlayerObject and BulletObject into my GameScreen and removing my old implementations. Amazingly, I didn’t actually have to change very much in my code at all.

The biggest hurdle was spending way too long wondering why I couldn’t see the player drawn to screen. After an hour or so I worked out that the problem was all the way back up in main.cpp. My draw code is now being run from the Update functions of the GameObjects, and these are being called from the Update function in main. In main I was calling glClear, then the (soon to be deleted) draw function, and then calling glSwapBuffers before calling the Update function. Basically that meant I was drawing to the screen, then clearing the screen before posting the screen to the front buffer. Oops.

The only other issue was that my guess for the initial force used to shoot the bullets was way too low. After upping that to 30000 I decided that this was a “magic” number and this should really be passed in as a variable so I can have bullets of different speeds if I want.

As always, you can find my code on github – and the component code is still in a separate branch from master.

On an unrelated note, I’ve been reading a book called “Write Great Code” by Randall Hyde. So far I’ve learned a bit more about how integers and fixed-point variables are stored and manipulated – and how the C/C++ compiler might translate some of my code into assembly. I’m getting better at being able to understand assembly snippets – or at least to use them to better comprehend what is going on behind some higher level code and how that affects memory management and CPU usage.

Bullet refactor

In my last post I created a PhysicsComponent while in the process of refactoring my messy Player class. Today I decided to have a look at the rest of the Player class and see what else I could clean up.

The next biggest mess was how I was handling shooting and bullets. Basically each Player and Enemy had their own vectors of Bullets and handled them separately. The Bullet class seemed like a really good candidate for another GameObject – so the first step was to create a BulletObject. Bullets need to be drawn to the screen and also move around – so I’ve added both the SpriteComponent and PhysicsComponent to my BulletObject (as I did with the Player).

Looking at the existing code for moving the Bullet it quickly became clear that my static const friction value was going to have to become a regular member variable. My bullets don’t have constant acceleration, so really I’m just applying a force when they are shot and then never degrading their velocity. So I set the “friction” in my bullets to 1. I’ve not been able to test all this yet, so I’m going to be amazed if it all works first go.

As I predicted in my last post – I had to repeat the code where the physics and sprite components have to work together before the sprite can draw. So it definitely needs to change – I’m just not sure how (yet). Might sit on that one for a while.

Once the bullet object was out of the way I decided to make a BulletManager that would be responsible for storing all the bullets. This way the player and each of the enemies can just have references to the BulletManager. The BulletManager currently has a vector of pointers to Bullet objects – each time I call the Shoot function I create a new Bullet and add it to the vector. Not particularly cache-friendly but I will fix that when I get around to adding functionality for object pooling.

Once that was done I moved the Player’s shoot code into it’s own function and everything was looking a lot cleaner. Here’s how it looks:

void PlayerObject::shoot()
{
 if (m_fFireCoolDown <= 0) {
     m_fFireCoolDown = 0.3f;
     PhysicsComponent* physicsComponent = 
     dynamic_cast<PhysicsComponent*>(GameObject::GetComponent(PHYSICS));
     float rotationAngle = physicsComponent->GetRotation();
     glm::vec3 shootPos = physicsComponent->GetPosition();

     //calculate offset from player position in world space
     glm::vec4 offset = glm::rotate(glm::mat4(1), rotationAngle, 
     glm::vec3(0, 0, 1)) * glm::vec4(10, 0, 0, 1);

     m_pBulletManager->Shoot(rotationAngle, 
     shootPos - glm::vec3(offset.x, offset.y, offset.z));
     m_pBulletManager->Shoot(rotationAngle, 
     shootPos + glm::vec3(2*offset.x, 2*offset.y, 2*offset.z));
 }
}

I still think I’m going to store a reference to each component in each GameObject. Calling GetComponent each time I need to use it is a bit silly (and adds overhead).

The only other change I made was to add an “active” boolean to GameObject. I imagine this will be useful for all sorts of things, but for now at least it’s an easy way to mark a Bullet as no longer on screen so that it can be removed.

Next time I will probably refactor the Enemy class into an EnemyObject – but that shouldn’t take long. I’m thinking I could possibly create a HealthComponent once I’ve done that since both Player and the Enemies have health.