| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Nov | ||||||
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
- 3D Stuff (9)
- BumpTop (5)
- C/C++ (16)
- Open Source (6)
- Radiant (8)
- Seneca (4)
- Stuff (11)
- Uncategorized (14)
- win32 (11)
- November 10, 2008: Radiant Update
- October 28, 2008: Primary Export: Pain
- September 7, 2008: Results
- September 5, 2008: Multicore Processing And Game Engines
- July 31, 2008: Work++; // Again!
- June 8, 2008: Patterns And Such.
- June 4, 2008: Work++;
- May 20, 2008: SIMD And Randomness
- April 30, 2008: Coder Burn-Out
- March 26, 2008: Some GameDev Math Resources.
Author Archive
Radiant Update
November 10, 2008 by Mark.
I held a bet with my brother to see who can guess the number of lines of code (or at least, close to it) my rendering engine is comprised of. Neither of us were close but I got a good sense of how much work went into this giant mash of code. About 25,000 lines is the total. That total is comprised of approximately 12,000 lines of computational code and about 13,000 lines of comments. This number does not include blank lines and such things. Regardless, it’s a staggering number for a project that is being worked on by one person, part time.
The engine itself is about 45% complete, with the majority of planning done. One of the components, my math module (it handles math stuffs and collision detection), is finally finished. I can breath a sigh of relief, it’s not easy stuff. Unfortunately I didn’t write any unit tests for it so I don’t know if it actually works or not. The project is open source. So, if anyone is masochistic enough to write a tests for my math module, by all means :).
Posted in Radiant, 3D Stuff, C/C++, Stuff, win32 | No Comments »
Primary Export: Pain
October 28, 2008 by Mark.
Everyone knows (or should know) that when you put together a DLL, you need to export functionality so that programs using your DLL know where to find your functions. This is usually done by prefixing classes or functions with __declspec(dllexport) or manually writing a definition file. Straight forward and right to the point. But what happens when you need to export something that does not have a name. Say for example, an overloaded new operator. What the hell does a new operator look like as a definition symbol?
I’ll give you a hint: its not human readable!
So, before I actually spoil the beans and tell you what I did, I have to explain why I did it, because its rather interesting. Radiant, my game engine, is split into 6 DLLs, all of which touch and create dynamically allocated memory somewhere. The problem with allocating memory all over the place is that you need to delete it in the same address space (or DLL) as you allocated it in. With that said, to make it more complex, I had to overload the new and delete operators in order to wrap around _aligned_malloc() and _aligned_free() calls. This is a special type of allocation that allows you to align dynamic memory to an address that is divisible by 16 (or any other value). This is crucial if your using SSE or any special instruction set because all values need to be aligned to at least 16 bytes.
Anyway, going back to the problem at hand, I have a bunch of overloaded operator functions that cannot be exported because if I try to add the __declspec(dllexport) prefix to them, the compiler will scream and tell you that the declarations of the functions do not match up with what is defined internally. Basically, what I am stuck with are a handful of functions that cannot exported programmatically. This is where the definition file comes into play. Exporting a function or class is as easy as entering its name in the definition file under the heading of EXPORTS. But here is the kicker, the overloaded operators of ‘new’ and ‘delete’ do not have a name! They are declared internally in a header that exists in the compiler’s own static data, and there’s no way to override inclusion of that header. Therefore, the only way is to manually enter the function’s mangled name into the definition file.
The mangled name looks something like the following:
| ??2@YAPAXI@Z | (void * __cdecl operator new(unsigned int)) |
| ??3@YAXPAX@Z | (void __cdecl operator delete(void *)) |
| ??_U@YAPAXI@Z | (void * __cdecl operator new[](unsigned int)) |
| ??_V@YAXPAX@Z | (void __cdecl operator delete[](void *)) |
In fact, those mangled names are fairly generic and may not match up correctly. But their names are very similar to what they should be. A more specific example of the name would be located in the Visual Studio directory under VC\crt\src\intel\_sampld_.def. This file contains a slew of definitions. What your looking for are the first four definitions that look very similar to the ones posted above. If you are running under a x64 or Itanium architecture, there are definition files for those architectures as well.
After a successful compile, all dynamic memory is allocated and deallocated in a single DLL’s memory space. This prevents the Heap Corruption errors I was getting before and allows me to further enhance the allocation and deallocation of dynamic memory. Woot!
I would suggest reading the following link because it contains a very good description of how this process works. Unfortunately, I stumbled upon this file AFTER I already fixed this problem. Alas, C’est La Vie.
Posted in Radiant, C/C++, Stuff, win32 | No Comments »
Results
September 7, 2008 by Mark.
I finished writing my own Thread Pool subsystem and then put it through its paces. The results are obviously not that shocking because anything that is multi threaded is more efficient on dual core machines. The machine I was running it on has a AMD Turion 64 X2 CPU and sports two 2.0Ghz cores. It’s not the best machine but its quite speedy for what it is.
Anyway, as I mentioned in the previous entry, threads are great and run best when they have a dedicated core. When there are more threads then cores, the OS then has to time-slice in order to give the threads equal time on the CPU. Having a dual core machine, the optimal amount of threads that I can handle is 2. The following is a graph of the time it took to process 50,000 square root calculations, 100 times in succession:

On the first run, I did not use any threads. Rather, I let the calculations run in sequential order on the main process. The blue bar represents the thread priority at normal and the purple bar represents the thread priority at Highest. I did this in order to measure the speed difference between the normal and highest priority setting. I should also note that even though the thread priority can be manipulated, it is up to the OS to enforce that. In some cases the OS may decide not to enforce the request for higher priority and give the processing power to other threads.
The second and subsequent runs were using the Thread Pool with an increasing allotment of threads. Each 50,000 calculations were plugged into its own Job and sent off to a worker thread. Having only one thread was not much of a boost over a single process (Took about 1920ms). The main process was put to sleep using the WaitForSingleObject() function call while the worker thread did the processing. At two threads there is a massive increase in time. Just as one would assume, the amount of work was spread over two cores and the time it took to process it all was cut in half (About 950ms). This is the optimal amount of work my CPU can handle because each thread has a dedicated CPU core. Increasing the amount of threads actually increased the amount of time it took to process the calculations. The reason being is that the OS had to time-slice the different threads on both cores. The time increased by about 20ms each time I increased the number of threads.
Thread Pools are very efficient at what they do. As mentioned in the previous entry, creating a thread and destroying a thread could have increased the amount of time required to process a batch of 100 calculations. Regardless, the work I done is Open Source and as is my engine. You can download it here (I’m not responsible for unexplained fires, deaths, or alien abductions due to using this code).
Posted in Radiant, Open Source, 3D Stuff, C/C++, win32 | No Comments »
Multicore Processing And Game Engines
September 5, 2008 by Mark.
I have been passively researching multicore processing for the last few weeks and I came to the conclusion that it is rather easy to implement. In its simplest form, all you need to do is create threads and have them do Jobs. The OS will then schedule a thread to be run on a dedicated core. Having multiple cores makes those threads run at the same time as opposed to the old time-slicing method of single core processors. But, at the very base level, it’s rather primitive and can actually be improved upon.
Creating threads and closing them is fairly fast but may be a bottle neck if the engine does that consistently. The best way to handle this is to not do it, obviously. This is where a Thread Pool comes in handy. It creates a bunch of worker threads that don’t get destroyed until the program exits. Each thread will sit idle until a job has been passed into it to be processed. This involves the use of critical sections and semaphores to accomplish and is much faster then allocating and deallocating threads. A critical section is optimized for speed as compared to any other form of asynchronous data sharing and messaging (alternatives include Mutexes, Events, and so forth). The rule of thumb is to create enough threads so that the OS does not have to time-slice. This is usually done by allocating [num of cores] + 1 threads.
In order for a Thread Pool to work properly, it requires a few things. Firstly, a Job queue. This is a long list of jobs that will get distributed between the threads once threads become available. Secondly, some sort of thread state management. It includes a set of states that the threads can be at. The basic types are ‘Working’ and ‘Idle’, but it can vary on the amount of complexity you add to the Thread Pool. Lastly, it requires data sharing. I suggest writing an object that wraps data around a locking/unlocking mechanism (Semaphores come in handy for this task). Once these aspects are implemented, the Thread Pool is basically finished.
Usage is another key role. Lets assume that you either use the built in Win32 Threading pool or roll your own, it doesn’t matter which one you do. Furthermore, you have some very repetitive code that you want to multithread. If you don’t quite know what is multithreadable, the best place to start looking is in any for loop. The place where I’m going to use my Thread Pool is in a loop where I would have to update some world object, such as a player state or even scene management. For example, this loop might call your world object and cause it to return collision information with its nearest neighbors. Plug the world objects into the Thread Pool, have it run asynchronously and output some data into some shared object. As it’s doing this, have the main thread wait or do some other processing until the output is realized. Once its all done, the Thread Pool will suspend its threads and the main thread can resume doing its job.
What this Thread Pool is designed to do is to complete small tasks asynchronously. Sticking a dedicated piece of code on one thread (such as a sound subsystem, or networking) is rather counter productive to a Thread Pool because it utilizes the thread until the end of the program. I would suggest that a subsystem that is substantially heavy be on a separately spawned thread instead. Another word of advice that I came across is to keep the amount of writing done on each thread to a minimum because it requires locks. The best approach is to have each thread write to its own dedicated memory that is attached to the Job that its processing. Keep the shared data read only when possible.
I’m in the process of implementing my own Thread Pool and once its done, I’ll post some metrics.
Posted in 3D Stuff, C/C++, Stuff, win32 | No Comments »
Work++; // Again!
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 | No Comments »
Patterns And Such.
June 8, 2008 by Mark.
I ended up having to refactor some of my rendering engine code this weekend. It was a tough job and it involved stripping several classes of their Singleton status. The first couple were easy because they don’t connect the any crucial system. One of them being a Logger that writes error messages to a file and console window. The last class I had to strip was my Event Manager system. Now, to put it in perspective, every hefty class that has a major role in the rendering engine (ie. Renderer, Windowing, Resource Manager, etc) needs to notify some other part(s) of the system of an event. For example, if the user resizes the window, the window class must then notify the renderer that it needs to resize its back buffers. But, the window class does not know of the renderer, so everything would be routed through the Event Manager. In order to send events through it, without coupling the Event Manager to any other classes, I used the Singleton.
It worked great! Until I tried to multi thread my renderer or place the rendering portion of my code inside a DLL. Hell broke loose and my whole architecture failed. Back to the drawing board I went. As a side note, when I started searching for a new way of dealing with this, I came upon a really cool website which proudly displayed this image:

Hilarious! I thought, Who would of thought that Patterns can be displayed in a periodic table. But that was beside the point. I eventually came to the conclusion that one must make a singleton but without a singleton. My solution was this: Create a Factory that spits out message dispatchers, but with a slight twist. Only spit out a pointer to the same dispatcher over and over, therefore creating only one instance of that dispatcher for all objects that want to use that specific Event subsystem. Why, you may ask. Because that lonely dispatcher knows how to communicate with the Event Manager. As the Dispatcher was being created by this factory, it was given a pointer to the manager. So now you have a direct link between a Dispatcher and the Manager. Lastly, all you need is an Event Listener. This listener takes in a pointer to a dispatcher and since it knows how to contact the Manager, it registers itself with it so that it may receive messages. All the programmer has to do is derive a class from this Listener class and it automatically has the capabilities to send and receive messages. To an extent its a fancy version of the observer pattern. I especially like this because I just replaced a Creational pattern with a Behavioral pattern.
This is not the only method I came up with, but its the cleanest one. Although, it sounds like there could be problems with memory management and loose pointers, but I do not believe so. I posted a question regarding this on GameDev, and there was a plethora of responses. I used that as my platform to kick off searches that were more in depth then what was talked about.
On a different note, I used a program called StarUML to model my entire engine. The results are here, but I must warn you, its big, its complex, and not quite finished. Feedback is always welcome as I am always looking for ways to improve it.
Posted in Uncategorized | No Comments »
Work++;
June 4, 2008 by Mark.
Some of you may know already that I have received an employment opportunity from a company called Parallel Worlds Labs (PWLabs). I took the job without hesitation for several reasons. Firstly, my yearly salary was increased substantially. To some, this might have been enough to switch companies, but for me, it was not the main reason. Secondly, PWLabs makes 3D, interactive games and displays for museums and other such institutions. I saw this as my chance to pursue a career in Game/Graphics programming. Lastly, its mostly a work form home job, so my commute time is cut down from 40mins to about 10 seconds (The time it takes me to walk into my living room). So, as you can see, I am thrilled to start my new job.
Unfortunately, this will mean that I will be leaving my ever-vigilant post at BumpTop. The last year flew by quickly and from my perspective as a code monkey, it was not a bad job. Code was my passion and focus. I literally re-wrote the vast majority of BumpTop, made it stable and robust, and its something I would definitely put on my portfolio.
Posted in Open Source, C/C++ | 2 Comments »
SIMD And Randomness
May 20, 2008 by Mark.
Alright, I ended my zealous trek through the inner workings of SIMD just because I wasn’t using it enough in my project. Don’t get me wrong, its a really nice piece of technology to dabble in, especially when doing math on a large scale (say, Matrices). But for the day-to-day programmer in me, I really don’t get to use it as much as you might think.
But, I’ve done some detective work and most compilers nowadays optimize the code in such a way that SIMD gets incorporated automatically. Therefore, learning SIMD should be put in the same category as learning Assembly. Its nice to have but in reality it will be rarely used, if ever. I have a feeling that I’ll run into a situation where SIMD is required and its the only thing that can save the world from total destruction. Well, until then, I’ll just shelve it.
On the bright side, I finally gave my game/rendering engine a real name: ‘Radiant.’ I don’t know why I named it that, and for some reason, I never second guessed it. It was one of those spur of the moments that I hit F2 and started typing. Don’t ask me what or why, I’m still in the wilderness on that one. Anyway, progress on the engine is a bit slow just because the only time I get to work on is during bus trips to and from Hamilton, or other places. If there were more hours in the day, I could actually get something done.
I should also say that I’ve re-worked the way the engine is laid out because all my singletons were not working well with DLLs (I think I wrote about that, somewhere). This quickly because a mess. SVN likes things to be done in order and in small chunks, else it starts bugging you about cleaning up the repository. I like to do things in big chunks, literally taking a +1 Battle Axe to the tree and then rebuilding it from scratch. Bad tactic, I know. Lets just say, SVN was in pain. Poor thing.
As a side note, I found out something interesting today about the MSVC build system; It supports multi-core compilation! Its like your own distributed build but on your own machine, Hooray. More on this later.
Posted in Radiant, Open Source, 3D Stuff, C/C++ | No Comments »
Coder Burn-Out
April 30, 2008 by Mark.
Its been a while since I wrote something here, and with good reason. I have gotten to the point where I do not want to look at code when I come home. I am on the edge of burning out. Thankfully, my vacation starts in a few days. But this blog post is not about my fun-in-the-sun vacation, rather its about the politics of being a programmer.
A few days ago I had a conversation with a friend about coder burn-out. Most specifically, should a manager push the programmer to the brink of burning-out in order to move the project along? I say, yes. To a point. Pushing a programmer to work that extra bit is natural, and happens quite frequently in the industry. It gives that extra boost when the projects needs it. But, it is similar to adding nitrous oxide to an engine to get extra horsepower. If you don’t give the engine a break, it will break down. Pistons will seize, gears will grind, and the engine will come to a screeching halt. Much like an engine, all this can happen to a programmer (just it wouldn’t be as violent, at least, I hope not). From personal experience, when a burn-out happens, I cannot look at code. It literally makes me unproductive, sluggish, and resistant to coding. Moreover, I start to neglect personal projects and duties (such as this blog) that once made me happy.
Fortunately, I am nowhere near the point where I hate programming, but my pet projects have not seen progression in weeks. My vacation is coming up and it will be a breath of fresh air into a stuffy room. What I am wondering is, how do other people deal with coder burn-out? What are your strategies or things that you do to relax and get your bearings back?
Posted in Stuff | 4 Comments »
Some GameDev Math Resources.
March 26, 2008 by Mark.
I’ve been scouring the internet for some decent resources on math, collision detection, and physics, so here are some:
- Essential Math
- Game Physics Resources
- Real-Time Collision Detection
- Advanced Character Physics
- Simple Math Primer
- Flipcode’s Articles
- Harvey Cartel’s Collision Detection Site (Thanks Miksago)
More to come, later.
Posted in Radiant, 3D Stuff, C/C++, Stuff, Uncategorized | 1 Comment »