When I first started in making the sketch, I thought that it would be quite simple. By substituting the ellipse with an Attractor object and incorporating some Mover objects into the sketch I thought I could quite quickly come up with a solution. However this was far from the case. During my first testing of the program, it did not work and frequently crashed, and the solution, and the cause of the problem was not immediately obvious.
After some initial tinkering, I could not come up with a method to fix the bug. The program would start up but not display the mover or attractor objects. The program would also tend to crash after a period of time. As the objects were not displaying, I guessed that the problem was with them.
A method described by Wenham (2014) as using “tracer bullets” was very useful for finding the problems in my code. “Tracer bullets” is the method of using print statements to print certain variables (such as println(position.x);) to the console. By doing this at different stages of the program’s algorithms the programmer can find out where in the program the error is occurring. I was able figure out the source of the problem by printing the location and velocity values of these objects to the console. The main problem of the sketch was that as the sketch started up the Attractor objects were passing null values, which are variables with no actual information in them, to the Mover objects. This was because the Attractor objects position and velocity depended on there being information from the camera to interact with. In the end, this meant that the objects were not being displayed. I fixed this error by encapsulating the calling of all the objects in the if statement if (video.available()) which was used in the example I based the sketch off so that frames only get saved if the camera is useable.
After modifying the sketch, I managed to get the objects to display. Although this fix worked, it was a very quick solution that I used to be able to test the sketch quickly and it might not be optimal in the long run. Another, more error-proof way to improve the sketch would be to initialize the values at the start by giving them some values to start with. This might fix the sketch even further as there were still some problems with them not displaying every frame during testing. In addition the movement was very slow and jerky. I think this problem has to do with how the sketch is not really optimized to use the camera or to handle a lot of objects at once. Some of the things I could do in the future to try and fix these problems are:
- Limiting the frame-rate
- Optimizing how the objects are handled in Processing (for example finding the best way to load the Attractor objects and make the Movers respond to them.)
- Initializing values for all the objects, so there are no more null-pointer errors
However as I have had so many problems with getting this sketch to work, and the end result might not even be optimal, as I have had problems controlling the example it is based off (as detailed here) for now I will look at using a different method of camera interaction and if that will be a better solution for my project.
Although I might not use these testing sketches in my final project, it was very useful to learn about the proper methods of code testing and common problems people have. As I am fairly new to creating more complicated programs hopefully learning about these will help me solve problems faster and more efficiently in my future sketches.
Wenham. C. (2014).How to fix bugs, step by step. Available from: http://www.yacoset.com/Home/how-to-fix-bugs-step-by-step [Accessed 11.12.2014.]