Archive for March 2013
I’ve said in previous posts that I planned on completing the gameplay for the Beta – making DaggerXL a full DosBox replacement for Daggerfall. I also said that with the most authentic settings – extended features disabled – that DaggerXL would behave almost identically to Daggerfall, with the exception of fixing game breaking bugs like crashes and allowing the game to run at a fluid framerate without the gameplay elements messing up (no fighting with cycles or dealing with low framerate so NPCs can walk). What I haven’t said is how I am accomplishing these goals.
In the past I’ve done some reverse engineering of certain contained elements (like reading some table data from the executable) and spent a fair amount of time puzzling through file formats, testing stats and their reactions and so forth. But I’ve been working on something else without telling a lot of people that will help me make DaggerXL as accurate an emulation of the original as I want it to be, literally. To put it simply I’ve been decoding the original executable and reconstructing it in my own C code – completely (not just bits and pieces). Then I take that C code and modify or write the systems properly in DaggerXL, fixing game breaking bugs and refactoring to fit the rest of the game/engine. What this allows me to do is make DaggerXL just as faithful and authentic as a pure source port would be even without having access to the original source code.
During this process, I’ve been putting together a temporary executable (“DaggerfallDOS”) which I can run and verify that I’ve interpreted the code correctly. This uses just the original Daggerfall code – decompiled and rewritten in C – with the exception of OS calls and Windows boilerplate. I don’t plan on releasing this but all the code that goes into this is being used to make DaggerXL as authentic as a source port.
If you want an example, look at this page: Decompile-Example. It shows just one function, much much more of this process has been completed. And this code (and the functions that it needs that aren’t shown) were used to render this:
This is being rendered directly from the decompiled Daggerfall code, in addition the mouse and keyboard input works, you can select the appropriate option from the keyboard shortcuts or mouse. I’m currently working through from beginning to end, making sure that each part works properly by using the new executable. This means that with the Beta, DaggerXL will be 100% vanilla Daggerfall gameplay complete – and will be nearly 100% authentic with the appropriate settings. Of course the extended features I’ve already shown will still be available – higher resolutions, color depth, texture filtering, higher quality lighting, bloom, large scale terrain rendering, improved terrain heights and visuals and much more. This process is going extremely well and should be complete in a few weeks, after which I can release the Beta – after a short period of closed testing to get rid of any remaining unknown issues.
So what does this mean for the other games? Its quite simple – every supported game will be as good as a source port when they reach Beta, DarkXL and BloodXL included.
As you may have noticed, I’ve switched focus a bit lately. I will continue with the terrain and post results in the relatively near future – much of the work is complete – and it will still be in the Beta as previously discussed. However I’ve spent most of my time lately figuring out gameplay elements, in order to get the final – proper – Daggerfall gameplay in pace for the Beta. This has involved additional testing of Daggerfall as well as debugging the executable running in DosBox and reverse engineering. There will be settings to determine how authentic the Daggerfall experience is in DaggerXL, or how enhanced – with the most authentic settings being very close to DOS Daggerfall – except for fixes to game breaking bugs (and things like modern compatibility, performance and so on that you’ll get from the XL Engine). On the other end of the spectrum you can have texture filtering, bloom, smoother motion and control, extremely long view distances and more. The key is that you can pick and choose how authentic or enhanced you wish your experience to be in different areas.
Earlier today I took a small break from all the gameplay stuff to put the various texture filtering options in the engine again. Usually you get the choice between disabling filtering entirely – which gives you the sharp but blocky and jagged look to the textures and bilinear/trilinear which smooths out the jagged edges but blurs out the details in the low resolution textures. For the XL-Engine, I’m adding a third option: “Sharp Bilinear.” Sharp Bilinear preserves the blocky nature of the original textures but adds smoothing to the edges, giving the cleaner filtered look without blurring out the texture details.
Click on the thumbnails for full size screenshots, the effect is somewhat subtle:
From left to right: Bilinear Upscale + Trilinear, Sharp Bilinear Upscale + Trilinear
Sharp Bilinear Upscale + Anisotropic
As you can see, assuming you looked at the full size images, “Sharp Bilinear” preserves the “pixels” when upscaling the textures but still applies some filtering to avoid aliasing and shimmering as you move around. In my opinion at least, this gives you the best of both worlds and looks much better then pure bilinear for older games with smaller textures. In addition it does not require any additional texture lookups, just some shader code that alters the texture coordinates to adjust the effect of the hardware bilinear filter.