July 31, 2008 by Mark.

I’ve been slacking. No, really, mega slacking. Its been almost two months since I wrote something here. Earlier, I wrote about my latest employment opportunity at PWLabs. Well, that job ended abruptly. There was nothing wrong with that job, I enjoyed it fully, but several days after I started, I got a call from a recruiter that works for McAfee (Yes, the anti virus maker). Impeccable timing! He hooked me up with the dev team at McAfee and we had a phone interview. That, eventually, blossomed to a full 5 hour interview (you heard me correctly, 5 Hours!) where I took two tests on top of an in-person interview. Needless to say, I got the job and my brief career at PWLabs came to a close.

The stuff that they have me doing right now is guarded with an NDA, but its mostly going to be Win32 programming. My experience at BumpTop and at Strike Technologies helped me get my foot in the door. I always avoided huge Corporate jobs but this one actually made me excited.

For those that don’t know, McAfee’s engineering department is located in Waterloo, so the drive from Toronto is a bit time consuming. I ended up buying a 2008 Hyundai Accent for the trip, it’s not a bad car. Nevertheless, I will be moving down to this area eventually. Some places that I was looking at are in Cambridge, Kitchener, and Guelph. But that won’t happen for a few years anyway.

Posted in C/C++, Stuff, win32 | 1 Comment »

February 11, 2008 by Mark.

On my spare time (if there is such a thing), I have been slowly putting together my Game Engine. The foundational stuff is pretty much written and tested and I am just about to start writing the heart of this engine, the renderer. But as I’m thinking about the code structure, I am also debating if I should stick it out on the web as an Open Source project. I read up on a bunch of licenses but none of them were exactly what I needed. The type of license I’m looking for is one that would credit my name whenever it is used or redistributed. Also, it would force people who wants to use it for commercial use to cough up some coin. In other words: free for personal use, not free for commercial use, and my name to be always credited. Anyone know of a license like this?

One of the licenses I found useful was the MAME license. I might ask its author for a copy. On another note, I just set up an SVN server to host my engine. Also, I am slowly putting together a webpage for this project so people can easily find it. I’ll post the link soon.

EDIT: Dave advised me against using some of the lesser known licenses and advocated LGPL. I’m going to give LGPL a thorough read.

Posted in GEL, Open Source, 3D Stuff, C/C++, win32 | 1 Comment »

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 »

September 17, 2007 by Mark.

Almost any chance I get, I like to dabble in crazy things ranging from code optimizations to patterns and data structures. Well the last few weekends I had a some of time to kill and with my ever growing disgust of the STL Vector class, I decided to write my own (Growable Array class), just for the hell of it. Out of the box, Vectors are slow, especially when being run in debug mode. There are a slew of iterator checks, data verifications (during memory swaps, etc) and so on which completely turned me off of using the Vector class in time-critical applications such as games.

In that case, lets bust out some numbers. After I wrote my Array class (and optimized it, heavily) , I decided to test it against the Vector class in various different compilation modes. First was a regular debug build (without compiler optimizations), the second test was with full compiler optimizations, and lastly was a test using full compiler optimizations and that neat trick I mentioned in a previous post about disabling iterator checks (#define _SECURE_SCL 0). I was surprised to see the numbers once they came in, check them out:

 
Lots of Numbers! Let me explain what I did to get these numbers. The tests were conducted on 1 million integers within a loop, with the exception of the equals operator (operator=), comparison operator (==), the not equals operator (!=), and the Erase/Remove functions which were reduced considerably since they took so long. The numbers in brackets are the number of iterations that were done to get the result. Due to the debugging information that is added into the Vector class, the performance of the class will slow down to about one-seventh of the speed it should run at. But once all the debugging information is removed, you can really see the class fly. But I guess that was not enough for me. Once the Debugging information was removed and the compiler fully optimized the code, the Vector class was raised to the level of my Array class. It was on par with the majority of the tests, with the exception of push_back(), back(), and front().

One advantage that my Array class has over the Vector class is that it tries to use realloc() in order to grow, rather then trying to allocate new space and copying over the old info. Secondly, I scoured the web for some assembly tricks and stumbled upon an optimization paper written by AMD that mentioned the use of a buffer when copying information from one memory address to another. This is all done on the CPU, using registers. This function out preforms the stock memcpy() or memmove() functions that are included with Visual Studio. I also read that tapping into the MMX or SSE technology would give potential gain, but currently I don’t know enough about that technology.

Either way, I’m releasing the source for everyone to check out under the zlib/libpng license. If anyone has questions/comments/improvements to this class, please feel free to email me. Enjoy :).

Posted in C/C++, win32 | 1 Comment »

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 »

July 13, 2007 by Mark.

Writing a Win32 application that only acts on events and messages does not take much thought. The messages are streamed to the message processing function, they are acted upon, and then they are discarded. But what happens when your program needs to render or process something critical as fast the computer can go? Well, that also is not hard to accomplish but at the cost of the CPU. A loop such as that will take up the full power of the CPU whenever it gets a chance; essentially a power hungry monster. An application such as a game should take this into account. Take the following code as an example of what NOT to do (I apologize for the usage of PasteBin for this. Apparently WordPress sucks for code):

Attempt #1 Link.

This loop does do exactly what you want. It takes messages, hands them off to the message processing function and calls the Render function. But what happens when the program does not need to render, or worse, if the scene has not changed enough to merit a complete redraw. In that case, there are several things you can check for. One of which is to see if the window is minimized. Another check is to see if the scene needs to be redrawn. Take this example into account:

Attempt #2 Link.

A bit better, but it still will take up the majority of the CPU because the PeekMessage function is rather hefty and requires some time to process. In order to speed up the message processing, there is a way to do all your message processing all in one go rather then processing one message per loop. Further more, you can add in a Sleep() call into the loop for when the rendering is not necessary:

Attempt #3 Link.

Its a start, but there you have it. This Loop will only render when it has to and will yield CPU power to other applications when it cannot render. There are further optimizations that can be done to this loop, such as switching form PeekMessage to GetMessage when background processing is not required. That type of logic should only be considered for applications other then games because games will always have some type of calculations to do in the background that are not user dependent.

Also, there is a neat little function called TranslateAccelerator(). It speeds up translations based on a range of message types. I do not recommend using it on a large group of messages, rather for something like keyboard input or mouse input, it can add several FPS to a game. Furthermore, there have been some talks on GameDev.net about single thread versus multi-thread games, where all input is done on one thread and all rendering on another. I do not believe that using multiple threads to manage something as complex as rendering or input simultaneously would merit any kind of performance boost.

Either way, there have been numerous posts on a number of programming forums on how to write the perfect loop, and my own implementation is not the final say in its design. It is merely an example of how to begin writing a smarter loop. At the end of the day, a decent main loop will decide if your application takes up 99% CPU power or less then 5%. Happy Coding.

Posted in win32 | No Comments »