How do you think, what kind of game could this be?
Flight simulator? Train driving game? Educational app for young chemists? Or maybe even LHC iPhone interface?
You are wrong. This is...
I've just uploaded 'almost-0.2' version of gitcharts. It has more customization options, is able to track 2-level directories and has switched from own 'library' to GNUPLOT. I was experimenting with ZedGraph (C# charts lib) but I've decided that after 0.3 (with caching) the next version will be 1.0 and it will be written in portable ANSI C instead of C#.
New screenshot (and my 100KLOC project ;)):
I've found quite good sampling profiler for Windows -- and it's cool because it's free (GPL). It's called Very Sleepy. Doesn't need any special setup -- given that PDB files are provided it can attach to running application and sample callstack. There is even possibility to choose thread to sample. I've set up a git repository on github.com so I'll be able to improve it a little bit.
Every single discussion board for developers has a thread called Functional programming vs rest of the world where you could read that Haskell/LISP/Scala/etc is much, MUCH better than C++. But when you ask about AAA games coded entirely in Haskell you get just silence.
Today I've been reading topic about exceptions in C++. One of the arguments against not using exceptions is that when you use return codes for errors you have to pass real results in arguments, like:
int OpenFile(const char *filename, Handle *handle);
Handle h;
if (SUCCESS == OpenFile("file.txt", &h))
{
// ...
}
And that doing so makes code "less clear" because you can't see what is input and what is output of function -- and you should return output ONLY as return value.
But we should go deeper: OOP is out of question (because method call can modify internal object state) and so are pointers (bacause you could modify something far away from local scope). Now we only need to get rid of variables (as all of our &variables& are constant) and voila! We have Haskell. :)
Let's assert that this style of coding is cool -- so why does nobody code games in Haskell?
Well, I think that functional programming lovers forget that computer program is composed like this:
1. Read input
2. Process input data into output data
3. Write output data
And functional programming is useable only in part 2. Input/output doesn't fit functional programming anyhow. If that parts are simple (like read N numbers from file, process them and save M numbers into another file) we could ignore it. But if it's gamedev, part 1 (reading player/network input) is important, and part 3 is VERY important (like rendering, sound, network communication etc). Part 2 is quite simple or sometimes even trivial -- so why should we need FP for it?
On the other hand, FP is good for example in shaders. GLSL/Cg/HLSL mimic C syntax, but they are overall quite functional. Pure data transformation (input interpolators -> fragment shader -> output colors/data); no external routines; no memory management; massive parallelism. So its just a matter of proper tool for given job.
Everyone is coding software renderer (for occlusions) these days. So do I :)
Few benchmarks (more will be added later):
Core i7 930:
single thread: it takes ~1ms to render ~1000 triangles (see picture above) in 256x128 resolution
OpenMP: ~0.5 ms (I need to investigate why there is only 2x speed-up)
Vertex transformation takes only very small percentage of this and rasterizing occupies most (I use half-space approach)
Note: QueryPerformanceCounter is acting like crazy with OpenMP (even with SetThreadAffinityMask). Is this a known issue?
