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

Degbugging by Logging

In this blog I will talk about how we log.

So what logging am i talking about?

No I'm not talking about activities to do with tree trunks but the recording data occurance. 

Logging data acts just like how many business uses a book or chard to record business transaction, or black boxes record the flight data of planes. Logging code will generally save code to a specific file, but it can also help with debugging by printing it to the console. This can help by saving test data, or helping identify how code crashed. 

So how can we do this (in c++) ?

In c++, the language I mainly code in, there are 2 different ways of doing it std out, std err. Both of these generally uses Std in to get input from the keyboard, unless there is another 3rd party library. Std stands for standard library for those who are wondering.

·

•   STD out, this is a simple output, which can saved in a file or outputted the console. This is a buffered output, which means it will save to a buffer until it gets full, or flushed, which is when you tell it print. With this buffer you can save a lot to the buffer before printing it, making it a good for variable checking. The issue with this is that if the game crashes, or has a break point, right before the std out, it will not print.

•   STD err, err standing for error, this is a different output, which isn't buffered. This is because it will always print whenever it is called. This is good for unstable code, so that you can print out the error type when ever the code crashes.

Debugging Tip: Assert() is a useful function which doesn't log but will help with debugging. It will crash the program when the specific conditions are meet. For example if you want to make sure the player will always stay below a specific speed. This could be due to the fact the player will clip through objects if he is too fast.

Asset (player speed<100);

 

How to define a good logger 

 In class we defined a lot of definitions for what should consist of a "good logger". The following 4  points where the teacher agreed were most important through out the discussion. There are many agrueable good features left out, so feel free to add them to your debugger.

1.  The first thing you should do for a good logger is that if there is a logger class, it should be template and a singleton. Whenever a class needs it, it should get a reference to the singleton object. This is the correct way rather than just have everything inherit from it and create other instances of the class. 
2. The second thing is that the logger should have some ability to print the data being outputted/recorded to the screen. This is quite useful when monitoring constantly modified variables, such as player position, speed, or health.
3. The third is the priority or level of the bug which has occurred. With your logger you should be able to define the level of the bug which you have just encountered. With this the bug can be
4. Be able to specify a variable to track with the logger. The current value of the variable will be tracked every frame, recorded and/or outputted when specified.

With a logger at your disposal when creating a game/ debugging a project, it can help drastically. This can help identify problems early or solve existing ones