dabroz.scythe.pl

I've finished iPhone "port" of my blog. It was mostly CSS/XHTML task, with few issues. First - clamping images to 300 px width. To do so I visit each XML node, looking for <img>s and change width/height if they are provided. If not -- I download specified file (only if its in my domain: security is important, on the other hand -- why should I hack my own blog?) and calculate width/height ratio and append attributes. Of course I have many XML errors in my posts as I write them by hand, so I've corrected some of them. Navigation buttons (older/newer posts) are done with major hacks like most of the rest of blog server code. Yes, my blog system is probably the biggest application I've written using teleports instead of doors (and other OOP stuff). I know its ugly -- but fun. :)

If you use OpenGL you must check out this free debugger: glslDevil.

Quoting autors, glslDevil is a tool for debugging the OpenGL shader pipeline, supporting GLSL vertex and fragment programs plus the recent geometry shader extension. By transparently instrumenting the host application it allows for debugging GLSL shaders in arbitrary OpenGL programs without the need to recompile or even having the source code of the host program available. The debug data is directly retrieved from the hardware pipeline and can be used for visual debugging and program analysis.

I'm going to test it in near future, hoping it could handle OGL 3.x code (gDEBugger fails to do so and doesn't support Win7).

Few days ago there was a really cool Raytracing Compo. Rules were simple: 3 spheres only and you need to use raytracing. To be honest, the rules were my idea -- or to be more precise, my IRC joke. Joke that got real.

I've already had some experiences with raytracing and other cool effects, so I was wondering what kind of game could I make. Sure, every possible material and effect was available -- but this time my main concern was gameplay. I decided that eye-catching materials wouldn't add anything to gameplay and didn't use them (well, Krzysiek K. proved me horribly wrong, however he used multi-layered sphere -- very, very sneaky! -- check out his game, its awesome). In the end the game was made in great hurry, so it's not as fun as I wanted it to be (in fact I use PhysX just to roll ball...), however requires few minutes of "what is it all about" to win.

Few technical issues: it's GL 3.1, and almost runs on ATI Radeon. After lot of bugfixes executable starts but visuals are incorrect. I would be more than happy if a brave-enough Radeon-owner would spend some time and fix the code. With such knowledge I would probably also be able to fix deferred shading code. Other valuable points in code are "procedural" mip-mapping (because of bad aliasing with no AA or AA with uniform grid) and per-object texturing. In fact, please, do not post "The Orb Game Sources Reaction" on YouTube.

• binaries
• binaries (more compatible version)
• source code

Do you consider yourself a good programmer? I believe that there are 3 "skill levels" -- not only when we talk about programming:

• level 1 programmer doesn't know any tricks nor fancy optimalizations. If he's about to write a loop, he'd probably write i++ as incrementation. If he needs an absolute value, he uses abs function (found after 2 hours spent with Google).
• level 2 programmer finds himself more powerful. He knows that postincrementation requires copying variable, and he knows that branching is serious pain -- so instead of v>0?v:-v, he would say

  __forceinline float abs(float v)
  {
    union { float a; unsigned int b; } f;
    f.a = v; f.b &= 0x7FFFFFFFU;
    return f.a;
  }

  And yes, FFFFFFFU is very well related to the idea. :)
• and at last, level 3 programmer knows that i++ and ++i will result in the same code (if i is integer and we don't use result). He knows that compiler is way more comfortable with playing with low-level stuff (such as bitwise operations), so instead of trying to help compiler generate good code, he uses his skill not to disturb his compiler.

So, maybe document about compilers would be a good start if you are really interested in reasonable and pointless optimizations. Good knowledge about inlining and profiling is valuable. In fact, if you want to be a "maximum performance" programmer, you'll need to enjoy reading (and NOT writing) assembly code.

And remember: If you do an optimization, test it on real world data. If it’s not drastically faster but makes the code less readable: undo it. (final quote from referenced article)

Multithreading

And now for something completely different: multithreading. If you are a computer science student, you've probably had your Parallel programming course. Have you learned about small producers and big consumers (and vice versa)? Have you noticed that most important part of every piece of code you've written on such course (well, if you've written any code at all) is wait and release?

If you are a driver (not a graphics card driver), you're aware that your car can start skidding in bad weather conditions. But what is more important? An ability to control your skid? Or an ability to avoid it? Same goes for parallel programming. While multithreading is fun, using a lot of synchronization is not. If each method in your code starts with GlobalMutex->Acquire() and ends with GlobalMutex->Release(), would you call it multithreading?

Possible solution is lock-free programming. Andrei Alexandrescu (C++ expert) has written an article about lock-free data structures. Basic construction used is compare-and-swap -- an instruction that modern CPU can perform atomically (it can't be interrupted during its execution, unlike i++). It look like this:

template <class T>
bool CAS(T* addr, T exp, T val)
{
  if (*addr == exp)
  {
    *addr = val;
    return true;
  }
  return false;
}

Using such instruction, we can, for example, implement a Dictionary class that can be used in multithreading environment and doesn't require locking if we only want to get a value from a dictionary. Lock is needed only if user wants to update dictionary. However, this is not as simple as you want it to be. In the end, author ends up with Write-Rarely-Read-Many-But-Not-Too-Many Dictionary. Read the article if you are interested in details.