The weather is quite good today.Today is spent mainly on cleaning up whackapeng with two shapes (continued from last thurs). Finally, managed to spot the error that I was facing - I had mistakenly used the * operator instead of the *= operator as well as the || instead of a && for the loop condition to initialize random points, thus making the program act strangely and go into a infinite loop occasionally.
Of course, solving this was not alone, it was together with the help of C2E and Kevin.
We finally ended our day at 7pm.
Tuesday, 15 January 2008
Stress testing of Lightdraw game to see if the changes made yesterday actually solved the problem. And they did. :)
The game did seem a bit slow - due to a single processing thread attempting to accept light input, calculate all the shape and enclosed detection, then followed by rendering it out on 4 different displays (for debugging purpose), which made the light trail very segmented each time it ran through the loop.
Thus I decided to carefully examine each line of the source code to see how I could actually reduce excessive and/or debugging code and thread some methods to better the overall game play.
23 pages of code, 2am.
Wednesday, 16 January 2008
Today was spent working on the threaded version of the Lightdraw Game (Whackapeng) two shapes. Managed to finally get the threaded version to work as well as renamed and deleted some methods and variables which were poorly named and declared but not used respectively.
However, some of the resulting problems are:
The program seems to run worse on a single core than the original Lightdraw Game on all four cores. Perhaps the original Lightdraw game will be much worse on a single core? I tried the threaded version on 2 cores and it seems to work better, if not, slightly slower than the original Lightdraw on all four cores. Maybe the conclusion is that the game will need around 2 cores to run at least?
There is a memory leak which I have to fix tomorrow.
There is a segmentation fault which appears sometimes, which does not appear some times, which I have to fix too.
Thursday, 17 January 2008
Fixing the two aforementioned problems in the threaded code. (Ironing them out).
Today, I will also try to use the Mii Editor to replace the game pieces for the Lightdraw game to the Lightdraw team Mii characters! Should be pretty fast and cool.
Fixed the time elapsed problem today as well. Which I think this is something interesting to think about. Initially, I had used the processor ticks to attempt to calculate the total time used for playing the game. In the beginning, it showed results like 112, 142, which did not raise my suspicions as the code was slow (single thread) and drawing did seem to take quite a long time. However, with the threaded version and the ability to draw smoothly now, it still showed values exceeding 100 and sometimes even up to 190 seconds ( more than 3 mins).
After reading more about it and pondering about
Anyway, with the help of Harold and Kevin, I changed from using the data type clock_t to time_t which solved the problem. Now, I was taking the system time to do the calculation, which solved the inconsistency.
Friday, 18 January 2008
Final clean up of Lightdraw game. Tidied up the code and removed all the rest of commented out codes which were used for debugging or what not. Also added some commands in the drawing of game piece method to turn of the encircled flags. Hopefully they solve the problem.
We demonstrated the rest of our programs and drawn up some plans for the next week, including optional projects, such as adding vertex detection to JL's code as well as doing the UML for a OO approach of Lightdraw.
Reflection of the Week:
As promised, this week's reflection will be about collaborative work using the internet.
During the previous week, I've been checking out the OpenCV yahoo groups' previous threads in search for some answers to my problems. While there, I noticed a few threads asking about how to use OpenCV library with Visual Studio / Windows Environment; and since I had already configured my own environment as well, I thought why not help them. Helped around 3 threads when someone pinged me over the in-built web messenger and asked to clarify a doubt regarding my post.
Soon after, a second person pinged me to ask something about the IplImage class attributes and so on. Within the week, I helped 5 people (complete strangers) through the in-built web messenger.
With the widespread use of technology, I believe it has become much easier to tap on the expertise of more experienced users for help (the way I use the OpenCV groups too). It allows for collaboration all over the world and uses a community based approach to problem solving, instead of the traditional way of independent learning (having to search through books and white papers and not being able to share our knowledge after we have learnt something new).
However, we cannot always be sure that what the other person said is guaranteed to work for us. But I believe that is the nature of learning - curiosity and experimenting will help us find the answers we need and make us more knowledgeable.
What new things or approaches will technology yield next? And more importantly, how will technology affect the way we learn and our approach towards problem solving in the area of having the patience and discipline to slowly sieve through book after book (or link after link) of irrelevant results to find what we truly need?
Right now, I see some users (not majority) of forums and online community portraying impatient attitudes when questions go unanswered and self-centered approaches instead of community base / teamwork. Is this caused by the fast pace of technology which results in them expecting equally fast answers to their problems?
Food for thought. (pun intended)
Oh, one last thing, this week is Doc Green Theme.
No comments:
Post a Comment