In this article I’ll talk about the progress towards version 0.20 as well as plans for supporting lower end systems.

Version 0.20 Progress

I’ve been continuing to work on DaggerXL version 0.20, so I’ll talk about some of the items that have recently been accomplished. If you’re following along on the DaggerXL forums, then most of this will be old news.

Dungeon Water

The first step was to figure out where the water plane height is stored in the data, since it is different for different dungeons. Once I figured that out, the next step was to render the water plane, which you can see below (thumbnails):

The next release will most likely just use the simple plane for the surface, as shown in the previous screenshots. I’ll figure out how I want to handle the surface (how faithful the default should be, that kind of thing) after the next build. In the future the water can look much cooler, but I’m still trying to focus on gameplay.

So the next step was to detect when the player was underwater and render the appropriate effects:

Finally I implemented the swimming mechanic, which uses the player’s skill to determine things such as swimming speed. In addition the swimming skill improves with use in the same way that running and climbing currently work. Finally I implemented the breath meter and drowning mechanic, though the meter was implemented after I took the above screenshots. Sound effects for entering the water, swimming and underwater ambiance have been implemented.

Object Orientation Issues

The next thing I worked on was the various object orientation issues, which cause such comical images as you see below:

These and many other weird anamolies have now been fixed for version 0.20. Most of the screenshots of various issues like these were taken by a DaggerXL forum member, Lennas – if you want to see more “bloopers,” visit the bug thread here.

Switches

Switches will work much more reliably in version 0.20. The first problem is that they were not animating correctly a lot of the time or not animating at all. These problems have been fixed. The second problem is that they often didn’t activate their target objects properly, which has also been fixed. In addition a new switch type has been found and implemented that controls the gates that you find in some dungeons.

Remaining Issues and Features

Now I am working on finish the dungeon texture region remapping, which makes dungeons in different areas of Daggerfall use different textures without having to create custom pieces for each area. This is similar to the texture remapping already done for exterior buildings, terrain and building interiors. After that is finished, the next goal is to fix some uv issues and finally flat scale/offset issues – which will fix things like floating poles and columns. On the feature side, once the bugs are dealt with, I will finish the loot system, leveling and get proper random encounters in. At this point I’ll release version 0.20 which will feature a much more robust dungeon exploring experience as well as full character advancement and leveling.

Low-End System Support

The focus of DaggerXL right now is, and will continue to be for a while, completing the “vanilla” Daggerfall gameplay. However I’m also going to start, slowly, putting in proper support for lower end hardware and optimizing the support for mid/higher end hardware. So here’s basically how I plan on tackling this issue:

1) Greater optimizations for the current renderer (of course). Things like reducing shader complexity as much as possible, reducing batch-count further and so on.

2) Support for pre-shader model 2.0 hardware with reduced effects/quality when necessary. The goal here would be to reproduce the effects as much as possible using fixed function. Any GPU should be able to run in this mode, though visual compromises will have to be made – possibly reduced exterior view distance, lighting simplification (i.e. dynamic light maps, texture projections, local tesselation + vertex lighting, etc.; not sure which one yet). – This option may be skipped in favor of option 3 below.

3) Software renderer – I’ve been wanting to play around with software rendering again lately (it’s been a while… other then some CPU raycasting experiments). The idea would be to support, with low to moderate resolutions, any system with a decent CPU(s). Older GPU’s (especially Intel) tend to have terrible and outdated drivers, so this may be a viable alternative to people with decent systems that have under-performing or old GPU’s. At low resolutions, this could also help systems with slower CPU’s since batching, CPU/GPU bus bandwidth and driver performance are no longer an issue.

Now due to the terrible drivers I mentioned, I’m actually considering skipping option #2. Basically decent Shader Model 2+ GPU (Radeon 9500+, GeForce 6+) or software. Normally I’d shy away from the complexity of adding a software renderer but there are a few compelling reasons -

* For some reason I want to tinker with software rendering. Being a hobby project, this is actually really compelling for me. :)
* By limiting the set of GPU’s to those with decent drivers and allowing a fallback for newer GPUs with bad drivers (think Intel), this should make supporting DaggerXL a little easier while making the potential audience larger.
* Support older systems without worrying about poor Driver support (at least for graphics).
* I plan on supporting multiple platforms eventually, so this would allow me to make sure that clean support is in for multiple renderers without affecting the higher level code. I.e. most of the code base shouldn’t care if it’s hardware or software.
* Wider system and possible platform support.

Of course, many of the cool new effects will be hardware only. However the software renderer should still look much cleaner then the original Daggerfall renderer. Some examples include fixing visual glitches between tiles, increased draw distance (over vanilla, less then GPU), lighting and Goraud shading on terrain, per-pixel perspective correction to make textures look cleaner, mipmapping, proper z-buffer, true color textures in 32 bit mode, etc. There will be two modes – 32 bit and 8 bit – depending on whether you want palette support or not. Texture replacements, sprite replacements and model replacements will be supported in the 32 bit software rendered mode and in the GPU mode – though performance will have to be a consideration of course.

In addition I plan on doing some limited one-time caching to speed up the initial loading times. This would happen automatically the first time the program is run or whenever the cache becomes invalidated (new version, modding, etc.). Again all automatic, but I’d like to get the load times to be much faster as well.

Advertisement