It has been about 2 weeks since my last update but I have not been idle during this time. I decided to scale back on the rate of updates for a variety of reasons but work is ongoing and I check the blog/forums regularly so feel free to comment or ask questions. In the future I plan on posting updates about once a week or so, though the time between updates may occasionally be longer or shorter.
Also remember that you can see the full sized images by clicking on the pictures, they are scaled down to fit the blog format.
I have made good strides in the decompilation process, due to a variety of enhancements and fixes to my tools. Previously functions with multiple return statements or complicated flow control with dead code were problematic, resulting in sometimes non-nonsensical code, missing code or incomplete functions. The tool now properly follows the flow control and prunes unused code. Of course this results in functions were code is ordered based on when a branch was hit, so the resulting code must be reodered at the end of the process. Jumps with dynamic offsets are still problematic though, there is still more work to be done.
Next I fixed the “root function” determination code so it can successfully find “main” automatically. Previously I had to do it by hand which can result in errors. The unused function removal is now more robust.
Initialized static memory is now automatically mapped to the memory addresses used by the disassembled code, meaning that pre-initialized static data is now directly available. This is great for many reasons, including using the text referenced by the code to help identify the names and functions in many cases. This allows me to move a lot of the code to the correct files, so the structure of the source tree – in some cases anyway – can mimic what the original source might have looked like.
Unified Software Renderer
Recently I resurrected the software renderer I was writing for DaggerXL and start re-integrating it into the XL Engine. For the Beta 2 release, it will serve as a basis for the “unified 3D renderer” that can be used not just for Daggerfall but potentially other XnEngine games and for model-based elements of 2.5D games (such as Dark Forces). The “unified 3D renderer” will support both hardware and software rendering and – with the original code available – be able to functionally match the original visuals but with better performance for high resolutions and the ability to more easily add new features and fix bugs. Of course the original Daggerfall rendering will be available, at least until the new renderer can match it exactly (minus obvious bugs). Beta 1 probably won’t ship with this renderer but it will be available for Beta 2.
Below you can see some screenshots of Daggerfall using the cylindrically mapped sky and tweaked settings. Note that all of the 2D rendering has been disabled (weapons, UI, etc. – obviously not counting sprites in the 3D world). Also note that the rendering is not 100% correct but that will be fixed – including the wrong ground tiles being used, not a problem for the original renderer of course.
Build, Blood and the Newcomer
When working with the Blood code, one of the things I wanted to do was match up the decompiled source with the Build source in order to reduce the amount of work I had to do. I realized, however, that for best results I should test the Build source integration with something working and complete. So to that end, I added the first – and currently only – game that uses the original source code: Shadow Warrior. The purpose of this integration was as follows:
* Get something working with Build in the XL Engine.
* Start refactoring the code and getting it ready for Blood.
* Test the XL Engine functionality, including game life cycle, XL Engine services, sound, input and other systems.
* Have a complete experience to test with the engine and UI.
* Test the performance and memory usage with a complete game running.
When, in previous updates, I mentioned matching up Blood code with the Build code – I already had this working in the engine. In fact Shadow Warrior is 100% playable, including sound, music, controls, memory management and so on in the engine and has been for a month or two.
So why play Shadow Warrior using the XL Engine instead of an existing port? Honestly there aren’t really any compelling reasons, the existing ports do a great job. Of course I plan on changing this with future releases and in the future there will be more reasons to play Shadow Warrior on the XL Engine. Regardless it has helped me tremendously with the engine and Blood – so its a worthwhile addition even if no one actually plays it. That said, when it comes time to build the unified sector engine it will be very useful – like Blood it pushes the Build and adds Room over Room, drive able vehicles and other features.
This is a surprise I’m sure but, if things go well anyway, Shadow Warrior will not be the biggest surprise in store for the release.
As you can see, the UI itself has gone through some iterations since I last showed it. Of course any effects are optional and only work if you have a GPU capable of OpenGL 2.0 or newer (see the fullscreen view to get a better idea of what I mean). In addition sound effects have been added to the UI to improve the experience.
The XL Engine is progressing nicely and all of the features needed by the games are already implemented (as shown with Shadow Warrior). In the next update I hope to show screenshots of some of the other games in action. Finally here is the XL Engine Readme file that will packaged with the release (XLEngine.txt). In it is the copyright notice, description and credits. Take a look and let me know if I am forgetting anything, I want the release to go smoothly when it finally gets here.