February 12, 2008 by Mark.

Seems that my favorite pattern is also the bane of my current Game Engine development. Turns out that a singleton pattern doesn’t like to play nice with Dynamically Linked Libraries. The whole notion of being dynamic is counter productive to static members inside functions or classes. Looks like the only way to actually fix this is to wrap it all up in a big handler of some sort and have the calling code manage it. Either that or create a section of shared memory in the DLL and allow it to manage the singletons. Seems like a bit of a pain in the butt just to avoid a global variable. Hmm, unless I can wrap it in another creational pattern, possibly Builder or Abstract Factory…

More research is required. And research requires Tea. Therefore more Tea is required.

Posted in Radiant, Open Source, 3D Stuff, C/C++ | No Comments »

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 Radiant, Open Source, 3D Stuff, C/C++, win32 | 1 Comment »

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 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 »