Daggerfall Imaging 2 Not Far Away

I’m almost done with the first release of DF Imaging 2. I’m just bug-catching and putting a little polish on some things. I should have it ready for download in the next week.

Edit: Just a quick update. I’ve been unable to work on Daggerfall Imaging 2 for the last few days due to real-life issues. I’m back to working on it now.

DFConnect Rename & Update

I’m gearing up for a new release of DFConnect, which has been renamed to Daggerfall Connect. I feel this is more in line with the naming convention of my other tools and avoids any potential misunderstanding with a trademarked property also called DFConnect.

The next build is a major update across the entire namespace. I have temporarily taken down all Daggerfall Connect pages while I update the documents, tutorials, FAQ, etc. These should be back in a couple of weeks.

To summarise, the following changes have been made to Daggerfall Connect:

  • DaggerfallConnect root namespace now contains classes and structures emitted back to applications, such as DFBlock and DFMesh. These were previously in the Arena2 namespace. The reasoning is to keep “low-level” classes in Arena2 and “high-level” classes in the root namespace.  The Arena2 namespace now only contains classes for opening files in the Arena2 folder.
  • The Utility namespace has been added. This is for mostly internal classes used by Daggerfall Connect, but may contain public classes at a later date.
  • The first reader class has been added. ImageFileReader is a vastly simplified way of opening any Daggerfall image file.
  • All image classes are now based on abstract base class DFImageFile. This allows ImageFileReader to handle all image files in a standard way and return a standard object back to applications regardless of the image file type originally opened.
  • Casing changed from lower camel casing (e.g. getFrameCount) to upper camel casing (e.g. GetFrameCount). This is to be more in line with .NET Framework conventions.

I will post more on this after Daggerfall Imaging 2 is released.

Daggerfall Imaging 2 – User Interface

This post is about a few of the UI enhancements going into Daggerfall Imaging 2. Not exactly gripping stuff, but I know many people are still using the old DF Imaging and may be interested in where I’m going with the new version.

When you open the old version of Daggerfall Imaging, you’re greeted with the following dense menu of image files to choose from:

Talk about a wall of text! Most people only fire up Imaging once they’ve found the file they want in Daggerfall Explorer first, and even then it’s easy for the eye to get lost. Things don’t get any better once you’ve opened an image file, either. You’re limited to simple “next-file” and “previous-file” buttons or doomed to return back to the mess above and start again. Let’s face it, Imaging is a nice exporter with a rubbish UI. And haven’t people let me know it; I’ve received dozens of emails over the years condemning the user interface.

So while finishing up image handling in DFConnect, I thought: “what the hell, let’s rewrite the old mongrel.” It was a perfect opportunity to improve on an old tool and catch some bugs in my new library.

Searching through images should be fun and easy, and the best way to accomplish that is to let the images do all the talking. It’s much easier to find what you want from thumbnails than plain-text filenames, so the first change was to put in a nice thumbnail viewer.

 Thumbnails Detail Tiles

The thumbnails are housed in a sizing pane and can be rendered in a few different ways. Currently, there are two formats for browsing Daggerfall’s image files. The Thumbnails layout is just a preview of each image file. You’ll notice these thumbnails are mini views of the entire file, not just a single image. Think of them as thumbnails inside thumbnails. The Detail Tiles layout has the same thumbnails, but with additional information about the image file itself.

This simple change makes browsing into image files a lot more visual and fun. I never feel “lost” among the files, something I felt all the time in the old Daggerfall Imaging.

For those of you following DFConnect, the thumbnails are generated by a new method called GetPreview() that renders an image file onto a managed Bitmap. You can specify the dimensions of the resultant Bitmap emitted by this method, allowing you to fit more/less images into a single preview. All DF image classes support this method.

New Exploring Tools

I’ve mentioned in the past that I plan on releasing standalone exploring tools based on DFConnect. The first of these tools is under development now, and proceeding rapidly. Below are a couple of screenshots of Daggerfall Imaging 2.0.


Daggerfall Imaging has always been the least favourite of my old tools. Despite solid exporting features, it was let down by many aspects of the user interface. To date it is the only tool I have received negative feedback about. For these reasons it became the first program I wanted to revisit as DFConnect matures.

I plan on releasing the first version of Daggerfall Imaging 2.0, complete with source code, before the end of May. This will coincide with an update to DFConnect. The goal is to create something useful and fun while honing DFConnect through actual use.

Time permitting, I hope to turn out new small-to-medium exploring tools every few months. This will give everyone something to play with and demonstrate what DFConnect is capable of.

Man, It’s Dusty In Here

Time to pick up a broom and get back to work. I hope everyone has been keeping well while I’ve been away.

I will be getting back into regular updates soon. After breaking from Daggerfall for a while, I’m keen to get back into the swing again. I have an updated version of DFConnect to post and more news on those mini tools I spoke about a few posts back.

Thanks to everyone that has written to me over the last few months. I’m still very much alive and haven’t abandoned the Workshop by a long shot. More to come soon.

DFConnect Library 0.4.5

DFConnect Library 0.4.5 is now available for Download. Please check the Issues page for current known issues, and the System Requirements page for help getting started.

The key feature of this build is RMB and RDB blocks are almost fully supported by the library. This release includes an RMB Block Viewer Demo (binary and source code included with library download). The control scheme of this tool follows the RDB viewer:

RMB (Outdoor) Block Viewer

  • Click and hold the left mouse button while moving the mouse to look around in a first-person manner.
  • Click and hold the right mouse button while moving the mouse forward and backwards to move along the camera’s facing vector.
  • Click and hold the middle mouse button while moving the mouse to go up, down, left, and right relative to the camera’s facing vector.
rmb viewer 1 rmb viewer 2
rmb viewer 5 rmb viewer 3
rmb viewer 7 rmb viewer 4

The upcoming 0.5.0 build will introduce Maps.bsa support, along with climate processing (i.e. using correct textures for swamp, desert, etc.). This build will also include a simple map viewer demo similar to early screenshots of Daggerfall Scout.

The 0.5.5 build will be a bug-fixing and polishing build. If you have any problems with DFConnect not mentioned on the Issues or Troubleshooting pages, please Contact me so I can address them.

Starting with 0.6.0, I will be adding more usability features to the root DFConnect namespace. While the individual classes in the DFConnect.Arena2 namespace greatly simplify access to Daggerfall’s files, the addition of custom readers will make this easier.

I have started work on standalone applications that demonstrate advanced use of DFConnect. The plan is to release these separately to the DFConnect Library as new exploring tools. Details of these tools will be released shortly after the 0.6.0 milestone.

Improving UV Generation

I recently engaged in a fruitful conversation on the DaggerXL forums with another DF hacker called DigitalMonk, whose specialty is Daggerfall’s textures. His interest was piqued when I made an informal comment regarding UV generation. After bouncing a couple of posts off each either, DigitalMonk’s thoughts and observations resulted in improvement to my current method of UV generation. He also made a discovery that will result in yet another improvement down the track. If you want to track the whole conversation, read back from here. I will summarise the outcome below so you don’t have to re-read the whole thread unless you want to.

Anyone who used Daggerfall Explorer would have noticed some 3D objects have skewed textures. At the core of this problem is how Daggerfall stores UV coordinates (UV mapping is a way of describing how textures are painted on a mesh). Rather than storing a value from 0.0 to 1.0 for every point, Daggerfall only describes UV coordinates for the first three points of any face (and optionally on the fourth point, but research has shown DF does not use this value). This probably doesn’t sound so bad, triangles only have three points right? Unfortunately Daggerfall doesn’t use triangles to describe 3D objects, it uses ngons that can exceed a dozen points per face. With only the first three UV coordinates to work from, the problem is how do we calculate UVs for the remaining points? Check out the main article on the UESP for more information on the problem and the solution we’ve been using up until now. You get some feeling from this short article on how much special handling is needed to cover all possible faces.

The problem with this solution is the constructed matrix can generate UVs that look a little weird, even when the determinant for that linear equation believes the face should be solvable. There are also multiple linear equations based on whether the face is coplanar to XZ, XY, YZ, etc. When UV generation failed, branching logic was needed to post-fix the UVs for certain faces, or skip the matrix generator for another technique, or just slap the correct UVs on directly. All of this made UV generation a bloated exercise that was tricky to debug. Fixing one problem would often break something else. All in all, there are three classes of texture problems:

  • Type 1. These are faces for which UVs cannot be generated using the existing linear equations, or are generated incorrectly.
  • Type 2. These are faces with bad source UVs (i.e. the coordinates are incorrect in Daggerfall’s files). Check out the eastern side of Wayrest Castle in-game for an example of this problem. This class of problem is visible inside the game.
  • Type 3. I used to think these were Type 2 problems, but DigitalMonk discovered these source UVs actually have extra bits packed into the coordinate. By removing these bits, the UV coordinate works as expected. This class of problem is not visible in the game, meaning Daggerfall uses these bits for some purpose, or at the very least just strips them out.

After my conversation with DigitalMonk, I’ve made some improvements to my UV generation that removes all Type1 problems with no special handling required. I managed this after realising UV generation is really just a 2D problem in 3D space. All of those extra linear equations were only needed due to the extra degree of freedom. By moving all the points into 2D first, I would only need the single XY linear equation to solve for all possible faces.

This worked perfectly, and allowed me to remove all my special handling. Below are a couple of screenshots from the test block viewer. The screenshots on the left demonstrate some problem faces with all special handling disabled. You don’t see these problems in the RDB Block Viewer demo included with DFConnect because of that special handling. On the right is the same scene using the new UV generator, with absolutely no special handling. All UV coordinates “just work”.

uv fixing 1 uv fixing 2
uv fixing 3 uv fixing 4

The next step will be to strip those extra bits for Type3 problems, and eventually write a simple UV patching function for the worst Type2 problems. Once this is completed, UV generation in DFConnect will be almost perfect.

I can’t thank DigitalMonk enough for taking the time to clarify the various UV problems and help me reach a better solution. Cheers mate.

DFConnect Library 0.4.0

The 0.4.0 library release is now ready for download. The Tutorials pages have been updated due to a few namespace changes. I have also added a System Requirements page.

The demos are very basic examples of how to render content out of Daggerfall’s files. Demos will be added for all major content types as the features are added to DFConnect.

I need to add pages specific to each demo. Until then, the controls for the two initial demos are:

Mesh Viewer

  • Click and hold the left mouse button while moving the mouse left and right to rotate the mesh.
  • Click and hold the right mouse button while moving the mouse forward and backwards to zoom in and out.

RDB (Dungeon) Block Viewer

  • Click and hold the left mouse button while moving the mouse to look around in a first-person manner.
  • Click and hold the right mouse button while moving the mouse forward and backwards to move along the camera’s facing vector.
  • Click and hold the middle mouse button while moving the mouse to go up, down, left, and right relative to the camera’s facing vector.

The FAQ and Issues pages have been posted. A Troubleshooting page has been added for common problems relating to things like build settings and dependencies.

The 0.4.5 release should be ready this weekend. This build will support RMB (Outdoor) blocks. From that point, I will start adding map and world reading for the 0.5.0 build.

Workshop Updates

Lately, I have been spending most of my development time on the DFConnect Library. Besides making Daggerfall’s file formats more accessible, I now have the added benefit of a framework for rapidly discovering new things. I hadn’t realised just how cumbersome my old code had become until I started writing tutorials and demos for DFConnect. I can do things with DFConnect in a few lines of clear code that previously required a lot of jumping through hoops. There’s a lot to be said for a clean rewrite and rethink. Time spent on DFConnect is time saved in the future. Best of all, it’s something the entire community can take advantage of.

I’ll give you an overview of what I’ve been up to.

DFConnect 0.4.0

The next build of DFConnect is almost finished, and will be up in the next few days (this weekend at the latest). This build supports reading from BLOCKS.BSA, with a strong focus on dungeon (RDB) blocks. Outdoor (RMB) blocks are implemented, but still need some testing. So dungeon blocks will be the focus of this release, and outdoor blocks the release after.

DFConnect Demos

To complement the tutorials, I have started work on a series of demos for getting the most of DFConnect. These demos will cover things like proper 3D visualisation of models, blocks, and maps. Future demos will cover action records in dungeons (moving blocks, levers, etc.) and working with world data.

These demos will be available as pre-built explorers for everyone to play with. The source code for these demos will be bundled with the DFConnect Library starting from 0.4.0.


This is a self-contained 3D rendering engine – basically a simple wrapper for Ogre3D 1.6.3. All DFConnect demos will use this engine for 3D visualisation.

The WorkshopDemoEngine does not expose the full functionality of Ogre, just enough to do the job at hand. The goal is to provide a series of simple and direct examples of how to work with DFConnect data without cluttering these examples with engine-specific boilerplate. The implementation should be generic enough for you to learn the important concepts and apply them to your own engine of choice.

The second purpose of the WorkshopDemoEngine is a simplistic foundation for everyone. If you are just getting started with the DFConnect examples, or C# itself, the engine will hopefully be an easy starting point for you to get cool results without struggling with a 3D library on top of everything else.

Dungeon Block Viewer

Below are a couple of screenshots of a test dungeon block viewer. This uses DFConnect and the WorkshopDemoEngine. A cleaned up version of this will be released with DFConnect 0.4.0, along with source code.

Also, a big thanks to Lucius for his tips on cleaning up the edges of my billboards. The 2D flats have lost their black edges, and now blend slightly into the environment instead (not really visible in jpeg below). Enabling anisotropic filtering on supported hardware has cleaned up texture noise on long stretches adjacent to the view direction (see bottom-right screen shot).

blockviewer1 blockviewer2
blockviewer3 blockviewer5

Future of Daggerfall Scout

I’ve been thinking a lot about Daggerfall Scout, and where it belongs in regards to how I spend my time on this hobby. A few things have made me rethink the purpose of this tool:

  1. The best part of Daggerfall Scout has always been exploring cities and dungeons. This will very shortly be possible using the DFConnect demos. While these demos won’t have all the features planned for DF Scout, they will do much the same thing – with source code and faster to boot.
  2. Working with Daggerfall has never been easier for me than it is now with the DFConnect Library. As Daggerfall Scout is based out of a much older code base, it carries a lot of baggage along with it. Every time I look at the DF Scout code these days, I spend all my time wishing I’d written DFConnect first to make life easier on myself.
  3. Last but not least is DaggerXL. What Lucius is doing here is incredible! Much of the “wow” factor of DF Scout has been far exceeded by DaggerXL. If I had to choose between exploring the world in DF Scout, or in DaggerXL, I’d pick DaggerXL every time. If that’s how I feel about my own program, then others probably feel much the same.

When I started on DF Scout earlier in the year, the Daggerfall scene was stagnant. Since then, Daggerfall has been released for free and Lucius has come along to bring our remake dreams back to life. With the community revitalised, DF Scout is just looking really tired. To be brutally honest, I think I’m wasting my time with it.

Moving forwards, everything good from DF Scout will be cannibalised for DFConnect. So rather than releasing one big program at some point in the future, I get to release lots of small purposeful programs almost right away. For people who just want to explore the game files, these programs will be available for download. For people who want to hack away at the Daggerfall files themselves, the source code for these programs will help you get started.

I feel this adds the most community benefit, and is more in line with the spirit of Daggerfall Workshop. Thinking back to the glory days of this site, I can only imagine how much more could have been accomplished if I’d started work on a Daggerfall library then, rather than sinking that time into other projects that ultimately went nowhere.

Community Forums

To start rebuilding our development community, I am reopening the Workshop forums in the next few weeks. This will be a place where Daggerfall hackers can get together and talk about their projects. If you are using the DFConnect Library, this will be the place to share your ideas and get support from the community. Promising projects will be given their own subforum, just like in the past.

In the meantime, I am opening up comments in the blog for new posts starting with this one. I look forward to hearing all your thoughts.

Introducing DFConnect

DFConnect is a class library that handles the nitty-gritty of reading Daggerfall’s known file formats. Written completely in C#, this is a ground-up rewrite of the code I have developed over several years, and will allow other developers to create their own Daggerfall tools without facing complicated format specifications.

The key feature of DFConnect is simplicity. Supported file formats can be opened and enumerated with only a few lines of code. Data is fetched easily from native files (no need to allocate or convert anything, just fetch away), and emitted back to your application in a format that can be effortlessly used. Data is emitted as standard managed types (e.g. strings, images, and structures) but can also be emitted as byte arrays for some data types (such as A8R8G8B8 texture data for marshalling into your favourite 3D engine).

Built on the Microsoft .NET Framework 2.0, DFConnect is compatible with modern Microsoft operating systems (XP, Vista, and Windows 7). The DFConnect library can be used in any .NET language, such as C# and VB.NET. This also grants you a wide variety of options for 3D visualisation with graphics libraries like MOGRE, Irrlicht.NET, and XNA that also support these languages.

While DFConnect is still in the early stages of development, I am going to make it available to everyone for testing right from the start. A series of basic tutorials will accompany the initial release, and more will be added over time. Please keep an eye on the Tutorials and Download pages for more information.

Project Work

I’ve had some project work come up that will keep me busy for 2-3 weeks. I probably won’t have much free time, but will update if I can.

Visual Diary: Building Maps – Part 1

The Cartographer view in Daggerfall Scout is a continuous map interface, allowing you to zoom all the way out to see the whole Illiac Bay at once, or zoom right in to street level to see individual ground detail and buildings. The location browser on the left is for quickly finding a location.



The first step was to quickly prototype a dynamic scrolling map. The screenshot to the left renders each world cell using a single texture (from TEXTURE.002, .102, .302, and .402 depending on climate type). Locations are just plotted as red squares.

This fairly basic setup solves most of the early problems, and helps me visually confirm my new ultra-fast world queries are working. Now to throw out the experimental code and write it again properly.


Top-Level Map

There will be several levels of fidelity to the map. To start with we have the whole Illiac Bay on-screen at once. On the left is the first version of this map. Water is blue, land is grey, and locations are just yellow dots. So many locations!

I tried several different approaches here before settling on dynamic textures mapped to quads. The next step is to add some details.



Region Coding

This picture colours each region band appropriately. The colours have been averaged from the actual region ground textures. Location dots have been disabled so I can see details.


Height Shading

Next I have modified climate colours based on elevation of the landscape. As you zoom in, this will be replaced by actual deformed terrain and textured ground.

Nothing here is pre-generated, this is all built dynamically by reading data from MAPS.BSA (locations), CLIMATE.PAK (climate), POLITIC.PAK (region) and WOODS.WLD (elevation data). Every “world pixel” is built from a combination of data from these sources.


Zooming In

This screenshot is a slightly zoomed-in version of the above. This is about the limit of the top-level map, once you zoom in much further, 3D elevation maps will start to be paged in. My next post will show the process of this being added.