Category Archives: Screenshots

Screenshots of a computer or game or something.

Animated Plasma Wallpaper: Asciiquarium

Years ago, for KDE 3, I had ported a console “asciiquarium” to operate as a KDE screensaver, called “KDE asciiquarium“.  By KDE 4.2, it was included as part of the kdeartwork module by default.

Since the KDE 3 times when I started this screensaver, our desktop concept has changed around a bit.  We’ve developed the Plasma desktop, and have effectively deprecated the idea of screensavers (which are increasingly less popular), though lock screens are still important.

But not everything that changes is a negative: Plasma also supports “live” (or animated) wallpapers, including for lock screens.  After some pleas from users hoping for a Plasma 5 port of the screensaver, I started work about a year ago to see if I could port the screensaver to Plasma 5 as an animated wallpaper.

Screenshot of the running live wallpaper (set as the Plasma background)

I think I’ve succeeded in at least getting something to start with.  In fact I’ve been running this code for months, never quite finding time to work on it, and I figured maybe someone would be interested if I shared it out.

The code is available at my scratch KDE repository.  A packaged tarball of the initial release can be downloaded from here.

This version uses QML, which was quite a bit harder than I thought it would be, due to the desire to keep this “low res”.  For instance, instead of smoothly animating the fish with pixel precision, the code forces each fish to align to a text boundary (to simulate the effect of running the original TTY-based script).

To the Qt devs’ credit, I found that this was almost entirely doable in QML alone, thanks to its support for OpenGL shaders in its particle system.  In fact if you look at the QML code for the sharks you can see that I managed to get the shark sprite to be de-rezzed using vertex shaders alone.

This didn’t work for the individual fish; unfortunately I hadn’t found a way to both use vertex shaders for the fish and allow a per-particle sprite for the fish.  I’m sure this is just my inexperience with things; for now I create the fish in QML (in Component.onCompleted) but use a small C++ QML extension plugin to update their positions.  The C++ plugin is also used to create the pixmaps.  If it weren’t for these, the whole thing could notionally be in pure QML.

Unfortunately this isn’t anywhere near the greatness of the old version.  The shark sometimes dies early, and can’t kill the fish.  The air bubbles are missing (not that fish really produce bubbles anyways!), and we’re missing the other major ‘fun’ sprites like the sailing ship or, my favorite, the submarine.

But those nits aren’t getting fixed any faster hanging out on my hard disk, so I offer it up for wider consideration.

Victory is mine

So I bought the game Galactic Civilizations II a long time ago. I was able to play it on my wife’s laptop and I figured it had to be pretty easy to get at least the major parts of the game running in Wine since it doesn’t have the copy protection code which normally breaks games nowadays, and it didn’t look like it was using any fancy DirectX features.

Needless to say my first attempts to make it work in Wine didn’t go so well. I tried off and on over that month and eventually just gave up, playing it on the laptop when I had time. I basically never play it now, as moving over to the laptop is just too much of a hassle.

Last night I decided to try again. It took some 6 hours and probably the most debugging I’ve had to employ over this entire year on a problem, but Victory is Mine! :)

Link to screenshot of GalCiv2 running in Wine

The first problem I had is that after patching the game to the latest version, 1.4x, it required activation (what Stardock uses for copy protection instead of CD copying controls) in order to start. This is normally pretty easy, and you can activate by email even if necessary. But the process always crashed. I first tried copying over the authentication certificate from the laptop but it’s tied to the machine you’re on.

So I then tried bringing down the network interface, running the activation again and trying to get the activation request so I could email it to Stardock. That didn’t work either, as it crashed just before I got to that part.

Getting fed up I decided to use one of the Wine debugging megaweapons, relay tracing. This option causes Wine to mark the entry and exit from practically every single procedure call in Wine, including function name, module, and parameters and return codes. You can filter this all down to just the module you need but I didn’t know where the problem was. 70 megabytes of a relay log later, I had something which I could look at.

It took a bit of deductiveness (i.e. searching for the last place where the serial number is used, which is probably close to the crash location) but it turned out the error was in advapi32, in the cryptographic code. Looking at the Wine source code, it looked like the code was trying and failing to read a required Registry key. But how did Wine install itself without setting up required Registry contents?

I tried running wineprefixcreate (which among other things, sets up default Registry contents) but that didn’t help. Eventually a bit of Google searching for the registry key name (Cryptography\Defaults or something like that) resulted in a hit on the rsaenh.dll in the Wine source, in the DllRegisterServer() function. That looked like it created the required keys. Hmm.

From my past life developing Win32 applications I knew that OLE registration for a DLL was typically handled by running rundll32 and passing the DLL name and entry point (DllRegisterServer in this case). wine has that tool as well so I tried running it and… success at last!

Now GalCiv2 wouldn’t run because it said I didn’t have DirectX 9.0c. I tried following some instructions I found to install DirectX 9.0c DLLs into Wine. It turned out I had to use the rundll32 program again on the wintrust DLL to get the installer to do anything. It would still error out though.

At this time I figured there were probably many DLLs that needed to be registered. So I took the rash action of going to my /usr/lib32/wine directory and registering every single DLL in there.

GalCiv2 still didn’t start up, but that’s because I forgot to undo some of the steps I took in the previously mentioned DirectX 9.0c install guide (namely, using native instead of builtin versions of some DLLs). Once I undid that GalCiv2 started up just fine. I haven’t actually played it yet. It was so late by that point that I immediately went to bed. Now I need to see if the game can actually be played in Wine.

I also wonder what part of Wine is supposed to register DLLs (i.e. installer, on first run, or what?) and figure out why it never happened here.

ELF Library dependency viewer

Update 2009-10-10: Updated link to software

So after having a Gentoo upgrade break a lot of programs, even after running the revdep-rebuild which rebuilds packages affected by a changed library, I decided that I had to have a way to find out what libraries in particular were causing programs to need to load the affected library. In my case an expat upgrade replaced with Even though revdep-rebuild was supposed to rebuild the affected packages it missed quite a few.

(I would eventually figure out that the reason it messed up is because the lib64 directory is symlinked to lib since I have a 64-bit system. The program would end up linked against a library in /usr/lib64, revdep-rebuild would look for programs linked against the exact same library, but in /usr/lib instead, and then not find it.)

Anyways, after playing around with ldd and discovering that it would not give a nice tree diagram showing what the dependencies of a program was I decided to make a tool that would do so. I call it ELF Library Viewer (elflibviewer on the command line):

Screenshot of the ELF library viewer in action

If it interests you at all it is available from my software page. It requires Qt 4 and the readelf utility to be installed. It doesn’t really do much error handling (i.e. run it on ELF executables and libraries and you’ll be fine) but it shouldn’t ruin your binaries either.

It is rather Linux-specific at this point as well, but it should mirror the GNU binutils way of finding libraries closely. Instead of searching the cache it checks to figure out what should be caching however. Let me know if this program proves useful for you (or if I’m just reinventing the wheel). Bonus tip: Type the name of the offending library into the search line and hit enter. It will highlight in red all of the libraries which depend on the offending library. It also recursively resolves dependencies, but only the first time it sees a library. It probably wouldn’t be too hard to copy over the dependency tree each time it reencounters a library but I can’t be bothered to implement it.

Aworkin’ away

I think I’ve finally implemented all of the features that mornfall and
berkus have suggested, with the exception of separate compilation and linking,
since that seems to be impossible.

So, I update the entry on
, and when the content page comes back up, what do I see? This is a
of what I saw. If I were a superstitious man I’d be nervous
right now.

Hopefully nothing bad turns out with this release, Perl has given me enough
problems that I’ve been seriously pondering how to introduce a testing
framework into the script. That would be nice, since I already use a
packaging script for the program, I could just force the script to run all the
tests before doing any of the packaging.