Today, is Monday, 24th of December 2007. X'mas eve. Which means that everyone gets to leave work early at 12.45pm. Today, we left work early, but it was at around 4pm, earlier than normal days I guess.
Today I still continued to research and refine my code on detecting a single point within any given shape, represented as an array of points. And finally, it reached a workable and acceptable state. I initially wanted to improve more on the code, but I guess with the datelines for SAB nearing, we'd better combine the code first. Better one working program with some bugs than two perfect files with no working output, JL reminded me.
And thus, we took code 1 and code 2 and mashed them up, and my luck, we got a working program. Well, not really by luck, but by a lot of re-editing the method signatures and copy and pasting code from one to another. Alas, a working game code, just with a couple of issues to iron out, such as the scoreboard, threading time, debugging outputs being printed at the background, etc.
Tuesday, 25 December 2007
Today is Christmas. Did I get many presents from Santa? Well, I've got all my friends around me. That should be enough for me, right? :)
Wednesday, 26 December 2007
Well, what else could we have done today, save for improving the game code? (its called whackapeng.c, btw).
Well, there are 2 major changes which we made today, and shall highlight them here:
Firstly, we ironed out some bugs in the game play, to name a few, were the encircling counter and circle sensitivity. It was hilarious when we started to test the program, and after attempting to draw 10 shapes (for level 1) to see if the code works fine under a happy flow, we realized that we had forgotten to add code to keep track of how many shapes have been encircled. Interesting.
The second problem we faced as that by drawing a small enough square/rectangle, by just basically completing 2 out of 4 sides, and a little start on the third side, the program will immediately assume its a circle (due to its small difference in diameter of the 3 random pair points) and draw a circle, which, if enclosing the center of the shape, will be considered as a successful shape encircling. Thus, I had to reduce the sensitivity of the circle detection, dropping the difference in diameter from 12 to 10. This change did not eliminate the problem, but only reduced the chance of it from happening, and the player had to draw a really shape to get it. Alternatively, was to totally trash circle detection for the game play, since the code for n-gon point detection will work fine for circles as well too, I believe.
Decisions, decisions.
We also added a high score board after the successful encircling of the shapes, though its just a dummy board as we have yet to think of a way to perform I/O effectively for the scores and the possible logo. hmmz.
Thursday, 27 December 2007
Well, with the main functionality of the game working, its time to improve it, pondering about the overall threading issue + file I/O.
One of the problems faced for the threading is that after every 20 seconds, the program will clear the screen of all drawings, just in case the user has drawn too much on the screen to effectively continue the game. Though when the thread that is in-charge of this goes to sleep for 20 seconds, it loses track of the game play. So even if the game had already moved to the next shape, or has been manually cleared (if ever it occurs during actual deployment), it would be impossible to alert the thread to stop and restart the count down timer, so that the clearing of the screen will effectively take place 20 seconds after the new drawing has been rendered on the screen. Or is there? hmmz. (I wonder if there is something akin to Java's wait() and notify() methods?)
File I/O is just thinking of how to solve the storing and retrieving of high scores for each level and the possible corresponding player logos for each of the high scores.
Been thinking...
Friday, 28 December 2007
I'm still working on some improvements of the game (e.g. overall threading issue + file I/O). Still not quite there yet. Took the last 3 hours of work or so to practice and revise for my SCJP exam, which is tomorrow. Hopefully I will do well :)
In addition to today, JL did a very cool code of using the light to drag primitive shapes around the screen. I can already see the HCI forming. :)
Reflection of the Week:
What did I learn for this week? Well, basically, its performance and the effect of inefficient code.
Lets start with performance, which I would be referring to code performance, as our entry point. Many times, our deployment environment or developing environment is quite powerful due to the use of modern technologies or high powered hardware. Which indirectly leads to more inefficient code being written. Why do I say that? When coding a function to solve a problem, there is little regard to the amount of memory that will be used by the function or the entire software. The code will run with little or neglectable performance degrading.
Thus even if the function is very inefficient, it won't really matter cause during development phase or (even deployment phase), only one application is tested at a single time, with a possibility of core 2 dual processor at 1.8GHz running in the back ground and 2GB of RAM. With regard to my experience in our school projects (again, this leads to school. But hey, isn't this supposed to be a reflection of my school experience vs the experience I am having now?), we develop applications that take little consideration of efficiency. Sure, we know what is the definition of efficiency, but do we really know the finer details of how to go about doing it in our code?
There was once I wrote a 1800 line class file for a very simple application - well, it probably beat the length of many people's code, but I bet it also beat them in being the most inefficient code. It had so many repetitions and nested loops, but when tested on my computer (Pentium 4), it was totally not a problem. Now imagine we put that code up on a not so powerful server in Singapore, and this application becomes really popular, with up to 3,000 concurrent users worldwide online calling it concurrently. Now we're really going to see the strain on the server. But if back then I've written really efficient code, perhaps of a couple of hundred lines, the strain would be much lesser.
So how does this relate back? Many times, the ideas that come to my mind to solve the problems I face within the code are not really the best way to go about doing it. Cramming all the code within a nested for-loop in a single thread and calling it to execute its loops repeatedly would probably cause strain on the program, which can be seen by the time it takes between when the light is captured by the camera, to the time it is rendered on the screen. The longer the time needed for the program to process the code, the larger the gaps become.
So conclusion? Thinking before coding :)
What a mess!
No comments:
Post a Comment