About this blog
High performance coding in my spare time
Entries in this blog
For those of you interested in the new upcoming SDK from the NeHe group, to replace my old NeHe SDK, here are some screenshots [grin]
Basic texturing (note, the art was done by other members of the NeHe group):
OBJ file loader:
The other big difference is that the new SDK works under linux & MacOSX as well as Windows.
As I'm redoing the Nehe SDK for the updated site, I've been looking into the libraries I can use without licensing problems - in other words licences that won't restrict the use to which the SDK can be put. Viral licenses such as the GPL are therefore a no no. I don't have a personal problem with the GPL, but as a commercial developer I have to know the legal consequences of every third party code I use.
This reminded me of a problem that few developers seem to be aware of - libstdc++, the Standard C++ library that ships with gcc is GPL. Most people think that like glibc, it is LGPL. Therefore, whenever you use the standard library in a normal gcc environment (linux, mingw, cygwin, etc), your application automatically falls under the GPL.
Fortunately there is a way around it, as well as standardizing your application to a single Standard Library. This is the well known STLPort which has a simple "as is" free license. This standardization also sorts out the STL problems with pre-Visual Studio .net.
Hopefully updating the SDK will help me write more in this journal, as my present position isn't especially game related at the moment [sad].
Since I seem to have annoyed Rob Loach with my last entry, this time, I'll write something useful[grin]
I have been spending quite a while writing an advanced test framework for my system, as was looking for a simple way of catching system exceptions, which were the main problems with the code being tested. The solution (plus digging through MSDN) was found here on Thunderguy's site. The only problem that I've found with it is that each version of Visual C++ needs a different set of compiler switches to allow it.
I've also being doing some Win64 coding, which is fun up to the point that the compiler that comes with the platform SDK doesn't allow inline assembler. Fortunately there's a NASM compatible assembler called YASM here that can handle 64bit assembler that can be linked to Microsoft code. Get the latest snapshot from the downloads page, as the official release (0.4.0) doesn't support 64bit in microsoft format.
If you have to cater for many platforms, you have to know a great deal about their conventions, especially if you have to mix assembler with your high level languages. Windows XP 64 is no exception, and Microsoft have given us a whole new set of calling conventions that make use of the expanded instruction set. Rather than explain it myself, I will allow such Microsoft luminaries as Raymond Chen and Josh Williams to do it for me. They both explain the same thing from their own point of view, but two explanantions are better than one:)
I have been told off quite often for my use of post as opposed to preincrementing integer variables, especially in my NeHe SDK, as it is bad practice, and therefore teaching bad practice.
The reason for this is that in certain situations a temporary variable is constructed to hold the value before incrementing, so readability must be compromised in the quest for efficiency.
Unfortunately, I try to only use postincrement in for-loops and discrete statements, such as the following example:
for(int ct=0; ct iter_ct++;
Strangely, when using integers (which is what we're talking about), both the above snippet and its preincrement twin compile to exactly the same code without optimization.
Pre-increment is useful in certain cases, but in most, it is merely a case of premature optimisation.
Efficency does not always mean lack of readability. Readability should always be in the forefront of code design.
Edit: put the NeHe SDK into my webspace, as NeHe doesn't allow remote linking. Thanks for letting me know Ainokea!
It has been a while since my last entry[wink]. I have just been made redundant from my old work as a neuroscientist, so this means I should have a little more time to work on the middleware game solution I've been planning, health aside[sick].
Hopefully, I should be posting more from now on.
Writing cross-platform code is quite useful. It means that you have to research each part, so you have a better understanding of your code. However, porting inline x86 assembly from Windows to Linux causes more difficulties than it solves. The simplest solution appears to be to write assembly routines in their own files, using NASM to assemble them and then re-link them afterwards.
Fortunately the ports to the Mac and WinCE don't need the assembly sections, although they may be a little slower because of this.
For those of you that don't know, I spend some of my time at work programming medical software for the treatment ideas my group comes up with. Recently, I have had to write my code so that one of my students can use the libraries I write.
I have used most of the major documenting tools on the market, both free and otherwise, and find that it is almost impossible to write comments that are legible in both the source code and the documentation, finding that arcane means are required to get the style I need.
Yann L seemed to be having a similar problem, and one of the replies he got (I can't seem to find the thread in question) told him to use NaturalDocs.
After some initial annoyance (directories with spaces in seem to confuse it) I found it wonderful - mainly because it used a similar "english" way of laying things out to the way I was doing it before.
As my hands are getting less useful, this saves me a huge amount of post-documentation work[grin]