Skies

The skies in Daggerfall are not constructed by a sky box, sphere, or infinite plane. Rather they are a backdrop composed by two tiling images, one for the west part of the sky and one for the east part. As the player looks left and right, the images are scrolled left and right. As the player looks up and down (or levitates) the images are scrolled up and down slightly to match the horizon line. This approach made for some dazzling skies back in the day, but has a few technical limitations for modern interpretations.

• While the sky looks quite decent at 1024×768 (screenshot), it does not scale well to high resolutions. On a widescreen monitor running at 1920×1200, the visible portion of our sky backdrop is being enlarged by over 30 times its original size. No amount of filtering can save it from looking stretched, and this spoils the effect greatly.
• By using backdrops, the sky does not actually go above the player’s head (or very far below the horizon), which limits the maximum pitch (angle looking up or down) to around 60-70 degrees.. If you’ve played Daggerfall, you might remember not being able to look straight up or down as you can in modern games. This is because there’s nothing up there to see!
• The sky backdrops are designed to give the illusion of sky to a player standing at ground level, or levitating slightly above it. My goal in Daggerfall Scout is to allow the explorer to walk around towns, or zoom all the way out to view a whole city at once. In the former case, skies would look fine, in the latter any pairing between horizon lines is lost and the illusion fails: the sky is visibly just an image painted behind a tiny floating city.

With the above in mind, I need to make a choice on how best to represent the sky in Daggerfall Scout. Do I turn the sky on when walking around at street level, then off again when the explorer zooms out too far? I would also prefer to be able to look 90 degrees up and down, but Daggerfall’s sky backdrops do not allow for this.

Unfortunately, there is no perfect solution. My options are to either limit mobility and view angle, turn skies on and off as required, or to implement another type of sky (which means losing Daggerfall flavour). I will return to this later.

Shadows

This one is easy to turn on in Ogre (screenshot made using basic stencil shadows), and the effect is quite dramatic even with traditional per-face lighting. Shadows can be adjusted for time of day so they are long in the early morning or late afternoon, and short during the middle of the day.

I am not using shadows permanently at this stage, as the final decision on how to handle shadows has not been made. I will probably end up using a unified light and shadow model before the final version, so this particular shadow technique is not final.

Also, If you look to the bottom-right of this screenshot, you will notice a working compass. This should help explorers keep oriented in cities.

Lights

Before illuminating my scenes properly, I wanted to get an idea of where lights are positioned, and how their radius extends to the buildings surrounding them. As a mock-up, I dropped in a red semi-transparent sphere over every light source in Daggerfall city. You might remember from Visual Diary: Bright Ideas that street lights are added wherever a flat using a texture from TEXTURE.210 (Lights) is present. In the first screenshot, you can see the lamp-post at the middle of the red sphere.

In the second screenshot is the entire city of Daggerfall, with all “lights” visible. There are several dozen potential light sources in this scene. This is also a great insight into how the developers positioned lights. They line walkways, surround gardens and flood the wealthy market district. Not all cities are as well lit as Daggerfall. Wayrest only has several in key points, and Sentinel is almost lacking street lights entirely.

In the next three screenshots, I have enabled a simple per-pixel shader that creates a light radius against buildings based on their distance from a light source. I’ve turned off textures so I can get a better idea of how the values look moving from light to shade. If anything, it looks a bit too smooth. I quite liked the rougher bands of the old Daggerfall lights, but this is something that can be implemented after some time playing with shaders.

Keeping in mind that I wish to view cities from street level, or all at once, one of the frustrations I have with lighting is the performance hit on lower-end hardware. To show the whole scene from above with all lights visible, a forward renderer requires a tremendous number of passes. There are several ways to optimise this (LuciusDXL has given me some great pointers), but the absolute best results come from using a different pipeline (deferred rendering, or light indexed deferred rendering).

I have chosen not to write my own engine this time around so I can focus on exploring Daggerfall, and not sink valuable time into engine building. The downside to this is that I’m limited to the features my chosen engine (Ogre) offers. Now, I’m aware Ogre’s compositor framework allows you to build a deferred renderer, but this involves more time than I am willing to invest. So for now at least, I’m limiting myself to forward rendering.

What this means is that I need to optimise lights when at ground level, and turn them off when the explorer zooms out to view the whole city at once. Alternatively when zoomed out, I can just switch off per-pixel materials and add simple point lights to the scene. It’s not like you can see much detail from all the way up there anyway.

A Red Herring

The first place I looked was the map data in WOODS.WLD. Every pixel on the small map data has a corresponding large map chunk. One of the data values in the header for this chunk always corresponds to a ground texture. This seemed like a promising place to start.

After a bit of experimentation, I found the texture value only seemed valid some of the time. In many cases, it was flat out wrong. The city of Sentinel is a good example. The large map chunk for this world pixel reported the ground texture as 302 (temperate), not 2 (desert).

In frustration, I saved out the data into a visual format with intriguing results. Only the far eastern part of the world map, and some of the south, had any definition. The rest was a flat sea of “temperate”. This obviously wasn’t right, so I had to keep looking.

I’m guessing the data visualised to the left is either from an old version of the game world, or used in some as-yet not understood way.

CLIMATE.PAK

The next place to look was CLIMATE.PAK, which also defines a single pixel that can be overlaid on the standard 1000×500 world map. This data has been known about for some time, but I’ve not looked deeply into how it is used.

The first step was to see what kinds of numbers we’re dealing with. Each climate pixel is a value from 223 to 232. To see this visually, I saved out a series of climate maps, each with a single climate highlighted where it’s used in the world. The screenshot to the left shows climate 226, which covers the mountainous regions of Wrothgaria, Dragontail, and interestingly the Isle of Balfiera. This seemed far more promising. Each climate zone neatly overlaid visually distinct areas of the world.

Once I knew which areas were affected by a particular climate, I fired up Daggerfall and started taking notes. After a few hours of testing, I found Daggerfall always uses the same texture base and plant archive for any given climate value. This allowed me to build a table of which climate pixels uses which texture series for buildings and ground scenery.

If you’ve used Daggerfall Explorer, then you have probably played with my climate texture swaps already. Knowing how to make the swap is one thing. Understanding where the game draws this data from is quite another. With this in place, I was armed to build climate processing into Daggerfall Scout.

Pretty!

New code doesn’t always go to plan. The trees and other ground scenery are processed correctly, but the ground and buildings textures aren’t quite right. Castle Sentinel is particularly attractive.

After quickly fixing a few bugs, things start looking better.

Working Climate Processing

Finally, Daggerfall Scout will build a map using the correct building textures and ground scenery for that climate. This has been confirmed by travelling through Daggerfall with Scout running alongside to many locations in each climate band.

The screenshots to the left show maps using swamp, desert, and mountain climates, with distinct scenery in place.

The next step will be to drop in skies. Once again I need to do some research to find out exactly which skies Daggerfall uses where. I’ll put up another visual diary once I’ve made more progress.

Default Scene

This screenshot is of a General Store facade at night. Note the street light is illuminating the store nicely.

Before taking this screenshot, I have prepared a few modified BLOCKS.BSA files with different flats in place of the defaults. The purpose was to see how Daggerfall handled a simple texture index change. If the light kept flickering, then I knew lights were stored elsewhere and had to keep looking.

Lights Out!

After changing the texture index from a street light to a spell effect, the lighting effect is no longer applied. This is a good sign that I’m on the right track.

Testing A Theory

After putting the lights out, it seemed likely that Daggerfall was injecting a standard light source whenever the engine encountered a flat billboard using any texture from TEXTURE.210 (Lights). The billboard is also set to be emissive so that it appears to be self-lit.

To test this out, I replaced the street lights with braziers, and the lights returned. This was enough to prove how lights work, but what about cows and cats? Are billboard sound effects played based on texture alone?

Daisy

For the next test, I found a nice dark spot with a cow standing near a building. This cow is mooing happily – and frequently!

Flame On

I then replaced Daisy with a brazier. Not surprisingly, the mooing stopped completely and the billboard started illuminating the building behind it.