January 20, 2008 by Mark.

During my studies, every assignment I have been handed (with the exception of one) has been started from the very beginning. I was asked to produce an end result by designing, implementing, and testing the software I have written. I have no problems with the Software Development Life Cycle, its actually logical and concise. What starts to bug me is being shoved into a very dirty, unorganized code base and then told that I am not allowed to clean up. Instinctively, my brain figures out more efficient ways of doing things with the code then what is presently in place. But what I’m told is that features have priorities. In the back of my head, I know this is a time-bomb waiting to go off.

So, I move on. Each task that needs to be done has to work with the dirty code, forcing me to jump through hoops. The new code may end up being buggy or having some undesired effect. Lets, for instance, say this new code causes a bug. A fix is issued and it takes 20 minutes to fix. In another portion of the code, something else breaks because it was hooked up wrong. Another 20 minute fix. And so on, and so on. All those 20 minute fixes add up and eventually take up more of my time then it would to refactor the old code into something that is easily extensible and understandable. At this point, the code is twice as big and refactoring would take 2 days. Also, each feature that would take 10 minutes to implement, takes more and more time to implement because the code is convoluted. 10 minutes turns into 15 minutes, 1 hour turns into 3 hours, and so on. Great waste of time, in my humble opinion.

So when is an optimal time to refactor? Would it be at the very beginning when the problem is initially found? Should we wait until the critical features are implemented? Should we just forget about it and keep adding patches until the code is a giant maze of unreadable spaghetti? Why should my job turn into a Dilbert comic?

I honestly don’t know. My first instinct is to give refactoring a try at the very first time I notice a problem. Fix it before it spreads, essentially. Some think otherwise.

Posted in C/C++, Seneca, BumpTop | No Comments »

November 5, 2007 by Mark.

The Presentation Info:

Location: Seneca @ York, room T2109.
When: Tuesday, Nov 6, 2007 at 11:40am.

I will be discussing the relationship between Human Computer Interaction and high performance 3D graphics. Also, I will demonstrate the work that I have been doing lately on the BumpTop 3D Desktop. All are welcomed to attend.

Posted in C/C++, Seneca, win32, BumpTop | No Comments »

October 22, 2007 by Mark.

A few weeks ago, I aimlessly wandered into Dave Humphrey’s office and we had a quick chat and got to catch up on what we have been up to. I inquired about the Moz Dev stuff thats going on in Seneca, and he inquired about my job at BumpTop. As our conversation went on, he asked me to show him what BumpTop looks like. So as I was pulling out my laptop, Evan Weaver and several other teachers managed to squeeze into Dave’s already cramped office. I gave a quick demo to them all and, to make a long story short, It caught the attention of Evan Weaver and the like. He expressed an interest in having me give a short presentation to his game programming students. I agreed. Since Cathy Leung is teaching games programming this semester, I will be presenting during her course, on November 6th at 11:40am. I don’t quite have the information on where it will be held or what I’ll be talking about, but stay tuned and information will be posted soon. There will be a demo of BumpTop somewhere in the midst of that presentation.

On a different note, I’ve begun diving head first into the magical world of assembly language. Oh how marvelous it is. Mainly, it has to do with building my game engine and trying to take advantage of the SSE/3DNow! architecture.

Seems fun so far (Famous last words).

Posted in C/C++, Seneca, BumpTop | No Comments »

September 7, 2007 by Mark.

The problem with using SEH (As talked about in my previous blog) is that it does not catch any debugging information that is included inside any of the STL headers. I ran into this problem last night when trying to test the crash handler and I was baffled to see that my program was crashing outright and the crash handler did not work. I tracked the problem down to STL’s Vector class. When compiled in Release mode, the Vector class still contained debugging information which allowed the Just-In-Time (JIT) debugger to kick in and attempt to debug the application. This is bad because the JIT debugger has priority over any other exception handling. Consequentially, the crash handler was not fired and the mini dump was not created and emailed.

So how does one fix this? Actually its just a one-liner. Just by defining this before you include the Vector class removes the debugging code form compilation:

#define _SECURE_SCL 0
#include <vector>

In addition, the debugging code inside the Vector class is all over the place. It will literally remove a massive chunk of assembly code from the executable (and in the case of games, it will push out an extra 20fps or so). Having safety inside STL is nice when you do not have a crash handler, but it can create problems. However, it does compromise security because if you create a buffer overflow, it is easy to exploit that. I would suggest that if your interested in knowing more about this, check out this article, and the MSDN article on Checking Iterators.

Posted in win32, BumpTop | No Comments »

August 24, 2007 by Mark.

The last few weeks or so were ridiculously busy at work. The BumpTop internal alpha release is nearly completed and we will be shipping it out to a select few so that they can test it. I am really excited to put the 10,000+ lines of code that I have added to the project to the test in the real world. All of it has been a challenge thus far and as a consequence, it probably contains numerous bugs that I alone was not able to find. So, before the alpha is being shipped out, I am adding a neat snippet of code that allows me to do a stack trace on the executable. This snippet of code dumps the call stack and current variables to a file and then emails it to me for debugging purposes. Unfortunately for all the people that shun the Microsoft C++ Compiler, this is only available using it because the compiler itself exports a debugging database, which the crash can use to identify symbols (variables, line numbers, function names, etc). There might be other compilers out there that export symbols or failmaps, but since this is all new to me, I have only tried it using Visual Studio.

So, on to the code. Now before you scroll down and click the link, let me explain how this code works. Firstly, it uses Structured Exception Handling (SEH), which is much like C++ exception handling but its proprietary to Microsoft. The difference is that SEH does not call the destructor on local objects when the exception is caught, while regular C++ exception handling does. Secondly, the syntax for this type of exception handling is rather different because it uses the proprietary __try and __except keywords to catch the exception. The __except keyword can call a specific type of function that is referred to as a “Filter” by MSDN. This filter is where all your stack tracing and memory dumping can happen. Within this filter, I access a library by the name of DBGHLP.DLL. It contains a function that will dump the contents of a call stack into a file. This dump can be opened by Visual Studio and run much like a regular program. At that point, the contents of the crash can be seen and easily debugged by the programmer. But enough chit-chat, here is the Code.

Also, since the BumpTop alpha is going out internally the public alpha will be available very soon (within a week or two). If anyone is interested in helping with beta testing, please send me an email to mark(NO_SPAM)@bumptop.com. Please remove the (NO_SPAM) string in the email address.

Posted in win32, BumpTop | No Comments »