Some notes on capturing video/audio with GLC

Some notes on video/audio capturing with GLC:

• it's much faster then recordmydesktop, but limited to OpenGL apps, can't capture random desktop regions
• fast enough for 1280x720 capture on my old computer
  
• front buffer capture doesn't work for me, as it includes window borders and distorts the picture, backbuffer capture with "-b back" works
• audio capture is a bit problematic, installing libsdl1.2debian-alsa, forcing SDL to use alsa with "-j" and killing pulseaudio however seems to have fixed that
• "-s" captures instantly, otherwise press Shift-F8 to start capture
• "-i" shows an indicator in the top/left corner when recording, if not given, there is no sign if it's recording or not
• use "glc-play -i 1 pingus3.glc" to inspect what streams are in a recorded file
• there are some more options to tweak the compression in glc-capture that I haven't tried
• gamma in the videos recorded by glc looks wrong, the resulting video is to dark
  

Complete capture line for Pingus looks like this:

glc-capture -l /dev/stdout -v 3 -i -j -o /tmp/pingus3.glc -b back build/pingus -r opengl -d data/ -g 1280x720

For converting the capture into a regular format one can follow the instructions from the GLC Wiki.

Final video looks like this:

OpenGL 2D Soft Shadows

A quick little test of soft shadows in OpenGL. It's all just simple textures, no shaders.



The video captured with GLC:

glc-capture -f 25 -b back -o /tmp/video.glc -s ../../build/2dshadow

Pingus: Even more svn2git

After Galapix and Windstille, Pingus is now the third project I converted from SVN to Git in short order. Pingus took noticeably longer to convert, even so the repository isn't much larger, but it contains more branches, tags and a bit more history. svn2git seems to have performed well again. There was a bit more cleanup I had to do this time around, as some of the resulting tags, going back to CVS days. Essentially there where two kinds of tags again:

foobar
foobar@234

In this case the 'foobar' tags would point to an empty commit created by cvs2svn that would branch of from the main tree, while the foobar@234 would point to the actual position in the main tree. A bit of "git tag -d foobar", "git tag foobar foobar@234" and "git tag -d foobar@234" fixed that easy enough.

Another problem that popped up during the conversion where old tags and branches that I want to keep for historic purpose, but that don't play any role in active development. In SVN one could simply delete those and it would be fine, as they would stay in the SVN history. With Git that is not possible, branches and tags are unversioned in Git and when one deletes them they are gone for good, including the source code to which they pointed. To work around that I converted the branches to tags:

git tag archive/branches/foobar foobar
git branch -d foobar

This way the code to which the branches pointed are still around and can be converted back to a branch via a simple checkout. The old stuff still shows up in "git tag", but as one uses that command a lot less then "git branch", it's not really a problem. The process for the obsolete tags was the same, I moved them to archive/tags/.

I also did a bit of normalization with the release tags, which game in numerous different forms, such as release_0_1_0 or pingus-0.7.2. I renamed them to the semantic versioning scheme, i.e. "v0.7.0".

Final repository is available at:

• http://code.google.com/p/pingus/

The few subprojects floating around in the old SVN trunk/ will be converted in the coming days, some of them probably ending up on GitHub instead of in the Pingus repository, as they are not all that Pingus specific.

Windstille: Another round of svn2git

Did another round of converting an SVN repository to Git yesterday, this time Windstille. Instead of going the manual route I used svn2git this time, which automates the renaming of remote branches/tags to local ones. I haven't verified in depth if everything worked out right, but it seems to have performed well enough. Even svn2git however leaves some traces of SVN behind that have to be cleaned up, namely a few svn remote repositories and a few entries in .git/config, but that is easy enough to fix. The final result can be found at:

• http://code.google.com/p/windstille/

Why Google Code and not GitHub or something else? First of course the obvious, Google Code now supports Git, which it didn't some month ago. More importantly however Google Code has a 4GB space limit, while GitHub has a tiny 0.3GB space limit. Google Code also now finally has support for multiple Git repositories in a single project, so it's easy to break of all the subdirectories one might have had in SVN, without it getting to messy and without a need to stuck it all into a single Git repository.

Converting from SVN to Git

I just converted Galapix from SVN to Git, so here a quick overview about the process.

First thing one wants to do is make a copy of the repository, as the conversion can take quite a bit of time and made require a few restarts to get every detail right. A copy of the repository can be done with svnsync:

svnadmin create /tmp/your_svn_repository
svnsync init file:///tmp/your_svn_repository http://www.googlecode/your_projects_svn_dir
svnsync sync file:///tmp/your_svn_repository

This creates a local repository and copies all the content from the remote, here googlecode, repository in it. One done with that one can start creating the git repository from it, for that there exist "git svn", which not only allows conversions of repository, but also checkins from the Git repository back into the SVN repository if desired, however we are not going to allow this. This is meant as a one way conversion from SVN to Git without a way back.

So next step is:

git svn clone file:///tmp/your_svn_repository/ your_project.git \
--trunk trunk/galapix/ \
--tags tags/ \
--branches branches/ \
-A /tmp/authors.txt \
--no-metadata

The --trunk, --tags and --branches do the obvious thing, they tell "git svn" where to look for your branches and tags, as they don't have a fixed locations in SVN. The authors.txt file is a simple text file mapping the SVN account to Git style names, it has the form of:

grumbel = Ingo Ruhnke <grumbel@gmail.com>

Where the left half is the SVN accountname and the right half the Git name.

Tho --no-metadata flag strips out meta data that "git svn" would normally insert into the commit messages to allow tracking the Git commits back to their SVN origin. This might have some use if you have references in documentation or bug reports to older revisions, but seems otherwise not be needed, so we strip it here.

The next step is a bit weird. With that "git svn clone" you now have a full functioning Git repository of your SVN content, but something is still wrong. All your SVN tags get converted to remote branches by "git svn", not tags and all the SVN branches are also remote branches, not local ones. I am not quite sure why that happens, part of the reason seems to be because SVN tags don't have to be constant, while Git tags have to be, but not really sure way then they are remote and not local ones.

Anyway, the conversion from remote branches to proper tags and local branches isn't that difficult, just a little ugly. To see everything "git svn" has produced use:

git branch -a -v

The interesting part are the remote branches, listable via:

git branch -r -v

Another way to inspect the repository situation is via:

git show-ref

Converting the branches to tags is a simple matter of doing something like this:

git tag galapix-0.1.0 tags/galapix-0.1.0

Converting the branches can be done with:

git branch local_branch_name remote_branch_name

Some branches and tags might be exist multiple times, once as tags/galapix-0.1.0 and once as something like tags/galapix-0.1.0@723. I assume that is the result of SVN "accidents", i.e. deleting a tag or branch and then recreating it or otherwise breaking clean continuity of the repository. The @{number} branches and tags seem to be the older one, so in case you know what you are doing, you can probably just delete them. There might also be a branch called trunk/, you can just delete that as it should be identical with the master branch you have.

Deleting the old now converted branches is a simple matter of:

git branch -d -r tags/galapix-0.1.0

The final step is cleaning up some remains of "git svn", in .git/config there is a section called [svn-remote] and [svn] that can be deleted and there is a subdirectory .git/svn/ which is no longer needed either.

If that last section sounded a bit messy, it's because it is. I couldn't really find any definitive documentation on how to do any of that the proper way, it all boilded down to some manual for-loop and grep'ing to manually translate the branches to local ones and tags.

Another issue which I haven't really looked deeper into is how the whole process reacts to less clean SVN repositories, i.e. repositories where the content of trunk/ might have been moved around to say trunk/{subproject} or where other accidents might have happened with the branches/ and tags/ directory.

I am also still a little clueless on why "git svn" creates everything as remote branches, not as regular local branches, its highly likely an artifact of "git svn" allowing commits back into the svn repository, but no idea why there isn't an easy way to disable that.

xboxdrv 0.8.2 released

• added click-press, click-release, click-both button filter
• added delay button filter
• added simple Python script for response curve generation
• added PDF Afterglow AX.1 Xbox360 controller support
• fixed swapped keys in KeyAxisEventHandler

Download: http://pingus.seul.org/~grumbel/xboxdrv/

Review: Descent 3: Mercenary (PC)

Descent 3: Mercenary is a seven level expansion pack to Descent 3, it was released in 1999 six month after the original game. The games story takes place inbetween the end of Descent II and the first few missions of Descent 3. The player controls this time around not the Material Defender, like in other Descent parts, but a mercenary that is involved in attack and sabotage missions, some of those attacks triggering events happening in the original Descent 3 plot.

The core gameplay of Mercenary is identical to that of Descent 3, new weapons or game objects are not provided as far as I can tell, aside from a few new enemy types. Descent 3 problems are also untouched. The guide bot still moves rather erratically in large environments, which makes it extremely hard to follow, it can also still get lost from time to time and not find the way back, both problems didn't exist in Descent II. Weapon and enemy fire still lack a proper feel for impact, making it hard to judge if you hit something or got hit. Enemy design is also still rather problematic, with enemies shooting to many to fast moving projectiles that make it impossible to properly dodge them other then by wild circle strafing. The game also again contains plenty of unbalanced gameplay situations, where you run into spots one is attacked from multiple sides by multiple enemies, making it hard or impossible to find a save spot. Enemies also reduce your health rather quickly, sometimes in two hits, which often leads to random death before you even know what was going on.

The reset point system from Descent 3 is present again. It will respawn you with your weapons gone and placed on your death spot for recollection without reseting the game world, thus enemies will stay exactly where they where when you died. This keeps frustration rather low, even in unfair situations. The game does however have a few weird spots where you have to do something under a timelimit and failing to do so will result in a failure of the mission, with the player being reset to the start of the level. Thus saving before pressing a switch that might trigger a time limit is needed to avoid running into situations that force a replay of a level.

As with the original game, Descent 3: Mercenary is again rather heavy on the puzzles. A lot of times you will have to press a switch or perform other puzzly acts and not be much involved in combat. Combat takes more of a side role, it's there, but it often feels more like a small obstacle between the current puzzle and the next, not the core focus of the game. The reset system, which often lead to a simple death/retry loop further enhances that feeling, as being actually good in combat provides little if any benefit. The game also introduces a few weird "soccer puzzles", in which you have to push a ball around and navigate it to a specific target, those feel kind of even more out of place then the regular switches. One of those puzzles also felt rather broken, or well, maybe I just couldn't figure out the proper solution. All it involved was kicking a ball through a pipe, except that none of the weapons seemed to have any effect and the only way to push it was with the ship itself. Touching the ball however lead to instant death, no matter how slow and gentle. I solved the puzzle simply by crash, respawn, crash, etc. On the positive side of things I however found none of the puzzles to be as complicated and time consuming as some of the bad ones in the original Desecent 3.

Overall Descent 3: Mercenary is simply more Descent 3, with all the problems and issues still intact. The thing I like about Descent is the fast navigation through narrow tunnels and the way you can manoveur around enemy projectiles with the 6DOF control scheme. In Descent 3 and this add-on, however all the locations are large, making the navigation feel slow and boring and the number and speed of enemy projectiles makes them near impossible to dodge individually and you quickly resort to random circle strafing and random death. The focus on puzzles also just feels out of place. The last boss fight, in the tradition of the series, also feels incredible unfair again and the ending is, unlike the fully animated intro, just a disappointing still frame with a lazy "The End" text, the add-on doesn't even bother to scroll any credits. So while this isn't a bad game, it again fails to reach the real potential that I see in the Descent series.