D

I’ve started reading up on the D programming language. (The book I’m reading is called “The D Programming Language” – รก la C – and I’d recommend it, if only for the humorous style.) And I have to say it’s very cool. Whenever I’ve used C++ in the past, I’ve thought of ways it could be better, more useful. There are probably posts in this blog about it in fact. Well D is basically C++, but with all the things that it should have had from the start. I’d like to talk about all the features but you might as well read about them yourself. When I find an interesting way of using one I’ll probably post about it here.

Where am I now?

It’s been over two years since I’ve written here, but I think I shall start again. I didn’t really add anything, that I remember, to pdEngine since the last post, and there’s not much that I’d like to add. It was a fun experience to write, but looking back it’s an inefficient mess.
Since then I haven’t had any major programming projects. I contributed a few lines of code to an indie game or two, I hacked some features into some audio software for my band and I wrote the odd little program to test maths theories I’ve had, but nothing major. In fact, I pretty much forgot any intermediate to advanced C++ I knew. Reading this blog has taught me things.
In three weeks time I start reading the Mathematics Tripos at the University of Cambridge, probably the hardest undergraduate maths degree in the world. So maybe I won’t have time for programming. But then again, I’d like to get into it. There should be lots of people (many of them actually reading computer science, not chickening out like me) who can program, and I might find some guys to do a project with. Or I might start one of my own.
Either way, with that in mind – and the fact that I have a few weeks to spare doing nothing – I’ve started reading up on programming. I’ve found textbooks on assembly and algorithms and TCP/IP, and much more importantly, a few on best practices in C++ and in general. This is something I never really learnt, with only limited team experience. We’ll see how that goes.

Shadow Mapping

Man I’m slow at shadowing. I’ve been reading techniques for soft shadows since at least 2008, yet here I am only just implementing shadow mapping. That’s probably Carmack’s fault for making me believe in stencil shadows.
No fancy features yet, just plain shadow mapping:
shadowmap

Deferred Shading and Ambient occlusion

Over the past four or so days, I have been rewriting the renderer of pdEngine to be deferred rather than forward. It is much easier than I thought to do this, even in Direct3D 9 (I will translate it to Direct3D 10 when I am satisfied).
With a deferred renderer, there are so many interesting things one can implement. One is ambient occlusion, and I had an idea for an improvement of this to use it for global illumination. Talking to people and searching I found someone already proposed a similar technique, described here. I have been following this to implement my Screen Space Directional Occlusion (SSDO). The attached image shows just the AO on the right, and the final image on the left. The framerates are bad on my old card, but don’t judge it by that.
SSDO

An update!

I haven’t posted anything here for ages, so I thought I’d better give a glimpse at what I’ve been doing. I’m now working pretty much full time on pdEngine, but rather than making any major changes I’ve been tidying lots. I have made a nice mesh viewer for the .pdmesh and .pdmat formats in C# and WPF. pdEngine now also supports .NET languages because of this, but not fully yet.

I have a new website for game developers’ news, here.
meshviewer

C++/CLI

Since I finished (except for materials) .pdmesh file loading in pdEngine, I have been working on a mesh viewer application. Now, this is not a game and requires a proper GUI, and everyone knows that C# is the only satisfactory way to do this. I don’t want to be meddling in MFC, I want nice windows, made by WPF.
This means that I need to create a wrapper for pdEngine in C++/CLI, so that I can get it working through C#. I’d never used C++/CLI at all before last week, so it was an interesting learning experience. I was previously biased against it as a horrible language hacked together, between native and managed, which in some ways it is, and yet it works and doesn’t have many annoyances.

That is the language however. I am using Visual Studio 2010 (release candidate, but I will get the final through DreamSpark in due course), and for all its bells and whistles, can’t handle C++/CLI for shit. There is absolutely no C++/CLI intellisense. It sounds stupid, but intellisense makes it so much easier to program, especially when writing a wrapper. I don’t have to remember all the variable names I have given, when copying lots from one location to another, it prompts me.
This is why, when I found out there was no intellisense in VS2010 (and there was in VS2008) I got very annoyed. I ended up downloading an addon, called Visual Assist X, which essentially does intellisense better, through an extension. It includes C++/CLI. Now, I think if one small company can get out C++/CLI within months of a beta of the IDE, a multinational corporation shouldn’t have to drop it because of “time constraints”.

Templates in .cpp files

I blogged a few days ago about the need to define templated members within header files, and why I found that annoying. Well, when looking through the propositions for C++0x, the next specification of C++ that could be released as a draft this year, I was pleased to see the heading “Extern Template”. The syntax would be thus:
extern template class std::vector<myclass>;
See the full infromation, and the rest of teh changes in this spec here.

You learn something new every day

I frequently see function prototypes written as
void function(type& param);
but until today have never found out what the relevance of the & was. I assumed it was the opposite of a *, a dereference, but didn’t understand how that worked. I always treated functions like this as if they were written
void function(type param);
and no harm came of it.
But, looking at a physX function early that was
void NxBoxShape::saveToDesc(NxBoxShapeDesc& desc)

I wondered how it could return from this. I had the additional problem that I had a pointer I wanted it to save the desc to, of type BYTE*. I tried various casts that didn’t work, and after a while on Bing I found out that this type of parameter takes a normal variable as an argument, but within the function treats it as a reference, so the value can be changed and it will affect the argument.
It is odd that I never knew this before, either I missed it in the various tutorials and books I read, or no-one thinks it worthwhile to mention. Well, now I know.
In the end, I solved my little problem by just passing a new NxBoxShapeDesc then using CopyMemory to save it to the pointer.

Templated class

For some reason unbenknownst (that’s an awesome word) to me, templated classes must not only be declared, but defined, in header files rather than C++ files. I assume this is becasue templating is done at compile time, and the compiler does not have access to other C++ files, that is done with the linker.
The upshot of this is that whenever modifying the functions in this, a compile of every other C++ file that sues this header has to be done. This slows down development time significantly. I can take long compiles, but it’s annoying when I’m only making small changes in one file.