Further continuing on the path to make all the engines display areas (see my posts on Jade Empire and Neverwinter Nights 2), I looked at The Witcher next.

As some people might know, CD Projekt RED licensed BioWares Aurora engine for the first The Witcher game (and only the first; the later parts use their own REDengine). And in many aspects, it’s very obvious that they spawn off directly from the Neverwinter Nights codebase, not from later BioWare titles. There have been quite some changes, though, to accommodate for The Witcher’s requirements.

Models

Due to their similarity to Neverwinter Nights‘ MDL model files (and with light help from Michael_DarkAngel’s twMax code), I had already a partially working loader for The Witcher’s MDB files. Or so I thought. Turns out, my quick & dirty hack was just about enough to get simple object and character models to show, but it totally failed on area geometry models. Those turned up completely invisible.

Textures and lightmaps

Closely looking at what my code does made me realize that the geometry itself loaded, but the textures failed to load. In fact, the textures it tried to load didn’t exist. However, there were similarly named ones in the resources. In fact, for the requested texture “foo”, there were texture resources “foo!d”, “foo!n” and several others.

Well, these are, it seems, lightmaps, and several different ones depending on the time of day (named after their Polish words). There’s:

  • !d, for dzień (day)
  • !r, for rano (morning)
  • !p, for południe (noon)
  • !w, for wieczór (evening)
  • !n, for noc (night)

Since not all of them might exist for a given texture, I settled on just loading the first one available. And yes, that gave me textured area geometry. With just the lightmap applied, it still looked a bit low-res, however. No wonder, there needs to be a base texture as well. Unlike Neverwinter Nights, which just straight up names the textures and has simple TXI files for some texture properties, The Witcher has full-fledged material definitions integrated into the model. And they’re shader-based. For the object models, it was enough to just take the texture names and run with it, but for the area geometry models, I had to extend this a bit. Granted, this is still a hack (we still don’t support shaders), and fails occasionally, only less so than before.

The result was this:

Kaer Morhen exteriorKaer Morhen exterior Kaer Morhen exteriorKaer Morhen exterior Kaer Morhen interiorKaer Morhen interior

There’s bits missing, I hear you say? Correct. Unfortunately.

TexturePaint nodes

More debug printouts on the model loader clued me in: there’s a new kind model node! The twMax author also noticed this; he calls them “TexturePaint”. No support for them in twMax, though. My Google-fu didn’t uncover anything else helpful either.

With no existing tools to help me, I had to do the dirty work myself. I pulled out my trusty friend the disassembler. Luckily, CD Projekt RED kept the tradition of supporting ASCII representation of model files, and so I was able to map out the loader code relatively quickly, for the most part.

First, I filled out my loader to stub and comment more MDB fields I previously just ignored. Then, I started implementing the TexturePaint nodes. Thanks to a brief email conversation with someone who’s also playing around with The Witcher models, I already knew what these nodes probably represented: geometry textured by blending several distinct textures together, to create more realistic terrain. I.e. similar to what I found Neverwinter Nights 2 does for its terrain geometry.

This turned out to be exactly the case, only with in-node weightmaps instead of the color channel approach in Neverwinter Nights 2. Additionally, these nodes too have a lightmap applied. Without shaders, this mixing is awfully slow and memory-consuming to do, therefore I instead just apply the lightmap for now. The result looks like this:

TexturePaint node with lightmapTexturePaint node with lightmap

It’s not exactly pretty, but it at least shows something.

Level of Detail (LOD)

After having implemented the TexturePaint nodes, I found a curious issue: certain nodes appeared twice, overlapping each other:

Overlapping model nodesOverlapping model nodes

This is the result of the LOD information in the node headers. Some nodes are supposed to be displayed when you’re near, some when you’re far. Simpler textured geometry nodes are displayed instead of the more complex TexturePaint nodes when far enough away to not notice the texture blending anyway. As a workaround, I rigged it to only display the highest LOD for now.

Areas

With the area models correctly loading, I went on to actually load the area. Owing to its origin, it’s again very similar to Neverwinter Nights, with one difference: no tiles and tilesets. Instead, the “tileset” value specifies the singular area geometry model to display.

I quickly implemented loading said area geometry model and simple area objects. And was baffled. The area geometry’s position didn’t match up with the objects’ positions. The area was so far in the distance, you couldn’t even see it. I looked and searched for a “tile” position in the area description files…nothing. As an experiments, I bound moving the area model to keyboard keys, and played around with it until it fit. The correct position, for some reason, is {1500.0, 1500.0, 0.0}. Don’t ask me why, but this works for all areas in the game. ¯\_(ツ)_/¯

Kaer Morhen exteriorKaer Morhen exterior Outskirts of VizimaOutskirts of Vizima Country InnCountry Inn

Object orientation

There was another thing I noticed, though: the orientation of the area objects is wrong. Unlike Neverwinter Nights, which only specifies one angle, the “bearing”, for each object, The Witcher lets you rotate all objects in all three axes. The orientation is described as a quaternion. Now, Neverwinter Nights 2 does the same and because we need the object orientation in Euler angles instead, we convert them. Unfortunately, that code doesn’t seem to work correctly in The Witcher. I assume it’s connected to the fact that The Witcher actually fully rotates the objects (while Neverwinter Nights 2 only, in effect, rotates around two axes), combined with how xoreos changes the axes around for world objects and additionally needs to translate the coordinate system from Direct3D orientation to OpenGL’s.

Try as I might, I couldn’t get the correct orientation. After way too much banging my head against the wall, I caved and put that onto the TODO pile. That’s something I have to revisit another day.

Creatures

“Only objects? Where are the creatures, the NPCs, the people?”, I hear you ask, imaginary reader. Well, The Witcher doesn’t directly describe creatures in the area files. Instead, there are spawn points, and I think the rest is handled by the game scripts. Not something I can do now. No NPCs for now, I’m afraid.

Miscellaneous

A few bits and pieces I found out or did during this endeavour:

  • I renamed the engine and namespace in xoreos from “thewitcher”/“TheWitcher” to “witcher”/“Witcher”
  • I noticed that The Witcher, unlike other Aurora games, encodes all strings in UTF-8. The language IDs are also wildly different. To get these together under one big tent, I changed how xoreos handles languages and encodings
  • The Witcher uses Lua scripts. I already knew that previously. But what I didn’t know: it also, additionally, uses the traditional NWScript. That’ll be a lot of “fun” to reimplement…
  • I found references to the LuaCOM library in the The Witcher disassembly, which provides Lua bindings for ActiveX components. I really, really, really hope that’s unused

In conclusion, area loading in The Witcher is now in a similar state to area loading in Neverwinter Nights, Neverwinter Nights 2, Knights of the Old Republic, Knights of the Old Republic II and Jade Empire. It’s not flawless, and there’s still a lot of things missing, but it’s a start. :)

What’s next? There’s three games left without area support: Dragon Age: Origins, Dragon Age 2 and Sonic Chronicles: The Dark Brotherhood. The latter is a Nintendo DS game, and is missing basic support for a lot of DS-specific file formats. In fact, I’m still not 100% sure this game even belongs in xoreos… The two Dragon Age games are somewhat further along: resource loading works and the texture format is known. They are, however, completely missing model support, as well as support for the new GFF version. Since that is at least something to go by, it’s possible I’ll tackle Dragon Age: Origins next. It could take a while until I have something worthwhile to report, though.

Continuing with my quest to make the engines display areas (as I did with Neverwinter Nights 2), I turned to Jade Empire the last two weeks. There was just one tiny issue: xoreos didn’t yet support the model format. While I could make use of other’s people reverse-engineering work for the model formats of other engines (Neverwinter Nights (Torlack), Neverwinter Nights 2 (Tazpn) and Knights of the Old Republic (cchargin)), apparently barely anybody bothered to look into Jade Empire. A person called Maian tried to figure out a few thing with just a hexeditor, and while that was a great start (and confirmed my suspicions that the format is similar to Knights of the Old Republic’s), it wasn’t enough for full support in xoreos.

So, with no other place to look, I buckled down and opened the Jade Empire binary in a disassembler.

Models

The loader function was quickly found, and in combination with Maian’s findings, the header was a cakewalk. The model nodes, the structures containing the mesh data, however, proved to be more tricky: the engine simply read the whole shebang into memory, to be used later.

Trying to find a shortcut, I remembered that Neverwinter Nights was able to load ASCII representations of its models. I searched for some common keywords like “verts” and “faces”. I had luck: there still is a ASCII model loader in Jade Empire, and not just a remnant of older code; it was updated to load ASCII representations of Jade Empire models. Moreover, for the most part, it actually parsed the model values into the same struct it reads the binary data into. Meaning: I could directly map data from the model file to their ASCII name, getting their meaning handed on a platter.

Parsing the Binary Model HeaderParsing the Binary Model Header Parsing the Node TypeParsing the Node Type Parsing an ASCII TriMesh NodeParsing an ASCII TriMesh Node

Untextured Geometry

This basically gave me the entirety of the general node header, and a good part of the TriMesh node (that contain model geometry in form of a triangle mesh) header. What it did not help with was the format of the vertex data and face indices; those were parsed into a different structure.

Chasing down the place where the binary data was put into that structure wasn’t too difficult, and soon I had enough information to render basic, untextured geometry:

Untextured GeometryUntextured Geometry

Materials and Textures

While there was a texture field in the TriMesh node, I found it was more often then not empty. Instead, there was a numerical material field, and a matching .mab file in the resource. A material definition in binary format. I also found several .mat files in the resources, ASCII material definitions. Trying my luck again for finding a loader of these in the binary, I searched for the string in the disassembly, and yes: there is a loader for the ASCII material files, parsing them into exactly the layout of the binary .mab files.

With that, and some fiddling with the offset into the vertex structure for the texture coordinates, I managed to render textured geometry:

Textured GeometryTextured Geometry

Triangle lists, strips and fans, oh my!

People familiar with Jade Empire might recognize that model: that’s Silk Fox (SPOILER WARNING on that link!). And for some reason, she usually wears a veil in front of face. So, where’s that veil?

Turns out, while meshes in Knights of the Old Republic’s models are always triangle lists (simple, unconnected triangles), Jade Empire models also contain other mesh types: triangle strips and triangle fans. For the sake of simplicity, I decided to unroll them into triangle lists for now, and that made the veil visible:

VeilVeil’d

Now, about that vertex structure…

I said above that I fiddled a bit to find the texture coordinates inside the vertex structure. Well, in fact, what I did was a big, fat hack: I hard-coded the offset based on the size of the structure. Obviously, that’s wrong. And it did fail for a lot of models, most prominently the models used for the area geometry.

Wasting quite some time trying to find how the vertex structure is interpreted in the disassembly (and even trying to trace it with WineDbg), I eventually found the answer where I should have looked way earlier: in the Knights of the Old Republic model loader. Since the two model formats are similar, I could just apply what the one did to find the offset in the other. With that, the area geometry renders more correctly:

Area ModelArea Model

Please note a few things. Yes, not all fields in the material definition are used yet (in fact, only the 4 base textures are used). As such, the rendering looks a bit off, especially where environment mapping should happen. That’s why the roof is semi-transparent, for example.

Also, while I did find the offsets for the textures, I’m not yet sure about the other pieces of data. Specifically, the normals and data found after the texture offsets. For example, take a look at this hexdump of the vertex array for Silk Fox’s head (click for a bigger view):

Vertex Data for Silk FoxVertex Data for Silk Fox’s Head

Each colored section is a new vertex. The red box, i.e. the first twelve bytes of each vertex, is the vertex position, stored as 3 IEEE floats in little endian byte order. The green box, i.e. 8 bytes at offset 0x14 within each vertex, is the first set of texture coordinates, stored as 2 IEEE floats.

Now, the field that in Knights of the Old Republic models denote the offset to the normals, points to 0xC. Unfortunately, there’s only space for 2 floats here, while the normal usually needs 3 floats. I have frankly no idea what’s going in there. In the case of the first vertex, the data could intentionally overlap, since the 0.0f would fit, but that breaks down not much later.

The data after the texture coordinates looks pretty un-floaty, more like several uint16 values. Again, no idea what that could be yet.

I am, of course, always open to suggestions if you should know what this could mean. :)

In either case, this brings Jade Empire model support close to the other model formats. I found that enough for now; I did spent about 50 hours staring at disassembly to get this far, after all.

Areas

Like a lot of things, areas in Jade Empire are structurally similar to areas in Knights of the Old Republic. A .lyt file specifies the layout: the positions of several models (called “rooms”) that make up the area geometry. And a .vis file specifies which rooms is visible from where, so that, in-game, rooms that are not visible from the current location can be culled from the render queue.

Unlike Knights of the Old Republic (and also unlike Neverwinter Nights), the Jade Empire areas don’t have .are and .git files to describe static and dynamic elements of the area, like the name, the music playing in the background, and objects and creatures found within. Instead, there’s another array in the .lyt file for simple, state-machine driven objects like doors, and an .art file gives some general information for each room (mostly wind, fog, camera perspective). Everything else seems to be placed or started by the game scripts.

A script system is not something I want to bind to the Jade Empire engine just yet, but loading the layout file and placing the room models, that I can do:

Two Rivers SchoolTwo Rivers School TienTien’s Landing Tea House

Again, the same caveats as above apply: no proper material support yet. And due to these issues of missing environment mapping and wrong blending, those two screenshots are actually less ugly than others. See for yourselves:

Broken Transparency MaskingBroken Transparency Masking Drawing Order vs Translucent MeshDrawing Order vs Translucent Mesh Bug in a Texture Loader?Bug in a Texture Loader?

Still, apart from the missing NPCs and objects, Jade Empire areas are now in a similar state to areas in Knights of the Old Republic. That counts for something, no? :)

During the last 2 weeks, I implemented basic support for Neverwinter Nights 2 areas and campaigns/modules. In particular:

  • Reading the list of modules and the starting module in a campaign
  • Reading module areas and starting conditions
  • Loading general area information like music
  • Loading area geometry and objects
    • Tiles
    • Terrain
    • Doors
    • Placeables
    • Environmental objects
    • Creatures
  • Flying through the areas in a “spectator mode”
  • Highlighting potentially useable objects
  • Hooking up a debug console
    • listcampaign/loadcampaign commands
    • listmodules/loadmodule commands
    • listareas/gotoarea commands

As a result, areas in Neverwinter Nights 2 are now in a similarly supported state as areas in the two Knights of the Old Republic games.

Indoor AreaIndoor Area Outdoor AreaOutdoor Area

So, here’s a few interesting things and/or issues with them.

Tiles and Metatiles

Like the first Neverwinter Nights game, areas in Neverwinter Nights 2 are (or can be, more about that later) made up of tiles. Meaning, a grid of models define the general structure: piece of indoors floor with walls, corners, windows and/or doors. Unlike the first game, though, there’s also metatitles, which are bigger models spanning the space of several regular tiles. This is used, for example, for the piece of the cave where you wake up in the Mask of the Betrayer expansion.

xoreos correctly loads and displays both tiles and metatiles.

Metatile in MotBMetatile in MotB

Terrain

Also unlike the first game, areas in the second game can also use terrain instead (or maybe even additionally to) tiles. The terrain is floor geometry unique to the area, and consists of patches of land and water, together with walk mesh definitions. Terrain is used very often in outdoor areas, to give those areas a more unique and less flat feeling.

xoreos correctly loads and displays the land and water patches, in a very rudimentary and stubby way.

Terrain GeometryTerrain Geometry

Environmental Object

Neverwinter Nights 2 adds a new area object type: environmental objects. These seem to be quite similar to regular placeables, only that they are static and can’t ever be moved. Apparently, their geometry is also baked into the area walk meshes.

As an extra weird bit, environmental objects store their position and orientation differently than all the other objects.

xoreos correctly loads and displays environmental objects in areas.

Trees

Neverwinter Nights 2 also adds new, non-static trees, courtesy of the SpeedTree middleware. Tree definitions seem to consist of just a few parameters and a random seed, the rest is done by the SpeedTree library.

xoreos does not load or display those trees yet. In fact, that will be a major task in the future. Luckily, trees aren’t essential; them missing is not a showstopper.

Creature Models and Animations

xoreos also partially loads and displays the various creatures (animals, NPCs, monsters, …) defined in the area files. There’s one caveat, though: the different model parts (head, hair, gloves, boots) aren’t actually attached to the body yet. They’re loaded as separate models and those are already placed correctly for default character dimensions. Of course, this would fail with scaled models (which we do not yet support).

The underlying problem is this: where the character models in Neverwinter Nights and Knights of the Old Republic contain special nodes telling the engine where to place the different body parts, Neverwinter Nights 2 has no such thing. Instead, each skin geometry vertex has a “bone index” attribute that, I assume, are indices into the Granny 3D animation files.

Which means: to properly attach the body parts, and to animate the models, we first need to figure those files out.

Bounding Boxes of the Model PartsBounding Boxes of the Model Parts

Tile and Object Tinting

A lot of objects in Neverwinter Nights 2 areas use tint maps. These are special textures with intensity values in their color channels. When an object is loaded from the area definition, those also contain 3 color values, and those color values are combined with the intensity values in the tint map to create a unique tinting of the object. This gives you the ability to create blue-ish caskets with yellow-ish metal rings, purple carpets, green vases and the like, without having to manually create textures for each color combination.

Moreover, tiles also use this tinting.

Currently, xoreos can evaluate and use those tinting, but entirely in software. For each object, an uncompressed RGBA texture is created, and the color values are mixed on loading. Of course, this has certain drawbacks:

First of all, it’s slow. But more damning, it takes up a lot of extra memory, both on the GPU and in the system’s RAM. As a ballpark, a common large-ish area creates 1GB of extra textures; even more when there’s a lot of objects around.

This is, of course, unacceptable. In the future, this tinting should most probably be done with shaders on the GPU.

Without TintingWithout Tinting With TintingWith Tinting

Without TintingWithout Tinting With TintingWith Tinting

Terrain Tinting

There is another tinting mechanism: terrain geometry uses a similar approach, only more extended. Instead of just 3 mix channels, there’s 6 (using 2 mixing textures) and instead of just mixing colors, textures are mixing. I.e.: a terrain patch can specify up to 6 texture that will be mixed according to the color values in 2 mix textures. The result is a layered texture that removes all visible texture tiling effects.

Additionally, each patch also has a color value to modify the texture, increasing the flexibility again.

At the moment, xoreos does none of this, for obvious reasons. Instead, the singular color value is applied to each patch, creating a more flat look.

Doors and Chests

Currently, xoreos does not display most doors and chests entirely correctly: doors are missing their, well, door part (only the door frame and knob are visible) and chests are missing their lid. I have no idea if that’s connected to the animation system, tinting, or what.

Broken Door and ChestBroken Door and Chest

All in all, I’m pretty happy with the progress so far. :)

Unbeknownst to me, the Neverwinter Nights Podcast, the podcast where I had my first and so far only interview, recorded its last episode in August. While I was not a frequent listener, I am still sad to see it go. So with some melancholy in my heart, I thank Brian S. Bloom, Ben H., Mark Shook and the rest of the crew for their work (and their continued shout-outs to the xoreos project) and wish them the best of luck in their future.

If a story-driven Neverwinter Nights 2 persistent world is your thing, please have a look at their’s, Realms of Trinity, and consider supporting them. Thanks.

The Neverwinter Nights Podcast website might go offline in May 2015, so I took the liberty of mirroring the episode with my interview here. You can find the original text accompanying the interview below.


Neverwinter Nights Podcast Episode 192 - Project Xoreos

Please join Mark AKA Madmage999 and Brian AKA Sir Brian, from NWN2 Realms of Trinity, as they interview the lead developer of the Xoreos project, Sven AKA Dr. McCoy.

Neverwinter Nights Podcast Episode 192

xoreos is an ongoing FLOSS project to reimplement BioWare (and derivatives) as used in their 3D games, beginning with Neverwinter Nights. The goal is to have a portable program to play those games even on operating systems those games were never meant to be played on, such as GNU/Linux and Mac OS X.

How is it licensed?

xoreos is free software and licensed under the terms of the GNU General Public License version 3 or later (GPLv3+).

A note about piracy

To use xoreos to run the games, you have own the original game media. We do not endorse piracy in any way, shape or form.

What does currently work?

In its current state, xoreos is still far away from its goal. At the moment, we are able to load resource archives and read basic file formats. Video and sound playing works, models are partially supported, and for earlier games, areas are shown and even some very basic gameplay exists.

What is left to do?

A lot of work is still left to do. We are actively looking for developers interested in joining our efforts in taking apart BioWare games and reimplementing them. If that sounds something you would find exciting and feel capable of, please contact us. We are always happy to see new faces. :)

The most pressing matter, however, is finding a person with knowledge of OpenGL: The current graphics subsystem is barebones and was quickly hacked together without much deeper understanding. If works for what is shown right now, but is far from being anywhere near adequate. There are a lot of features missing, and the performance is nothing to be proud of. Again, we would be very glad to welcome you in our still small team!

I am not an US-citizen, but nevertheless, I think the time is right for an introspective blog post about the progress and general state of the xoreos project and what I am thankful for. Oh, and no worries, I’m not throwing the towel here. :)

So, let’s start with what has happened: there has been quite some work and changes and fixes under the hood. Not as much as I’d like, and no hugely visible new features yet, but still.

On the code side, we have:

  • BZF: Added support for BZF archives, used in the iOS version of Knights of the Old Republic. Basically, these are your standard BIF archives, but the data inside is compressed using LZMA.
  • WMA: Fixed a crash in the WMA decoder occurring in some audio files found in the Xbox version Knights of the Old Republic.
  • FilePath and FileList cleanup: Lots of cleanup and restructuring in these utility classes handling paths, file names and lists of these.
  • Rewrote absolutize(), relativize(), normalize(), canonicalize(): These functions operate on path. They create absolute paths from relative paths and vice versa, normalized (resolving ambiguities like “/./”) or canonicalized (stronger disambiguities including symbolic links) versions. As a result, paths in the config file now properly resolve ~/ to the user’s home directory.
  • ConfigDir and UserDir: Changed the location of the config file on GNU/Linux to $XDG_CONFIG_HOME/xoreos/xoreos.conf (i.e. following the XDG Base Directory Specification) and on Mac OS X to ~/Library/Preferences/xoreos/xoreos.conf. Likewise, the default log path is now $XDG_DATA_HOME/xoreos/xoreos.log on GNU/Linux and ~/Library/Application Support/xoreos/xoreos.log on Mac OS OX. On Windows, they are still in $APPDATA/xoreos/.
  • UNUSED: Added an UNUSED macro to mark deliberately unused function parameters and enabled the compiler flag to warn about unused function parameters without this macro. This helps find places where the lack of usage was in error.
  • Icon: Embedded the xoreos icon into the executable to be displayed in the standard application icon of the operating system.
  • Loading progress: Added a progress bar visualizing the game loading stages at startup.
  • Split docs / tools repo: I split the xoreos-docs repository from the xoreos-tools repository. Both are now clean standalone repositories.

Additionally, I started working on another little tool: Phaethon. Phaethon is a graphical resource explorer (using wxWidgets) for BioWare Aurora engine games, able to look into the archives, extract files, display images and play audio files. It’s not yet finished, and there’s several things left to implement, including displaying GFF files. The goal is to have a more user-friendly, GUI companion to the existing CLI xoreos tools.

There has also been several improvements on the documentation side of things:

As you can see, this is quite a list. And that’s only half of the story. Leading to what (or, more precisely, who) I am thankful for, there’s been contributions by several incredible people:

  • I am thankful to ImperatorPrime, for wrangling the Travis CI integration. This also helped me in setting up a more comfortable, semi-automatic Coverity Scan integration.
  • I am thankful to Supermanu, for improving on the Neverwinter Nights GUI code and for continuing to implement the Neverwinter Nights character generator.
  • I am thankful to mirv, for starting to tackle the monumental task of rewriting the graphics subsystem. I’m looking forward to seeing this evolve, so that we can finally put my naive OpenGL code out of its misery.
  • I am thankful to clone2727, for all his insights and advice over the years, for always having an open ear for my complaints and rants.
  • I am thankful to all the other people providing me with help, with tips, bug reports, bug fixes, file format information, existing modding tools, Aurora engine knowledge, complaints, offers to contribute, etc., etc., etc.

There, this is what’s happened in the last 7 month since the last blog post; this is the current state of the project. Looking forward, here’s hoping that we all continue to find time to work on xoreos, that maybe more people will join us and that together, we can make this project bloom into something wonderful.

At the suggestion of ImperatorPrime I should set up a MediaWiki: https://wiki.xoreos.org/. The sidebar link has also been updated to reflect the change.

This will hopefully be more flexible than the GitHub wiki, and will allow easy contributions by people outside of GitHub. The idea is that this will become a knowledge hub into the internals of BioWare’s Aurora engine. Any interesting things anyone has found out, we’ll be glad to have documented here. So please, if you feel the need to crawl deep into the bowls of the Aurora engine, or have already done so, add your newly-found understanding to our wiki. :)

We will be migrating the GitHub wiki pages to our wiki, and see about adding some new information as well, in the following days.

A few days ago, I registered xoreos for Coverity Scan, a static analysis service that is free of charge for open source projects. ScummVM was already in there, so I knew how useful Coverity is.

Since I had already ran cppcheck over the codebase in the past, the number of issues wasn’t high, still Coverity found 79 potential issues. Of course, 2/3 of them were false positives or intentional (mostly uninitialized member variables that are set later in init methods), but about 30 issues were real. I immediately started fixing them.

I closed the last remaining issue yesterday, so now xoreos is issue-free according to Coverity. For now, at least. :)

This is a quick attempt at building a site for the xoreos project.

Here’s what went into this:

  • a new logo (just text using the Rezland font)
  • a basic octopress site