The XL Engine is and will remain free, donations are purely optional but greatly appreciated.

Recent Comments

I missed the last XL Engine blog post and so delayed the Alien Awakening post from this week as well. Once the XL Engine progress is back on track, the Alien Awakening posts will resume. I wanted to show a movie for this post to show where things are now… but I’m not quite there yet due to some delays. However there has been a fair amount of progress that I’ll talk about in this post.


Logics are a system where behaviors can be defined and attached to objects, similar to the Logics that were used in DarkXL. Rather then having an object have fixed behavior – objects are basically containers to which components and behaviors can be attached. Logics are contained behavior modules that can be implemented in either code – in the game DLL – or in script. These logics are then referenced by name and can be added or removed from objects at runtime. In order for Logics to affect objects they have various callbacks that may be called, such as Update (if the object is currently active) and can also receive messages, though during setup the Logics must opt in to the messages that they wish to receive.

The basic Logic that a game needs is the player itself, which is currently implemented in the game DLL. The player Logic is no different to the Engine then any other Logic but it is where the player behavior is controlled – including input that may affect the player. Other, non-player affecting input is handled by the UI script that runs the “GameView.” For DaggerXL I’ve also implemented the Logics that control Doors, switches and other interactive objects inside the dungeons. Basically this means that the dungeon interaction is nearly finished and I’ll probably be moving on to exteriors in the coming week and finally getting everything back to where it should be. :)

Another area that I’ve been thinking about is the editor that will be coming after these sets of builds are complete, as you’ll see below.

Logics define the data that they need, per object, in order to operate. This data can simply be space to store state, such as the current animation time. However this data is oftentimes derived from the objects themselves or loaded data. In order to link data that the logic requests per-object to the engine data semantics are used. As data is loaded or defined, a particular variable may register a semantic with the Logic/script system. When a Logic is assigned to an object the semantics are matched up and the data setup accordingly. But how do objects receive Logics? For existing data, the data format loader manually assigns logics based on the object type. For example “Logic_Door” is used for door objects in Daggerfall. When the editor comes online, the user will be able to assign whatever Logic they want – it is simply stored as a name string. In fact an object can have any number of Logics, which simply are processed in the order that they are added. In addition there will be editor semantics for the Logic data declaration – and these semantics and UI meta data defined inside the scripts or code will be used to generate the editor UI needed to assign data to an object in the editor.

As an example, let’s say you wanted to add a new door type for DaggerXL. You would create a new Logic script file where you create the Logic. In the data declaration you define the data the Logic needs per-object and assign the appropriate semantics and UI meta data. You can make the UI use edit boxes, sliders, check boxes or other appropriate control including sensible limits. Then simply include this Logic file in the Core Logics UI file for your mod and the engine and editor will pick it up automatically. In this way behaviors can be added or edited in seconds and the editor immediately allows you to start using the Logics with an appropriate UI.



As I’m sure you’re all aware, I’ve been adding software rendering support for a variety of reasons. Among these reasons include: increased compatibility, closer emulation of the original look, as a reference for figuring out and matching up the rendering for all modes as close as possible. However I ran into a problem: there are a variety of feature combinations that I wish to support and I don’t want to add a bunch of code or conditionals to the scanline rendering – since it is the most time consuming part of the rasterizer. What I had been doing is hand coding a variety of scanline drawing functions that used only the features that were necessary but it became obvious that this wasn’t going to scale. For example, the 32 bit renderer became out of date with the 8 bit renderer that I had been focusing on.

The shader system (OpenGL, shader-based renderer) uses #defines to allow a few shaders to be coded, the shader code actually used is based on this base code with the appropriate defines set. For every set of features shader code is generated that fulfills the requirements without requiring a large number of if statements in the shader code or having to write a bunch of redundant code that may become out of date.

So I basically decided to implement the same system for scanline rendering in C/C++. There is one routine for scanline rendering with defines for the various feature permutations. When the engine renders triangles, the appropriate permutation of the scanline rendering routine is used to render the triangles with as little code in the inner loop as possible. So now adding new features to the renderer has become easier without becoming out of date. Now the 32 bit renderer has all the features of the 8 bit renderer and vice versa, for example.

One feature that I added is translucent surface rendering, which now works even in the 8 bit renderer. This will allow for certain effects for every renderer, from simple things such as translucent backgrounds for UI windows and the console to additive blending for things like torch flame. Some examples of alpha blending in the 8 bit software renderer:


The way it works in 8 bit is through the use of translucency tables. Basically the final source palette index and the destination pixel index are fed into a table which contains the closest palette index to the proper blended result. This functionality will allow me to add other blending modes, such as additive, in the future. This also means that colored lighting could be added to the software renderer in the future and other filtering affects, as much as the palette allows anyway.

For the 32-bit renderer, I’ve been working on a color table that will be able to match the 32 bit color lighting/shading results to the original colormap better. This remapping is working, though I have some tweaking to go before it really does the job properly. However I’m getting some pretty positive results for things like the colormap used for underwater and for fog, I’ll show these next time. There is still much more contrast in the 32 bit renderer then the 8 bit renderer though, however the quality is improved in some ways. You can see for yourself in the comparison shots below. Clearly I still have more work to do in this area. :)

Once the 32-bit color map is working properly, I will use the same colormap with the shader based OpenGL renderer as well, allowing for much of the effects afforded by the colormap and the quality and speed of the hardware rendering. This is one example of how the software renderer is helping me improve the hardware rendering as well.

Below are the comparison shots. Notice that there is still more tweaking to be done before it matches, though. But the beginnings are working. :)



In the next post should feature a video and exteriors. After that comes the DaggerXL part of the iterative XL Engine merger release.

16 Responses to “Logics and Rendering”

  • C.H.:

    Love these updates, good to see you work all these things out. :)
    – Looking forward to watching the videos!

  • Edward:

    Thanks for update.

  • Kinasin:

    Looking F’N EPIC! GJ bro.

  • V.C.:

    This is utterly amazing, thanks so much.

  • Krizzen:

    Beyond awesome. I’m also looking forward to the video!

  • SweatyGremlins:

    is look amazing, thanking you for working on such project for all gamers enjoy

  • McSpain:

    Just played DarkXL up to the Nar Shadda-Bug. Great work on an amazing project. Looking forward to updates.

  • Lanus:

    Will you make exteriors to be more realistic? I mean not city blocks, but woods, mountains and lakes. In vanilla daggerfall exteriors are sucks, in earlier releases of DaggerXL exteriors looked better than original, but still empty. Will there any changes? For example, dense forest, roads between cities, signposts or ability to edit exteriors by modules?

    • luciusDXL:

      There are a variety of features planned, though not all of them will be present in the next release:

      *Procedurally generated road system that connects cities and major locations (where it makes sense).
      *Procedurally generated rivers that flow naturally and connect to the ocean.
      *Procedurally generated locations out in the wilderness, ranging from road side taverns, to bridges and ferries to cross the rivers to bandit/monster camps, small farms, ruins and more.

      And there is even more planned for the future beyond that. :) Of course all these features can be disabled depending on how close you want the experience to match the original.

  • chiknbone:

    You know, i have been lurking around here and the old site for years, (visiting several times a week in the hopes of an update) and never posted anything. I’m an avid fan of yours and the tes series. What i really wanted to say today, Is come on! its been two weeks sense the last update! im here every day several times a day when you miss an update, because i feel like you could post it at anytime, so pleeeeaaasseee XD

    • Klasodeth:

      Even under ideal circumstances, Lucius is a very busy man with more real-life obligations than most people. Lucius has been making a lot of progress on the XL Engine in the past few weeks, but his time is sufficiently limited that if he took the time to compose a blog post, it would noticeably cut into the time he can spend on development. For instance, the other day he was working on improved terrain support. If he had written a blog post, that would have taken enough time that his work on that particular feature would have been pushed back to the next time he had free time–which often isn’t the very next day. The forums and especially the IRC channel are much better sources for semi-frequent updates, since they are more informal in nature and don’t require capturing and hosting an assortment of screenshots and then writing detailed posts thoroughly documenting everything that was done and what’s being worked on.

      I’m making an effort to post small updates at the forum when Lucius doesn’t have the time to do so, but that’s not really practical with the blog, since Lucius would still need to have enough involvement providing technical details, screenshots, and videos that delegating the task of updating the blog wouldn’t really save him much time or effort. If more than a couple of weeks goes by without an update at the blog or the forum, feel free to post at the forum. If Lucius isn’t available to provide an update himself, I’ll post a small update to make up for it.

      • chiknbone:

        Thats quite alright! I can just be immensely impatient when im excited (bit of a character flaw on my part…) I know how much work goes into a project like this (having a game three years in development myself,not much progress either, no funding and its a one man endeavor). Bot oh how the wait ever torments me so ;) I shall give that IRC thingamajig a go though i suppose. Thanks for whatever it is you do oh valiant aid of the great and masterful (not to mention incredible busy) lucius.

  • Spot:

    Like chiknbone, I’m more of a lurker than a commenter, but I want to let you know I’m looking forward to the results of your hard work. I really appreciate what you’re doing!

    Best of luck.

  • Edward:

    All is known and understandable, but this is just one of the reasons to think more about getting this project as a opensource project as soon as possible. As opensource more people could join in, and more time could be spend on the developing. A team is more productive then one-man-army ;) . I’ll be checking here for some more time for sure. I’m just a bit concerned that with that development ratio project may die or I can die before I see it. And don’t take me wrong-I don’t have any programming skills and I’m really happy that someone shares my warm feelings towards Daggerfall and decides to make this game more playable again.

Leave a Reply

The XL Engine is and will remain free, donations are purely optional but greatly appreciated.