I spent the last few days exchanging the graphics engine in Daggerfall Scout from Irrlicht to Ogre. This came with enough surprises and frustrations to last me a few weeks.

To paraphrase one of the best quotes I’ve read while comparing these two engines: “Irrlicht quickly lets you get your project to the point where you need Ogre to complete it.” That certainly was the case DF Scout. Irrlicht required very little investment in time to get up and running, but poor mesh loading times and limited support for dynamic content were starting to be a drag.

Fortunately DF Scout talks to an engine wrapper that handles all the dirty work. I should just be able to swap in a new wrapper and everything will be peachy, right? The initial work was easy, and before long I had a new Ogre wrapper happily chugging coloured pixels into a viewport.

The next step was to build .mesh and .material exporters into the Cache Manager to change all that Daggerfall content into a format the engine could load and render. This required a few changes to DFLib to break meshes down into named submeshes rather than use attribute buffers (which is more common in D3D). Again, not so hard. I’ll even go so far as to say I enjoyed it.

Problems started when I loaded my first city and everything was back to front. All the meshes were in the right place, but they were flipped. Imagine looking a sign and the letters are back to front, and then imagine a whole building flipped that way. The effect was a little unsettling.

The root cause was that my old engines, and more recently Irrlicht, happened to use a left-handed coordinate system. This coordinate handedness is ubiquitous in my code (and my thinking). I use left-handed coordinates everywhere in DFLib, in DF Scout, in the content builders, in the scene files. Now in comes Ogre with its fancy right-handed coordinate system making my buildings look peculiar.

Of course, I didn’t work this out right away and spent a lot of time trying to fix my mesh builders, assuming I did something wrong in the new submesh breakdowns. When the penny finally dropped (with a clang), I just kind of sat there stunned thinking “how the hell am I gonna fix this, I use left-handed coordinates everywhere.”

After a quick cup of coffee and wishing I was a smoker – or that my girlfriend who is a smoker was home so I could at least get a passive hit – things didn’t seem so bad. In the end, all I had to do was change face index ordering in the mesh builder, and teach the engine wrapper how to deal with the conversion (a quick sign inversion of the Z axis). Of course this isn’t ideal. While it’s easy enough to fix handedness in the engine wrapper, the engine itself is still right-handed while the content builders are left-handed. This will probably lead to confusion down the road, and the confused person will probably be me.

And the results? Well, they’re awesome. Ogre loads its native mesh format incredibly quickly – even the largest cities fly into the scene almost instantly. The material system is excellent, far more power than required to render Daggerfall’s old content. This should give me some interesting tools as my experience with Ogre grows. Overall, the work has been worth it.

The downside is that I’ve spent a few days gutting DF Scout and more or less getting back to where I started. Oh well, back to the fun stuff.

Anyone that has written mods for Daggerfall, or even peeked at the file formats, will notice just how unusual these formats are. There are five different bitmap formats, each with their own specification, three 3D model versions, two major block formats and, thankfully, only a single map format.

Looking deeper things get even stranger. The 3D models aren’t stored as triangles – a single face primitive might have upwards of 12 vertices. Considering modern gaming cards generally feed off triangles, these models have to be converted before they can be rendered properly. Loading a city or dungeon into memory can take several seconds of processing on a fast computer just to load a small map.

My solution was to pre-convert Daggerfall’s files into something manageable, rather than convert everything at runtime as I have in my previous tools. Daggerfall Scout has a feature called the Cache Manager which builds a personal cache from your Daggerfall CD containing pre-converted textures, 3D objects, blocks, and maps. The following table shows the process in a little more detail.

Fresh Install The first time you open Daggerfall Scout, there’s nothing much to look at. I don’t distribute any copyrighted content with my programs, and I don’t plan on starting. Even the world map image is Bethesda’s property. By itself, Daggerfall Scout is useless. Before you can do anything with Daggerfall Scout, you have to build your personal cache. If you open the screenshot to the left, you will see a message on the status panel guiding you to the Cache Manager.

Cache Manager Opening the Cache Manager shows that you need an update. This only needs to be done once, but you may also need to update your cache after downloading a new version of Daggerfall Scout. Clicking the Update button starts the process.

Select Your CD The next step is to insert your Daggerfall CD. You must tick the box confirming this is an original and legally purchased CD before the program will allow you to continue. After clicking OK, the update process begins. This can take several minutes based on the speed of your PC. Once the cache has been built, you can put away your Daggerfall CD.

Cache Complete The cache has been built, and all groups show they are updated and ready. Clicking Close will take you back to the main program.

Scout Ready After closing the Cache Manager, Daggerfall Scout detects the cache is now up-to-date and initialises the exploring components. The world map and location explorer come online, and the 3D engine is prepared to render. From this point you can start using Daggerfall Scout to explore.

The contents of the cache are easy to work with. Bitmaps are saved to standard PNG files, and constructs like blocks and maps are written out as XML documents. This makes exploring Daggerfall a faster, cleaner, and more stable process.

One of the key goals for my abandoned Daggerfall Project was to bring the virtual world of Daggerfall back to life. Prior to that, all of my exploring tools were about specific media. If you wanted to listen to Daggerfall’s music, you fired up Daggerfall Jukebox. If you wanted to view and export bitmaps, Daggerfall Imaging was the tool for you. For most other things, Daggerfall Explorer and Cartographer had it covered. But none of these tools gave you the ability to really visit a place.

While The Daggerfall Project was never close to a finished work, I put a lot of effort into visualising the world. It’s a shame to let all that go to waste. My solution is a new exploring tool, something that lets you explore the Illiac Bay for the hell of it. This new tool is called Daggerfall Scout, and you will be able to track its progress at this blog over the coming months.

To get things started, I want to talk about the goals I have for Daggerfall Scout, and what you can expect to see as work progresses. The most important thing to realise is that I am approaching this as a hobby. Some people play golf, or paint, or fish. I work on exploring Daggerfall. It’s my version of a good day out on the water drinking beer and reeling in snapper. My number one goal is to have fun.

Just as important is to keep things legal. Daggerfall is Bethesda’s property, not mine. Like all of my tools, you will need to legally own the full version of Daggerfall before you can use Daggerfall Scout. No content belonging to Bethesda is distributed with my programs. If you don’t have your original Daggerfall CD handy, you won’t be able to play with Daggerfall Scout.

Last but not least is to keep it simple. In the past, I’ve written my own 3D engines. This time around I’m using a free, open-source graphics engine as the back-end to my tools. Daggerfall is not a graphics powerhouse and it doesn’t need a hand-rolled engine to render the world. Time previously spent on developing an engine can now be better put to use on the fun stuff.

Keeping those three goals in mind, my overall objective is to take the best parts of the abandoned Daggerfall Project and put them into an exploring tool that will hopefully recapture some of the magic of Daggerfall and put it at your fingertips.

With all that out of the way, let’s take a look at where I’m up to, and where I’m headed:

Privateer’s Hold This first image shows the basic layout of Daggerfall Scout. The user interface can be docked to the top or bottom of the window, or collapsed down to a small status bar with just the basics. In the bottom-left is a map of the Illiac Bay, allowing you to choose a region to explore. Just to the right of that is a hierarchy of locations that can be filtered by type. If you’ve ever used Daggerfall Cartographer, you will be familiar with this concept. The difference here is that Daggerfall Scout supports all world locations, including dungeons and interiors. The blue square on the right will eventually be used for several purposes, such as displaying a graphical minimap and controlling properties. Along the top of the user interface is a status bar and commonly used buttons. When collapsed, this is the only visible portion of the user interface. Currently loaded is the centre portion of Privateer’s Hold.

Daggerfall City You can see from this screenshot I’m only part-way through porting my world builders from Absinthe (engine written for The Daggerfall Project) to Irrlicht (a simple and easy to use open-source engine). The ground plane and the sky are missing! I will slowly fill in the blanks as development progresses. If you open the thumbnail and look at the location view, you will notice there are two Daggerfalls in the tree view. The parent Daggerfall is the city. The child Daggerfall is the dungeon contained inside Castle Daggerfall. I am working on a free-roaming mode allowing you to enter dungeons and buildings through the front door, just like you would in the game. For now, all dungeons follow this format, allowing you to swap between world cells and dungeon cells with a single mouse click.

Castle Daggerfall This screenshot is an overhead view of the twisting labyrinth inside Castle Daggerfall. If you look to the right of frame, you can just see the Treasury. How many hours have we all spent search for the Totem in that twisting mess? Another limitation of the current build is lighting. Ultimately, I want to render Daggerfall’s light sources as they appear in game – recapturing the atmosphere of those dark places. While exploring you will be able to toggle gravity and collision, allowing you fly through the map with ease or explore on foot.

Daggerfall Treasury This is a close-up of the Treasury inside Castle Daggerfall. Using the first-person flying camera with no collision, I have positioned myself high in the room. One of the long-term features of Daggerfall Scout is to allow world interaction. There is a complex puzzle in this room to find your way to the Totem. I would like to enable the explorer to action levers, teleporters, doors, etc.

Mantellan Crux This famous dungeon marks the end of the main quest in Daggerfall. Each part of the dungeon is a self-contained puzzle room where you are beset by foes. Only the most powerful characters could find their way past these challenges. This screenshot also shows the user interface collapsed down to just the status panel.

Blind God A close-up of the fire room in the Mantellan Crux, looking down on the Blind God.

I hope to release the first version of Daggerfall Scout in a few months time. The plan is to release a fun world explorer and continue to add features in subsequent builds.