Datafile format for SCS

Preliminary data structure for the configuration of the seasonal plugin. Using JSON:

     "SCS_Data" : [
          "Plugin" : "Skyrim.esm",
          "Options" : "unused",
          "Data" : [
               { "0x00000001" : [ "0x00000010", "0x00000010", "0x00000010", "0x00000010", "0", "0", "0x00000010", "0x00000010"] },
               { "0x00000001" : [ "path\to\model1.nif", "path\to\model1.nif", "", "0x00000010", "0", "0", "0x00000010", "0x00000010"] },
               { "0x00000005" : [ "0", "0", "0", "0x00000005", "0x00000005", "path\to\anothermodel.nif", "0x00000005", "0x00000005"] }
     } , {
          "Plugin" : "Somethingelse.esp",
          "Options" : "unused",
          "Data" : [
               { "0x00000005" : [ "0", "0", "0", "path\somethingelse\new.nif", "0x00000005", "0x00000005", "0x00000005", "0x00000005"] }
     } ]

Let’s break it down. (more…)

On Seasons in Skyrim

Through some internet randomness, about a year ago I found myself trying to play Skyrim for the first time.

I never got far.

I found modding the game to be far more interesting. Exploring the user-developed content that had already been created by that time was daunting, as its reach far exceeded anything Bethesda had put forward.

Eventually I began tweaking the mods to my liking. This is what I mean when I say hacking. My most recent hack is a tweak for one of the more popular mods to introduce a seasonal element: Frostfall gives the playet temperature and cold weather exposure. I added seasonal changes to this system.

That’s right, Skyrim has no seasons. It has a full-year in-game calendar, but no seasonal variation. If you want any change, you’ve got to travel (kind of like some coastal cities). A lot of very smart people have tried. It looks like at one point Bethesda even tried, but dropped the project.

I love challenges, so I decided to try as well. And I may have succeeded where other people previously have not, due to recent additions to SKSE (a program that hooks into the raw Skyrim binary and allows for extending it in various ways).

There’s a test plugin I’ve uploaded on the Nexus forums just as a proof of concept while I begin implementing it properly. I’m going to (vaguely) attempt to document my progress here, because I’m sure a variety of people will find this interesting, and this project is of a scale and style that I’m going to need beta testers at some point, to test with the large variety of (potentially) conflicting mods out there.

GPG Key Migration

As a follow-up to my earlier post regarding vanity keys, I figured I may as well make use of (at least one of) them. On that note, I’m migrating to a new key! This is actually really good timing, because there’s a key-signing tomorrow at the local LUG. Most of my signatures came from the last one of these I attended (same group of people, too).

Here’s my signed transition notice: (more…)

WineD3D Benchmarking Part 3: The Results

At long last, the results are in!

What can we tell from these?

Firstly, and most obviously, there is a large drop in performance for 3DMark2001 and ShaderMark between wine-1.5.8 and wine-1.5.9. This is not a real performance drop: as I noted in my previous post, prior to wine-1.5.9, XRandR support was incomplete, and some applications (i.e. 3DMark2001 and ShaderMark) were unable to render at 1920×1080.

OpenGL Tests

Furmark: flat-line consistency. OpenGL performance has not changed at all through the entire cycle. Not surprising, but good to know.

UnigineHeaven (openGL): Okay, it’s possible OpenGL performance has changed a little, but we’re back where we started.

Lightsmark (OpenGL): fairly steady, but a slight improvement

Xonotic: flat-line OpenGL performance again


Overall, OpenGL performance is unchanged, and is not likely to change much, either. OpenGL calls can be passed through natively. In fact, the wine D3D implementations convert everything to OpenGL calls anyway.


DirectX/D3D Tests

UnigineHeaven: nice 10% improvement around wine-1.5.4. Overall 13% improvement over wine-1.4. At no point is this faster than the OpenGL version, but towards the end it gets very close.

streamsrc / drawprim / clear / dynbuffer: I don’t pretend to know what they test, but except for dynbuffer, they all imrpoved. dynbuffer was flat-line.

3DMark2001: apart from the resolution recognition, there wasn’t much change here

ShaderMark: same as 3dmark, but with a 5% boost around wine-1.5.29. Interesting to note that running with PixelShader3.0, the test performed 2% slower than with PixelShader2.0. My understanding is PS3.0 is not fully implemented yet, and so many of the calls fall-back to PS2.0, anyway.

Half-Life2 (dx 8.1):  Slightly decreasing performance over the series.

Half-Life2 (dx 9.5): Also slightly decreasing, but definitely faster than with directx8.1

TrackMania: slight decrease, but an improvement in the fact that it wouldn’t give results prior to 1.5.16!


Results Summary

Some things improved, some didn’t, and some got worse. Overall, it probably depends on what application you’re using, but the improvement in XRandR support and many other things suggest that everyone should be using at least 1.5.9.

WineD3D Benchmarking Part 2: Phoronix Test Suite

After Part 1, I have waited to run any benchmarks, until it looked like they were getting close to actually releasing Wine 1.6. I wanted to run them all at once, so that the results weren’t skewed by system updates between runs (Another problem I have with looking at Stefan’s historic results: I don’t know which improvements are due to wine development, and which were from video driver/kernel/library updates).

In its own $WINEPREFIX, I have installed Phoronix-Test-Suite (PTS) and php for Windows. Unfortunately, some hacking was required to get PTS to output desirable system information, as the Windows side isn’t fully developed (There’s a lot of code like: if(phodevi::is_windows()) { // TODO: Windows support }). I didn’t keep track of everything I ended up changing, but I’d imagine much of it is irrelevant, due to a newer release of PTS (4.6) which I have yet to try.


Creating a vanity GPG key

I had decided a while back that I should generate a new keypair, as I’m still using an old 1024-bit DSA key, and it’s been recommended to migrate to a stronger RSA key for several years now (In fact,many key-migration tutorials date back to 2009, in response to an announced attack vector against SHA-1). Yes, I decided a while back… but never actually did it.

You see, there was a small problem: it had taken me a while to remember my key-ID. That arcane annoying random 8-digit sequence that is part of the fingerprint for every GPG key. It’s not globally unique, but it’s unique-enough to be useful. Mine is 04edc4b1.

I was determined to have something more memorable, or at least slightly more geeky (because having a GPG key honestly just isn’t geeky enough.)

Someone else had the idea of creating a vanity key-ID, too, but he was trying to create a specific key. His method for generating them is private, and I didn’t feel like reaching out to find out what it was, which meant rolling my own.

Since I wasn’t looking for a specific key, but just for something memorable and interesting, I didn’t have to create a collision scenario. I just had to create a bunch of keys, and filter them for “interestingness.”


WineD3D Benchmarking Part 1: Auto-Building from Git

I’ve been following wine-git a lot recently, and especially now that they’re starting to put out wine-1.6 release candidates. I’m especially interested in seeing the evolution of the DirectX performance.

One of the Codeweavers developers, Stefan Dösigner, has been running regular performance benchmarks tracking D3D development with Phoronix-Test-Suite, and it’s great to see the changes over time. However, I have one major problem with his results: He’s using a much older hardware for his tests. They’re run on a 8-year old 2-core CPU (Athlon 64 X2) and a 7-year old GPU (Geforce 7600GT). What does that really tell me about Wine’s performance on newer hardware? I wanted to know for myself.

To start with, because I wanted to be able to build from wine-git instead of using the Ubuntu Wine PPA, as well as rebuilding with “-march=native” and using Clang instead of GCC. (Through my personal uses of  Wine with a few games, I’ve found performance better when it’s built with Clang, although it varies from game to game, and is sometimes worse. For the benchmarking, I intend to run everything as built by GCC, since the earlier versions needed patches to compile via Clang.)

Over a series of iterations, I’ve thrown together some bash scripts which do the building for me:


Hello World!

The title applies in two senses:

  1. This is my introductory post. Something traditionally deserving of the moniker.
  2. The subject of the post will refer to a Hello World! of another sort

A little bit later than I would have liked, I found out about the Ubuntu App Showdown. It is likely the content of that URL will change, but the short version is that they’re running a contest, starting on June 18th, and ending July 9th, to promote the Ubuntu App Store, and also Quickly, their Rapid Application Development tool.

My first impression ofQuickly was that for something built to create GTK applications, it is itself lacking an GTK interface. I set myself to the task of usingQuickly to generate a frontend for itself.

The naive method is simply to stick a bunch of buttons in a window and make them launch external processes. This was how I started out, just to get something up and running. It makes far too many assumptions, and is prone to having things go terribly wrong.

Ideally, I’d like to embed the gedit and glade windows inside my “frontend,” but for the life of me, I cannot figure out how to do it. At least not by the contest’s deadline.


I really would like to finish up and make a proper submission. I think Quickly might be on to something. I just feel that “something” could go much further with a UI attached.