BUGS BUGS BUGS!

What is it

When you think of bugs, usually people think of the small annoying animals which annoy or disgust them. This is similar to coding bugs, as these are small things which annoy programmers.

Coding bugs are technically mistakes, which could range from unintended behavior of the program to the program crashing during a specific case. Mild bugs may be comedic such as causing AI to malfunction or deformed objects, but not crash the program. Serve bugs can cause a section of a game to be unplayable, or some functions could be cut out.

What types of bugs are there ?

Arithmetic bugs

When the user does a mathematically impossible argument. This could range from Division by zero, to arithmetic overflow or underflow. There could also be loss of arithmetic precision due to rounding or unstable algorithm.

Logic bugs

Logical bugs deal with loops and incorrectly using them. This could be from infinite loops/recursion, to using one too few loops which will access uninitialized data. 

Syntax bugs

Syntax bugs occur when using the wrong operator, usually a result of being new to programming or switching to a different language.  The good news is that in some cases the complier will give a warning about these bugs, even making it an error at times.

Resource bugs

Resource bugs occur when you are improperly using your resources, from pointers, to buffers, to variables. Pointers can give an issue when they are null, or used after its memory is free. Variables have issues when the wrong data type is being packed into it, or there is an uninitialized variable.  Finally buffers can have issues with overflow, or resource leaks may occur.

Interfacing bugs

                Interface bugs deals with incorrect usage of the external tools, and hardware. This could be software based with incorrect api/library usage and/or implementation. This could also come from hardware related issues, such as incorrect hardware assumptions, resulting in incorrect handling of the hardware.

Performance bugs

Finally performance bugs are issues which could range from minor hiccup to major malfunction. A minor case could a be a random hiccup when a piece of code is used, there will be a performance hit for a few seconds. A major performance bug will be when the game continuously suffers low frame rate due an “unoptimized code”. With this code optimization is something done near the end of game development cycles, so performance bugs may not be solved till then.

Debugging  

                Debugging is process of solving these bugs split into 2 parts, find and solve. First we have to find out what specific area or line of code that is causing this problem, which can be a tedious process if our complier doesn’t tell us what the line causing the issue is. If we find the line causing the issue we now have to identify what specific issue it is, and now attempt to solve it. With knowledge on the bug, the solution can range from changing the line, to modifying another piece of code which could be affection the line, or changing the whole section due to incorrect coding.

I will be spending the rest of the semester learning how to find and solve these bugs

A (bug) blast from the past

Its the beginning of a new school year and the beginning of a whole new set of technical blogs. For this semester's technical course, we have Advanced debugging, with the program's well respected teacher. In this course, we look at ways to solve bugs of any sorts, high and low level, memory leaks, wrong memory allocation and sorts.


To start off this year, I wish to go back and discuss a simple but yet deadly bug which took place during object deletion. This was second year when I was creating my bullet hell game, Bullet Devil, and was creating my own mangers with std::vectors. Theses vectors contained pointers to objects which were being managed, bullets in this case, which could be modified by the manager. The bug occurred when I was deleting bullets with my manager, with the following code.

            if (BulletVector.at(i)->    b_hit==true)//true
            {
                BulletVector.at(i)->~Bullet();// calls the bullet
                BulletVector.erase(i);// erases that object    
           }    



The problem was that the bug would trigger after a random number of bullet destroys, sometimes after 5 bullets, sometimes after 20.  The visual studio disassemble wouldn't help either, directing me to the spot where I knew was the issue.

The solution came when a good programming friend of mine came to help point out what was the issue with this was.The problem was that next iteration of the loop will increase the variable i, but there was also an element removed. This means everything after the deleted element has moved back one step, but the i variable will be 1 element ahead.
To fix this everything in the array after the removed element, we simple decrement the i variable by 1. So if the i variable increases AND things moved backwards, the i variable will not skip any elements. 

The following code fix was:

               BulletVector.at(i)->~Bullet();
               BulletVector.erase(BulletVector.begin()+(i--));// erases that object
               continue;


From this point on, when ever I made a bullet, powerup and enemy manager, for c++, I always included this segment of code.

Havok Collisions

 Initial Implementation

           When we found out that we had to use The Havok Physics Engine for collisions, we heard that we had to use the abstract class: hkpContactListener. From here we fiddled around with it in the Havok Sdk, until we had the bare bones of what we needed.  For this to work we needed to initialize the contact listener first, by giving it 2 rigid bodies which it must search for a collision between, this would be an issue I’ll explain later. Once that is done, the contact listener must be attached to one of the 2 rigid bodies in the initialize function.

           How Havok handles it after that I do not know, however there is one function I can call to check if the 2 rigid bodies have collided. This function is the contactPointCallBack function, which is a virtual function so we can redefine it. This way in our game we have it so that we can set what the function does, which in our case sets a Boolean value for hit to be true.

 

 Issue 

The issue with this is that the only one object will know if it has collided with the other. For example if the listener was attached to the bullet, and the bullet collided with the enemy, only the bullet would know that it had collided with the enemy. The initial response I had was that I should just add another listener for the Enemy for that bullet, but that would not have been preferred.

    Figure L5

Looking at my initial thought diagram (figure L5); this would be one heck of a tangled messed if I did it that way. First, every enemy would have to check every bullet and the same vice versa. This is highly problematic because we wanted to have special attributes per bullet, so the bullet and enemy would have to communicate at some point. Another issue is that the when a new bullet is added, existing enemies will have to add another listener for that bullet. Finally when the enemies/bullets despawn, how do I know which ones to stop checking for in the opposite class?

 

 Solution

           Thinking about these problems, I though the only solution is some form of reference to the object it was searching for! To do this I initially had to decide which object will be referred to and which objected will have the listener.  The answer was simple; the bullet would have the listener, while enemies will be referred to. This is because no new enemies will spawn within the lifespan of the bullet (3 seconds or hitting another object), unless its end of a round.  

           Doing this meant I had to modify the listener class to take in a pointer to the enemy. This would modify the bullet manager to take in the enemy vector, so that I can get the pointers of all the enemies in the scene. Once that was done I had an array of bullet listeners, one for each enemy, each initialized in their own function (figure L6). The bullet will have to check the listener if it got hit, using a Boolean. With this when there is a collision, we can now have the pointer to the enemy call its hit response function, allow for more logical and easier to read code! Figure 6