On plGLPipeline and Plasma for Linux…

A new beta driver from nVidia on Thursday night spurred me to revisit the plGLPipeline stuff I’ve been poking at over the past few years. I had an unexpectedly productive few days and got a lot of texturing-related stuff done. I posted the following image on Twitter yesterday to show-off how things were looking:

Relto, rendered on Linux with plGLPipeline

It’s pretty cool, but a single screenshot easily gives a false impression of progress. Some people were asking if I needed anyone to help test it. The reality is that this screenshot is all that plGLClient is capable of right now. The OpenGL work is solely the rendering pipeline and while (very slow) progress is happening there, the rest of the pieces needed for an actual functioning client are still quite far from being usable on Mac or Linux.

plGLClient currently has a hardcoded camera position. If I wanted to take a screenshot of a different part of Relto (or a different Age), I need to edit the code and build a new client. The reason for this is that the camera system depends on a working keyboard/mouse input system, and the current plInputCore system is Windows-only code.

Likewise, the Age name is hardcoded. I’d been testing with the Guild of Writers Pub for quite a while, and after it seemed to be working I decided on a whim to try Relto. Using the real plAgeLoader requires plNetClient and pfPatcher code, and those require the actual networking system code which is a tangled mess of several layers that involve of Windows-specific code.

To be entirely honest, to even get plGLClient to work at all involved commenting out sizable portions of other code. Did you know that texture layers depend on the network system (via plLayerSDLAnimation, which requires plSDL, which requires plNetClient & plNetMessage, which require plNetClientComm, which require …)?

One of the next things on the to-do list for plGLPipeline is getting lighting hooked up. You can see in the screenshot that some objects are rendered black because of the lack of run-time lighting. Unfortunately plGLight also has dependencies on other parts of the system that don’t compile on Linux. For now I’ll probably end up commenting those out for the sake of progress, but I can’t keep avoiding these issues forever.


I’m going to be honest, I don’t know if this project will ever get to a point where the game is playable on Linux natively. It’s taken me over 2 years to get to what you see above, which probably totals less than 80 hours of actual work. There’s so much to do in terms of replacing non-portable code and cleaning up the tangled subsystems, and it’s very overwhelming and makes it hard to work on it. It’s depressing to think that your next step might involve replacing 1/4 of the entire codebase. It feels a bit like punching your way through a rock wall, you make minimal progress at personal cost, but given infinite time you would eventually accomplish it. But we don’t have infinite time, and we don’t have resources.

There is nobody left for whom Plasma is their main focus. There are 3 or 4 of us who make casual contributions, but general interest in Uru has dropped off so there are no new contributors coming along. Between full-time jobs and other commitments and burnout, the reality is that most of us have very limited energy to devote to a project that feels like a black hole sometimes.

Horizontal background extending on fixed width sites

Often when building a fixed width website, there are blocks of content whose backgrounds should extend horizontally beyond the fixed width area. Footers are a good example of this, but there are other cases as well.

There are a few ways to go about achieving this: wrapper divs, a mess of absolute and relatively positioned elements… or there’s a nice little CSS hack using the :before pseudoclass.

#myblock    /* Main content block */
    width: 940px;
    margin: 0 auto;
    background: steelblue;
    height: 200px;

#myblock:before    /* The pseudoclass hack */
    position: absolute;
    width: 100%;
    left: 0;
    background: steelblue;
    height: 200px;

A few things to note:

  • The block must have a fixed height, otherwise the :before extensions won’t match the main content height.
  • The content block must not be position relative, otherwise the absolute positioning of the :before pseudoclass won’t work properly.
  • This works in IE8+, Firefox, Chrome, Safari… IE7 and lower have no support for the CSS :before pseudoclass.
  • This is best suited for solid colours. A tiling image should be okay too. A background image at a specific location in the content block will probably incur z-index problems.
    For most browsers, this can be fixed by setting the :before pseudoclass to have a z-index of -1, but this will not work in IE8. There doesn’t appear to be a solution for this problem.


Firstly, we survived and we are awesome. There are few things better than seeing 5 groups send files back and forth over wireless modems on a protocol we designed and then being told that you are the first group in 20 years to accomplish that.

What was interesting for me (between periods of frantic bug hunting) was watching how people worked, how they tried to solve problems, and how they handled things going wrong. From watching that, I’ve realised some things.
I need to be less… controlling about things. I try to always be open to new ideas and new methods, but I always try to ensure that everything is done the way I would do it. This leads to other people feeling useless, and me reaching the point of burnout from trying to do everything. I will always have a need to know how the project as a whole works and how all the pieces fit together, I’m definitely not one for blackboxing. But I need to trust other people to do things, and trust that they can be help responsible for what they’ve done.
Almost as importantly, someone needs to hold me to similar standards. There should be debate about how to do something, and someone’s idea should not be used simply because it’s easy, or it sounds good. I should need to prove my reasons to people before I’m simply given the freedom to implement it.

Those of you who felt like you couldn’t contribute anything, or (worse) those of you who got stuck writing documentation at the last minute: Don’t let me do that to you again.

Gwibber, or “Planning for Plugins”

I have been consistently pleased with Gwibber as a Twitter client over the past year or so, and I’ve seen some very nice improvements over that time (support for new services like Buzz and Digg, support for displaying thumbnails of Twitpics, etc.). Yesterday I was working on a simple prototype for fetching status updates from a web service, and thought Gwibber would be a good place to integrate it.

While I was (mostly) successful, the experience left me with some questions about plans for extensibility by 3rd party modules for Gwibber. Every service is implemented in its own Python file in a directory, adding the class for a new service was easy. Making Gwibber load it was much more difficult.

Gwibber’s client file explicitly imports all of the service modules. This is a problem: if I want to add my own service, I need to edit core Gwibber files. Not to mention, those files are of course in /usr which means I need superuser permissions to do so, and any Gwibber updates will overwrite those changes. I’m certain that there are “plugin” module loaders out there for Python, and if there aren’t any that are suitable it’s easy to write your own (I’ve done so in the past for a different project).
The second part of that problem is that simply importing the module isn’t enough, I also had to edit a dictionary in the client file to add my service to the list of recognised services.

Success… in some ways. The problem now is actually adding the account. Gwibber’s UI stuff seems to be entirely separate from the core, and each service defines its own UI file. I had to create another py file to tell it which UI to use (I cheated and re-used an existing UI, otherwise I would have had to create that as well).

Gwibber is a good program that works well, I wouldn’t have chosen it as my test area if I didn’t like using it. The actual service modules follow a reasonable structure (although some are inconsistent, and there is no documented API). The problem is that everything is hardcoded into the client.
I’ve seen feature requests for other services in Gwibber, but at the moment it isn’t feasible to write support for those as some sort of plugin.

Maybe I’ve been hanging around Pidgin too long, but I think the concept of every service/protocol being a plugin that is loaded dynamically is a very good one; and something that would make Gwibber feel a lot more open to 3rd party development.

Moodle 2.0 Theme Contest: Silvern

Announced at http://newschoollearning.com/theme/contest/, I decided that this was the perfect excuse to actually finish the theme that I’ve been developing for over a year.

That year has been interesting, since almost every single piece of code related to themes has changes multiple times, requiring a number of theme rewrites to keep it all up-to-date. I seem to repeatedly have this issue with writing lots of code for something that’s in active development, and then rewriting that code to keep up with the API changes. >.>

The theme uses one of the new custom renderer classes to output HTML5, and includes a number of admin-configurable settings such as colours, welcome text, and the site logo.
My entry is called Silvern.

Silvern Moodle Theme

Silvern Moodle Theme

Edit: I almost forgot to mention: All the code for this theme is available on my github account. Enjoy :)

Future of the Web 20100620

  • Starbursts using only CSS3+HTML are a cool idea, and produce a cool effect if used in moderation. Sadly some of the outrageous hover effects on the starbusts near the bottom of the post remind me of terrible GIF rollovers and Flash buttons that plagued the web for years. (Anyoneelse getting GeoCities flashbacks?)
  • This has been around for a bit, but I didn’t find it until I was looking up some CSS animation stuff. Star Wars AT-AT Walker using only CSS animations. There’s also a blog post that explains how it was done.
  • Safari 5 supports border-radius without the -webkit- prefix! Let’s hope for the same in Firefox 4.
  • As cool as it may be, I really hope we don’t start seeing webpages that are designed like http://www.useragentman.com/tests/cssSandpaper/cube3.html. CSS is awesome, but some things should not be used for certain purposes. (HTML is awesome, but <blink>/<marquee> should be used for any purposes ;) ).