Dante with Android

With much thanks to Krzysztof 'kkszysiu' Klinikowski we now have mostly working support for Android devices in Dante. That is to say, the code is there, the build scripts are there, but it's still not an easy process for the user to build their own Dante.apk package for their phone/tablet.

I am considering writing a detailed how-to guide on setting up the Android SDK and NDK, creating the standalone toolchain, and running the build. It's not really difficult, it's just tedious to execute all of the commands required for the Android build.

I have shell scripts which do most (but not all) of the work checked into Git, however you still need to know how to use them, how to modify them to point to your NDK and standalone toolchain, and finally how to transfer the Doom 3 media assets onto your device. Right now the process is definitely not very easy nor streamlined.

We are not yet at a point where this is user friendly! You're welcome to visit us in the #dante IRC channel on irc.freenode.net if you really want to build your own packages, get involved in the development, or just see what's happening in real-time. Okay, this is a free-time project, so you may have to idle a bit and the channel is not always active.

• Performance is currently bad. I am aware of this and it's something we're working on improving in various ways. It's unlikely to happen overnight.
• Touchscreen input is also bad but I expect this will improve fairly quickly. Adding good on-screen controls to be able to move and look around I see as a much more difficult problem. Perhaps one that will be solved with a wearable device (such as a phone or mini-tablet) a Bluetooth wireless controller, and the Oculus Rift. I'll have to wait for my unassembled prototype in November to find out...
• Audio support currently does not exist, though progress is being made in this area.

You can see the bugs and planned enhancements/features on Dante's Github Issue Tracker.

Happy Hacking!

Don't Panic! Doom 3 Repository Rename

I have decided to rename my Doom 3 repository (aka "idTech4 ES2.0", aka "Oliver's Doom", aka "omcfadde's Doom", ...) to an easier to remember name.

Going forward, the repository will be named "Dante" (based on Dante's Inferno and it's fitting description of the Doom 3 game.) Dante journeyed through Hell, guided by the Roman poet Virgil.

Hopefully this will make it much easier to uniquely and easily identify my repository. Unfortunately for those of you who already have clones of the idtech4 repository from Github, you will need to adjust the remote origin to point to the new address. I apologize for any inconvenience.

Don't worry, the project is continuing as usual; the only change is the repository name. :-)

New home for Revenge (Radeon Reverse Engineering Tool)

Thanks to Marek Olšák for having a backup copy of my Git repository online! The hard drive containing much of my personal code which was on people.freedesktop.org (until those directories were lost) is half way around the world.

Revenge now has a new home on http://gitorious.org/omcfadde/revenge.

I have bumped the version to 2.0.0, which introduces some minor configure.ac fixes: mostly PKG_CHECK_MODULES for libpci, sdl, and zlib. I have also updated email addresses and revenge.sh for non-developers.

Honestly I do not expect this code to get much interest now that we have documentation from AMD; but it's useful for historical/nostalgic reasons.

If I were to do it over again today: I would start with the kernel MMIO tracer (which would deal with the fglrx kernel module) then extend this to handle dumping MMIO access from a userspace process too. The kernel is the perfect place to do so, and would be far more reliable than userspace.

If you have any questions or bug reports, feel free to ask them here and I will try to provide you with timely answers/fixes.

Why everyone should be using Git...

I'm sure this has all been said before, but people don't seem to get the message: Subversion sucks for external contributors. Occasionally I send some patches for projects using Subversion...

Subversion has no way to commit local patches so that you can test out your changes, split up commits functionally, generate patches easily so you can send them to a review list, or any of these great features. Git does not have this problem; in fact it has a very nice set of tools for working this way. I won't go into the details of that, as most readers probably know it already, other than saying that it's amazingly simple and easy.

The pain comes when you're an outside contributor for a Subversion project: you might be testing some experimental changes that you don't want to commit to the public repository. Okay, you can edit the files and svn diff locally but this pathetic compared to the power of git commit and git format-patch

1. You're stuck doing one functional change, and only one functional change. Because you have no way to create a patch series. It's either everything in one commit, or nothing at all.
   
2. Even when you have commit access, often this results in multiple functional changes being squashed into a single commit. This is very bad.
3. Subversion provides no way to add commit messages or authorship to the diff generated by svn diff, so contributors are left out in the cold.
• Yes, if you have commit access you can provide this meta-data, but you're still pushing directly to the repository with no review what-so-ever.
  

I could continue, but I think my point is made: Subversion sucks for distributed development (in the across the globe sense) and it also sucks for development in the "few developers distributed across the room" sense. It all adds up to pain and inefficiency: especially for external contributors, but even for people working with the project with commit access.

Thankfully Sourceforge does at least provide rsync access to the Subversion and CVS repositories so git svn clone can be both fast and bandwidth efficient. Unfortunately, however, it seems that Subversion chokes on anything but patches generated by Subversion itself (including standard GNU diff format.)

Everyone should be using Git (or at least some distributed version control system with similar features.)