SVN 1.5, TortoiseSVN 1.5 released

Recently, Subversion 1.5 has been released, and alongside with it the excellent Windows client TortoiseSVN. SVN 1.5 adds basic support for merge tracking, which is a very nice feature which is especially important if development is mostly done on branches.

TortoiseSVN 1.5 brings full support for all of SVN 1.5 (including merge tracking visualisation) and fixes many Vista related bugs. One small problem remains, if you had previously "Enable accelerators on top-level menus" enabled to get properly drawn context menus, you'll notice that no icons are drawn in Vista now. Easy fix: Delete the registry key HKCU\Software\TortoiseSVN\OwnerdrawnMenus -- works like a charm afterwards.

Windows binaries for SVN 1.5 itself should appear during the next week.

[Update] Updated registry key, thanks to Markus for pointing this out.

DX SDK - June 2008 is out

I know, I'm a bit late, but I'm kinda very busy at university at the moment. Well, Microsoft released the latest DX SDK, which contains -- among other things -- lots of stability updates for PIX. PIX is an excellent debug tool which is one of the major reasons I tend to use DX nowadays instead of OpenGL. Unfortunately, there is a known issue with PIX and shader debugging on Vista x64. I have to try it yet whether I'm also affected; I'll update this post as soon as I get some time to test it.

I found a reason

Well, funny post title, but it fits in two respects: Finally I found a reason to post again, and the reason is the song "I found a reason" from Cat Power. It was quite a long time since I recommended a song, but this one surely deserves it. A very simple song, with just the piano in the background, and yet so powerful. I'm listening to it since more than a year from time to time, and each time, it makes me shiver.

What comes is better than what came before

This song is sad, with Cat Power's voice sounding fragile and a bit lost, yet it gives hope. It's also very short, with simple lyrics, but it's a real gem which you should have heard at least once. It has been also used in "V for Vendetta", if you watch the movie, just at the end when Eve comes back to V to dance before she leaves after he has tortured her, he's playing it from his jukebox (if I remember correctly, quite some time since I watched the movie the last time). Stay tuned for more posts in this section, as I'm busy buying music recently again. Currently, I tune in to "Enjoy the ride" from Morcheeba's new album "Dive Deep", but I'm not sure yet whether to recommend it -- gotta play it for some time first.

[Update] "I found a reason" was played at a different scene.

Virtual texture mapping

There's somehow a lot of confusion going on about virtual texture mapping: I've been recently asked whether it's going to increase the VRAM usage extremely, and this is so way off I think it's time to clarify some things about it ;)


Virtual texture mapping is going to be used by the id Tech 5 engine (from id Software). The technology behind this dates back to SGI, where it was called clipmaps and worked only for terrains. Later, a paper was written about a similar technique: "Unified Texture Management for Arbitrary Meshes". Carmack himself has been describing the basic idea back in 2000 already. Tom Forsyth has also a blog entry about it. Sean Barret presented a technique called "Sparse Virtual Textures" at GDC 2008, with a working virtual texture mapping implementation. For a good overview, take a look at Mittring's "Advanced virtual texture topics".

How it works

The main idea behind virtual texture mapping is the following observation: Given a screen resolution, it makes no sense to have more texture data in memory than needed to have one texel per pixel (at least). For example, if we are running a game at 1680x1050, we cannot display more texture data than 1680x1050 (simply because there are not more pixel available), so if we can create a texture with exactly the parts needed for display, it won't be any larger than our framebuffer. Of course, a perfect fit is not possible, but we can reasonably estimate that if we can figure out which mip-map level of each texture is needed, we can get away with a fixed cache of maybe 2-3 times our framebuffer (let's say 1680x1050x4 byte per pixel x 6 layers x 3 times overdraw = 120 MiB worst-case). This gives us a constant upper limit for the memory usage: We can never go above our texture budget, only below, if the amount of textures visible is smaller than our cache. Sounds easy, eh? The difficult part is:

  • figuring out what part of each texture is visible, and at which mip-map level (efficiently)
  • stream in the textures quick enough

But the idea is pretty easy. Notice how this is similar to virtual memory in a normal PC: There you have pages (texture tiles), which are either in RAM (VRAM) or on disk and paged in on demand. Same with virtual texture mapping, with exactly the same advantage: You can use larger working sets than your available RAM. For graphics, it's even a bit better as the upper limit can be capped by the display resolution. Larger working set in the context of graphics simply means you can use more textures than your VRAM would allow you to (basically, unlimited, as you can stream them from disk).

[Update] Added links to "Sparse virtual textures", "Advanced virtual texture topics".

[Update] Fixed link to "Advanced virtual texture topics".

CMake 2.6 final released

CMake 2.6 has been released. See the release announcement. CMake is a very nice cross-platform build tool which does not build itself but instead creates projects for the target platform (Visual Studio projects files for Windows, Makefiles for Linux, etc.).

Pretty nice and it usually "just works". Recently, KDE has switched over to it, and since then I also gave it a try and I must admit so far, it's the best build tool I tried. Aqsis is also using it and it works pretty well so far; supporting Mac OS, Windows and Linux -- this is where I had my first personal contact with CMake.