A lot of things happened with xoreos this past year, albeit most of them hidden and “under the hood”:

I wrote about disassembling NWScript bytecode. The tasks I mentioned there are still open, too. If anybody wants to take them up, I’d be happy to explain them in more detail :).

We released xoreos 0.0.4, nicknamed “Chodo”. That was the only release of xoreos in 2016. xoreos 0.0.4 included some minor fixes and features for Neverwinter Nights, and the xoreos-tools package included the new NWScript disassembler.

In April, I reached a streak of a full year of daily xoreos commits. Due to some real life things, I had to take a break there, though. I’m now again at three months of daily commits, but there is a three-month “hole” between April and August.

GitHub contribution graph in April

GitHub contribution graph in November

Farmboy0 fleshed out the Jade Empire engine a bit, mostly in the scripts department.

I then implemented a few more animation script functions, too, which is especially noticeable in the intro animation for Hordes of the Underdark. I also fixed a mistake in the keyframe interpolation. This takes care of another glitch in Neverwinter Nights: model nodes rotating the wrong way around.

I fundamentally restructured our build system, or at least the autotools part of it (xoreos can be built using either autotools or CMake). Previously, we used a recursive autotools setup, where make recurses into each subdirectory. This is, unfortunately, pretty slow, among other drawbacks. I changed it to be non-recursive now, with the top-level Makefile instead being created using (recursive) includes.

I then introduced various smart pointer templates into the codebase, making it easier to read and easier to keep track of memory allocations.

berenm added AppVeyor integration. Like Travis CI (which we already use as well), AppVeyor is a continuous integration service. This means that every single commit to the public xoreos repository will now be built on Microsoft Windows, using Microsoft Visual Studio 2015, in addition to gcc and clang on GNU/Linux (via Travis CI). This ensures that any compilation breakage on these systems is immediately visible and can be fixed at once.

I am currently writing unit tests for the xoreos codebase, using Google Test. I already found multiple issues, bugs, and corner cases while adding them.

From my side of things, my current plan is to make my unit tests branch public some time in December. I’ll write a small announcement here about it then. A new release of xoreos, 0.0.5, should follow early next year.

As always, this all wouldn’t have been possible without a lot of people. For them I am thankful.

Farmboy0, for various fixes, implementations and file format spelunking.

The end of the year is approaching fast, and just like last year, I want to use this time for some retrospection.

First of all, what happened in the last year?

berenmadded support for building xoreos with CMake, by the way of parsing the automake files used for the autotools build system. This way, xoreos can now be built with either CMake or autotools. I was skeptical at first, especially since I harbour no love for CMake, but it is working reasonably well and I am quite happy with it. In hindsight, I was wrong to reject this pull request for so long.

I focused on supporting all the different model formats used in the Aurora games, and then I made all the games display their in-game areas with objects.

xoreos adopted the Contributor Covenant as its Code of Conduct, in the hopes that it helps foster a friendly and welcoming community.

I overhauled the script system, making it more generic. This way, I was able to apply it to all targeted games, except Sonic Chronicles: The Dark Brotherhood (which doesn’t seem to use any scripts at all). This included figuring out and implementing four new script bytecode opcodes: two for array access in Dragon Age: Origins, and two for reference creation in Dragon Age II.

I implemented reflective environment mapping for Neverwinter Nights and the two Knights of the Old Republic games.

I added a new tool to the xoreos-tools package: xml2tlk, which can recreate TLK talk table files out of XML files created by tlk2xml.

With these changes, I decided to push out xoreos 0.0.3, nicknamed “Bastila”.

This is all old news, more or less already discussed in previous blog posts. However, since then, I added yet another new tool to the xoreos-tools package: ncsdis. It’s a disassembler for NCS files, the stack-based compiled bytecode of the C-like NWScript, BioWare’s scripting language used throughout their Aurora-based games.

It basically replaces the disassembler within the old OpenKnightsN WScript compiler, with various added benefits. I’ll write a bit more about this tool in the near future, so for now I’ll just leave you with an example assembly listing it can produce, as well as a control flow graph it can create (with the help of Graphviz). As you can see, it already groups the instruction by blocks and subroutines. It performs a static analysis of the stack (to figure out subroutine parameters and return types) and it also analyzes the control flow to detect assorted control structures (loops, if/else). I plan to grow it into a full-fledged NWScript decompiler.

Additionally, I also added support for BioWare’s Neverwinter Nights premium modules, like Kingmaker, to xoreos.

On the documentation side of things,

I added comments and documentation to various files in the xoreos sources, hopefully making them more understandable and useful for potential new contributors and otherwise interested people. Considering how awful my memory is at, this is also a kind of future-proofing.

Farmboy0 added “research” subpages for various games on our wiki, filling them with information about their workings.

I am thankful to all the people in the different BioWare modding communities, for having figured out many different things already. Skywing for example, who had emailed me a few years ago about certain NWScript issues, issues I recently stumbled over again.

I am thankful to fuzzie, for giving me pointers on the NCS disassembler/decompiler.

I am thankful to the GamingOnLinux people, who do a lot of work reporting on all sorts of Linux-related gaming news, and who so graciously mirror my xoreos blog posts.

I am thankful to kevL, for notifying me of issues with xoreos’ build system on configurations I hadn’t thought about.

As I mentioned in Part I of what I half-jokingly called my “yearly update”, Geisha was only missing two hard-coded minigames, so it was kind of a low-hanging fruit to get supported. Unfortunately, as happens very often with me, I didn’t actually finish implemented those minigames just then, turning instead to other projects of mine.

“What is eos?”, I hear you ask. Well, in short, it’s an open source project I started to portably reimplement BioWare‘s 3D engines, starting with Neverwinter Night‘s Aurora engine. Quite a daring task, and one I can’t begin to hope to finish on my own, especially since I’m not really that versed in all that 3D stuff. But working on it is fun and scratches an itch, and maybe more people will join me in that particular quest some day.

Well, it’s been a year since you’ve last heard from me, so I thought an update on what I’ve been doing is in order.
As this will be a tad longer, I’ll do that in two parts: This here first post will cover ScummVM-related things, while the next post will talk about eos (which you might not have heard about yet).

Hey, here’s another small video, this time with Mike walking in-game (without pathfinding) and talking to Hank in the diner. Also a nice showcase for most of the remaining graphical glitches (highlighted in the annotations) 😉 :