Yeah you know I like provocative titles once in a while because you guys are click whores. But somehow, this time it’s true. Pandafe is an awesome piece of software and there were only like 700 downloads in the repo over multiple versions released, which means there’s only something like 100-200 people actively using it (I have no proof of that, just my intuition… and rough BS evaluation). Well if there are people out there playing with emulators (and obviously there are many of you, with 9000 downloads for PCSXReARMed) you SHOULD be using Pandafe, like, right now. Stop being a n00b. Let me explain why.
Pandafe is a launcher for games, focusing especially on emulator games. The basic concept is to unify all emulator games behind a single interface, instead of having to launch one emulator then quit; and then launch another emulator then quit, etc… which can be quite time consuming and bothering in the end. So with Pandafe you simply get all your games organized in categories (usually hardware, like PS1, NES, SNES, etc…)…
and after clicking on one category you get the list of games directly. One click on the game and the game launches without having to launch the emulator first. Great concept, great execution, especially in the latest versions where the functionality of Pandafe has been significantly improved.
When you first launch Pandafe, it takes a while to start up as it begins scanning your SD card for applications, games and roms used by emulators. I have Pandafe’s creator, Nuhrin, describe in more details how Pandafe works:
Pandafe uses data files to define Platform and Program definitions, where Platform corresponds to the emulated system and Program corresponds to the emulator, and uses libpnd’s app discovery to determine which pnds and apps are available.
Each rom-based Platform definition stores the rom folder path (selected by the user on first use) and file extension(s) which indicate where appropriate roms can be found. It also stores a list of appropriate Program definitions which can be used to run those roms.
Each Program definition stores the app id of the pnd app(s) it describes (either exactly or via prefix/regex) and also a custom command script which enables the app to run a rom directly when the app’s default script does not already support this (which is typical).
When a user attempts to run a rom, Pandafe refers to the Platform’s list of applicable Programs and compares this to the list of available apps obtained from libpnd to determine an appropriate app to launch the rom with. The Platform defines a (configurable) default Program to try first, and the user may choose a prefered Program for each game if desired.
Because scanning available apps through libpnd takes a noticable amount of time, and because scanning the filesystem for roms does also, the list of available pnds/apps and rom lists for each platform are saved to a cache file when scanned. As a consequence, when a user add or removes pnds or roms they must manually rescan their pnds and/or roms before Pandafe will know about those changes.
Adding new Platform and Program definitions is done via Pandafe’s menu system. A GtkSourceView based editor for custom Program commands is included, along with a terminal widget with a shell in the mounted app directory to assist with custom command development. Each Platform and Program definition shipped with Pandafe was created in in this way.
And you can indeed modify several of the initial parameters of Pandafe by going in the software options. Changing the location of your game files, changing the extensions, changing the default program used to launch the game file… the possibilities are numerous.
It goes even further than that if you are a customization freak. You can directly modify, from the program itself, the scripts that are run to detect the game files or execute the programs. This is helpful when, let’s say, you want one emulator to launch with certain parameters and not the default ones.
It’s obvious that Pandafe is far from being a “simple / basic” launcher. A lot of thought went into it to make it very powerful and as flexible as possible. And it’s been a long time that it’s in the works!
I starting working on Pandafe before the Pandora was released, out of great enthusiasm for a GNU/Linux based gaming platform. I had also been looking for a project to work on as a means to teach myself a variety of open source technologies, and the chance to use those technologies on a new gaming system was exciting. My anticipation for the Pandora became the motivating factor in my finding the time and energy to not just learn, but apply myself towards the goal of making, hopefully, a worthwhile contribution of free software to a community.
Things proceeded, very, very slowly. I had a brand new family, and only a couple hours every couple nights to work with. I also gave myself lots of technical requirements and constraints, most of which were intentionally hard or idealistic in some way, to maximize depth of learning. I would go sit on a bench near my apartment for a couple hours after the family went to bed, try to keep my laptop out of the rain, and see how far I could get on something before sleep overcame ideas. It was a quite interesting process trying to unravel and refine complex tasks, while fatigued, in small chunks of time, without loosing context from one session to the next. Sometimes it would take two weeks or more to accomplish things I probably could have knocked out in a single day of fresh, focused attention.
Nuhrin was interested to make this software for himself in the first place, but even after time passed by there was still not equivalent software for the Pandora! It still made sense to share it !
Given the development process, it was immensely rewarding when I was able to finally release something. It was an awful lot of two hour days in the making. The fact that after so much time, Pandafe still ended up providing something not previously available was a surprise to me, and entirely a coincidence. I set out to make the program I figured I’d most want myself, always assuming someone else would do it first and better. When I got my Pandora and started playing with it, I was quite surprised no one seemed to be working on “yet another emulator front end.” Time went on, and everyone kept not making the thing I most wanted. So that motivated me to keep going and finish something, if only to have it for myself.
While the motivation was strong, Pandafe’s development was far from being straightforward. As Nuhrin mentioned, he had “stretched goals” and wanted to implement them as much as possible, leading towards more complexity, albeit he only had so little free time to dedicate to the project.
The biggest challenge by far was just making tangible progress in my tiny working sessions, while keeping the codebase from evolving into a mass of goo as I forgot an awful lot from one week to the next. Most of the technologies I was learning as I went, and the big-picture goals, design, and architecture were tough to nail down and keep straight through those tiny windows. It was certainly a lesson in managing complexity and in continuous refactoring. Imagine playing through Super Mario Bros.: The Lost Levels for the very first time. Now, pause the game after 45 seconds, no matter what’s going on. Come back two days later, unpause, go. Repeat until you beat the game. Kind of like that.
Pandafe suffered from the “Duke Nukem Forever” Syndrome as well. At once point Nuhrin had a whole version working with a GTK frontend (the default system library for graphical applications) but he didn’t like it and started on scratch to do a SDL version instead.
The main technical challenge came from my decision to use SDL for (nearly) every aspect of the program. I had a largely complete GTK+ version before I accepted that I found it just unpleasant to use. For actually using the thing I found I really wanted an in-emulator menu feel, so I grudgingly threw out lots of work and started to to learn SDL. That quickly gave me qute a shock. I dunno exactly what I thought SDL was, but I certainly did not expect it to be quite as low-level as it is. It took lots of nights hacking together mazes of bad code before I acknowledged that I needed to write multiple layers of higher-level interfaces and components before I could really even get started. It ended up being extremely interesting and rewarding to stick with my constraint of SDL for (nearly) everything, but if I had known what I was getting myself into at the time, I might not have been so enthusiastic.
So when do you release something that’s still in the works? Good question. That’s why competitions are out there on Pandora, to give a boost to what people are working on and set a final goal to release software in the best state possible. The Rebirth Competition in 2012 was such a trigger for Pandafe:
When I heard about the rebirth competition, I decided to use that as motivation to finish something and get it released. I stepped up my pace, got less sleep, then breathed a huge sigh of relief as I uploaded it. I was proud of my work and excited to hear what people thought of it. Unfortunately, most people just saw it crash on startup and moved on. I had failed to keep up with firmware updates and didn’t realize that Pandafe had a hard dependency on the version of libpnd from an older firmware. I got this fixed fairly quickly, thanks to some thoughtful testing and reports from the community and some precise libpnd technical support from skeezix, but the first impression had been made. It was a discouraging fizzle at the finish line after so many calendar days trying to get there, but the help I received from the community encouraged me to try to take it in stride and keep plugging away at it.
I will draw a short parallel here to my article on “7 Steps to be More Successful” since I think it is very relevant to the example at hand: leaving a bad impression because something is not sufficiently tested before hand. It does not happen only to other people! Please keep it in mind if you are an aspiring developer… Luckily, Nuhrin’s motivation was stronger than this original setback.
Since the learning aspect was always a primary goal, and really the primary motivation for my day to day effort, I ultimately feel the challenges and discouragement were a small price to pay. I gained a fairly deep understanding of Vala, Git, and Autotools through my work on the project, all things I had been eager to learn, and that knowledge is perhaps more valuable to me than the project itself. Though of course I am quite pleased that Pandafe has found enough of an audience for the project to continue on a something more than a compelling learning experience.
Even though Pandafe reached a very satisfactory state, there is still work ahead and more updates are planned.
I have two specific, unfinished features which were part of my original vision that I’d like to complete next. The first is the ability to manage roms and pnds through Pandafe. That means renaming and deleting roms, and moving them to Category/Genre folders. For pnd apps that means changing app name/category via .ovr files, and perhaps deleting pnds. I would also like this to support opening a terminal/thunar window in a given rom’s folder, and in a given app’s appdata and mount folders.
The second unfinished feature is screenshot integration. I want to be able to take screenshots of whatever game I’m playing via a common mechanism and then integrate those screenshots into the Pandafe interface somehow. The common mechanism I envision is an overlay menu that opens when you press the Pandora key, shows a scaled-down image of what was on screen when you pressed it, and allows you to install the screenshot then continue the game or quit/kill it. I have good progress on that in a local development branch, but it needs some ironing. Integrating the screenshots into the interface “somehow” is still an untackled matter though.
Apart from those two features, my intent is to continue to refine and polish the program according to community feedback and with little itches of my own that want scratching. The issues list on the github project page has a few items currently and I intent to implement all of them when I’m able. Everyone is welcome and encouraged to submit requests and reports either there or on the boards, and I will try to integrate everything that I am feasibly able to.
Talking about Github, I was wondering what were Nuhrin’s overall impressions regarding the platform, and why he chose it:
Pandafe is on GitHub because I was using Git and I had no reason not to go with that de facto standard. I’m mostly ambivalent towards it, though I will say that we use it at work for some client projects and I’m not a fan of it in that context. Enough so that I set up a GitLab instance and am moving us that direction. But for Pandafe its been lovely. Mostly that’s because Git is lovely, but that’s certainly not a bad thing.
I do regret that they’ve done away with project downloads. I had been uploading tarballs for releases, which allowed folks to compile Pandafe without needing a Vala compiler. That’s gone now. Oh well. I suppose release tarballs are not really useful anyway, since contributors would still need Vala and most people only want a pnd.
So there you have it. Pandafe’s great, is improving constantly (with the recent addition of DraStic support) and you can report directly issues with the program or contribute to the code via GitHub yourself! What could be better, really?
In case you wonder how Nuhrin learnt to program in the first place…
Like lots of folks, I taught myself to program when the first computer running BASIC as its OS found its way into the family living room. I made games and got into the sort of romantic young man’s view of hacking. I fell in love with the depth of learning available, and the joy of crafting tangible things from the intangible. I feel blessed to have a well-loved pass time which is also very practical as a career. These days I work from my home in New Mexico as a technical architect and developer for a Portland, OR based web agency.
In high school I had the opportunity to participate in some educational programs from the two national labs which are based in New Mexico. One of them connected my school to the Internet and gave us accounts on a super computer, with which we were meant to run computationally expensive programs for science fair entries. We mainly used them to send emails to kids at other schools, play with hacking around an Unix shell, and “finger” each other to find someone to chat with using the wonderful instant messaging precurser “talk.”
That first exposure to the Internet happened at a time when commerce was not yet really allowed, much less encouraged. It was an extraordinary place for a young person to venture, with an astonishing wealth of new information, ideas, and communities. I was struck by how positive it all was in general, and how well the Internet community maintained itself. A sort of functioning anarchy, as we referred to it at the time, and in very stark contrast to the “scary Internet that will eat your kids” which emerged in the media some time later.
The experience of that community had a strong impact on me, leading to a deep appreciation for free (as in freedom) software and an equal distrust for the inverse. When I became aware of the Pandora, I was sold before I followed the link on whatever blog I was reading. Yes! Exactly. This. Instant buy. Click. Er, ok. Not so instant. But I started coding for the idea of the thing anyway.
Pandafe was actually the first publicly released project from Nuhrin, even though he worked on many other things before…
Most of my experiments have been learning projects to pick up new languages or platforms, or to explore interesting software techniques and concepts, or (more often) both. The fruit from these experiments is rarely a finished product but rather a deeper understanding of something to be applied elsewhere. For example, I picked up python by writing a yaml parser with it, as part of broader experiments with object persistence in various languages. The led to tangents like extending language constructs via the language, which python is great at, but also to the yaml-based data persistence used in Pandafe.
Occasionally I work on something tangible that I finish and use, but usually I get sidetracked by technical tangents or just life, and I’ve rarely considered turning those things into a release for others. In a sense, Pandafe became largely an experiment in creating something intended for release, in contributing something to the GPL world I’ve gained so much from, and in learning and practicing what all goes into sharing my work and engaging with a community. I’m very pleased and grateful for the positive feedback I’ve received so far; the experiment has proved much more successful than I’d expected.
Nuhrin is now very busy with his wife and family, and don’t expect him to start working on several projects in parallel and make significant progress. However, if he had more time, he would be interested to work on the following…
I’d like to write some specialized compilers, as I find that subject fascinating. I’d like to enable use of the WiiU gamepad as an input device and second screen for my Linux desktop, to play games, watch movies, and control my pc. That still leaves all the time in the world though doesn’t it? How about easy to install Debian on every IOS and Android device? The next wave of disruptive Internet technologies, for putting some checks on the NSA and their buddies?
I dunno, as nice as all that sounds, I suspect I’d still be the guy playing in the water or the park with my kids.
That’s it for today on PandoraLive. I command you to try Pandafe! At least once. I wasn’t sure I liked it the first time I tried it myself, but after a while I got used to it and I now think it’s very practical and well designed.
Your comments on Pandafe (and other things) are welcome below!
* EKIANJO OFF *