11 August 2008, 18:25 in

OpenGL vs Direct3D

This old article, by Paul Hsieh from 1997, describes some of the significant historical events that occurred in the early days of the OpenGL and Direct3D graphics APIs.

The following is from a 1996 entry in John Carmack’s .plan file:

The overriding reason why GL is so much better than D3D has to do with ease of use. GL is easy to use and fun to experiment with. D3D is not (ahem). You can make sample GL programs with a single page of code. I think D3D has managed to make the worst possible interface choice at every oportunity. COM. Expandable structs passed to functions. Execute buffers. Some of these choices were made so that the API would be able to gracefully expand in the future, but who cares about having an API that can grow if you have forced it to be painful to use now and forever after? Many things that are a single line of GL code require half a page of D3D code to allocate a structure, set a size, fill something in, call a COM routine, then extract the result.

The world of computer hardware and software has changed a lot since then, but the information is interesting nonetheless.

Also see this comparison between OpenGL 1.2 core and Direct3D 8, and the Wikipedia entry on Direct3D vs OpenGL.

Comments

7 April 2008, 12:37 in

John Carmack's dev diaries

John Carmack is one of the co-founders of iD Software and lead programmer of famous computer games including Wolfenstein 3D, Doom, and Quake. It is old news by now, but his development diaries from 1997 to 2004 have been put up online. There is some interesting stuff in there, and it is worth a look if you are a programmer or a fan of his games. He also maintains a blog but it seems to be very infrequently updated.

John Romero, famous game designer and programmer and the other co-founder of iD Software, also has a blog.

Comments

24 May 2007, 21:13 in

How to write unmaintainable code

Brian sent me a link to an article How To Write Unmaintainable Code written by Roedy Green. As well as being funny, it’s a very good guide of what NOT to do when you’re programming.

A few excerpts that I particularly like include the following:

Thesaurus Surrogatisation
To break the boredom, use a thesaurus to look up as much alternate vocabulary as possible to refer to the same action, e.g. display, show, present. Vaguely hint there is some subtle difference, where none exists. However, if there are two similar functions that have a crucial difference, always use the same word in describing both functions (e.g. print to mean “write to a file”, “put ink on paper” and “display on the screen”). Under no circumstances, succumb to demands to write a glossary with the special purpose project vocabulary unambiguously defined. Doing so would be an unprofessional breach of the structured design principle of information hiding.

Misleading names
Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database.

Document How Not Why
Document only the details of what a program does, not what it is attempting to accomplish. That way, if there is a bug, the fixer will have no clue what the code should be doing.

Be polite, Never Assert
Avoid the assert() mechanism, because it could turn a three-day debug fest into a ten minute one.

When To Use Exceptions
Use exceptions for non-exceptional conditions. Routinely terminate loops with an ArrayIndexOutOfBoundsException. Pass return standard results from a method in an exception.

I can definitely relate to many of these.

Comments

28 February 2007, 08:37 in

Windows Forms performance tips

Just came across an article on MSDN Magazine entitled Practical Tips For Boosting The Performance Of Windows Forms Apps. The article is from March 2006 but still very useful.

The topics covered include the following (plus more):

If you’ve ever run into any performance issues when developing .NET Windows Forms applications, this article contains some useful pointers that may help you solve them.

Comments

15 January 2007, 09:46 in

Article on memory leaks in managed code

If you work with .NET managed code you may want to have a look at the recent MSDN article Identify And Prevent Memory Leaks In Managed Code.

While on the subject of programming, I also came across some videos on software development which appear to be pretty interesting.

Comments

11 September 2006, 17:41 in

XNA Framework

The XNA Framework is a set of .NET libraries whose purpose is to allow developers to easily create games that will run on both Windows PCs and the Xbox 360. Check out this article on the XNA Team Blog for a good overview. It sounds like it will simplify a lot of the tedious aspects of developing games, such as enumerating display modes and so on.

Comments

22 August 2006, 22:27 in

Problems with QueryPerformanceCounter()

To make a computer game run at a consistent speed across different computers it is important to measure the elapsed time between frames and adjust the in-game computations accordingly. If this is not done the game will run too slow on a slower computer and too fast on a faster computer.

I had written some timing code which used the
QueryPerformanceCounter() and QueryPerformanceFrequency() Windows API functions which provide a high level of timing accuracy. The idea is to call QueryPerformanceFrequency() once to find out the frequency (in ticks per second) of the performance counter, and then, each frame, call QueryPerformanceCounter() to retrieve the current counter value. You can then work out the elapsed time between frames.

I had written a reusable timer class in C# for my Pong game (which I have just revisited). The code worked beautifully on my old P4 1.6Ghz and P4 2.8GHz, but when I ran it on my new Athlon 64 3800+ dual-core, the game behaved weirdly… Moving objects flickered and jumped back and forth.

I wrote a test program and determined that the QueryPerformanceCounter() function would occasionally return a counter value that was lower than the previous value by a significant amount! Shortly after this, the counter value would jump back up, putting it roughly back to where it should have been. This was causing the game to sometimes jump back in time by about an eighth of a second, then forward in time, resulting in the flicker affect.

Here is a screenshot from my test program. You can grab the C# source file here.
My test program for the QueryPerformanceCounter() function

My first thought was that something was wrong with my new PC! Nooo!! However a quick search of the web turned up that this problem is known. This thread on the Channel 9 forums describes the exact same problem and there is some good information in there. Apparently a Windows XP hotfix solved the problem for the poster. Also see this thread on CodeComments.com. MSDN also has some information here and here.

It seems this a problem that occurs on dual processor systems. Even if the hotfix solves the problem on a particular computer it is not really a solution because you can’t expect every user of your game to apply the hotfix. Not happy.

Comments

17 August 2006, 21:58 in

August 2006 DirectX SDK

The August 2006 DirectX SDK is available for download at MSDN.

The August 2006 DirectX SDK download contains the tools needed to build cutting-edge, media-rich, interactive applications. It includes run-times, headers and libraries, samples, documentation, utilities, and support for C++ and Managed Code development. NOTE: This DirectX SDK contains Direct3D 10 components that are not usable until the Windows Vista RC1 release. Do not install this SDK in Windows Vista for releases prior to RC1.

New stuff includes:

Comments

Older Entries