After some thought, I have decided to release the full source code for the XL Engine and game implementations with the Beta build. In order to start this process I have created a Git Hub public repository and have started the process of pushing up the code.
That said, however, there are some surprises in store for the release so I will not be uploading all of the code until the Beta is published. The repository will be incomplete for now but that will be rectified for the release. Also this version of the XL Engine was rebuilt recently and so it does not contain all of the functionality past builds have had. However I am moving over the code and refactoring it to fit in the new engine as I need it but until then you will see holes. No game specific functionality is pushed and the code will not build as-is. Again this will be corrected for the release – this is just getting the ball rolling.
Finally some of the code is currently in a very rough state, this is a work in progress. I will not be taking pull requests at this time and this will be a quickly moving target, any part of the code can be radically restructured at any time. So if you have any ideas, like porting to other platforms, please wait until the Beta release and the repository is complete.
I have not upload a license yet, there are still some details to work out.
Here is the GitHub link: github.com/luciusDXL/XL-Engine
This post will discuss some of the recent progress made towards the Beta. For now I will focus on the UI and Engine and talk about the games themselves in a future post.
I have been using one of the games to ensure that the engine provides all of the necessary services and to implement the core features of the engine. When you start the application, by default, a UI comes up where you can select the game to play, change video settings, setup controls and so forth. While most of the UI is only semi-functioning and placeholder – the settings are stored in text based ini files which can also be edited outside of the application. Of course everything will be editable by the UI for the release. It is possible to launch a game directly and exit immediately but even when this is the case it is always possible to bring up the UI, change settings and switch games. This is useful if you wish to play a single game or to create shortcuts and bypass the UI.
Each supported game is implemented as a dynamic library (DLL on Windows) which can be loaded and unloaded dynamically. You can even pause the game at any time to bring back the UI and change settings as desired or switch games. The game is rendered into a virtual screen which can run at a different resolution then the window – right now a multiple of 320×200 (16:10 in 4:3) but normal 4:3 and widescreen modes will be supported. Proper aspect ratio is automatically maintained with letter/pillar boxing, though stretch to fit will be an option.
I am currently re-working the sound support in order to provide all the necessary features for the variety of games but otherwise all of the engine services needed to support the games is complete – input, graphics, file manipulation, etc.. The UI still needs work but is functional enough for testing.
First Look at the UI
Below is a first look at the UI, as you can see you can click on a game to start playing or click on various icons to bring up settings menus (video, controls, engine settings, game settings and so forth). The aforementioned menus are incomplete, placeholder and not shown but the main view works as intended. When pausing a game a thumbnail view of the game is shown in the UI.
Even the versioning has been retrofitted – it is now structured as MajorVersion.MinorVersion.Build and given a name though only major changes will warrant new names. The initial releases will simply be “Beta.” The build version is now incremented automatically, so even if there are two releases made in quick succession, the version order is always clear. Obviously I started the automatic build number very recently (and even now its out of date, the current version is 0.2.161).
I still have a lot of work to do before the release but I now have a strong foundation to build on with a fully featured engine and a solid build process – no more copying around files and manually updating build numbers, etc.. So now I can focus on finishing the game support for the Beta.
I have not updated this site and blog in quite some time. However, despite appearances, the project is not dead. For a variety of reasons the project had to be put on hold until the beginning of next year. Despite this, there has been some progress made – which I will discuss in detail in the next few months.
Next I would like to clarify some things. Interkarma has made large strides in his own Daggerfall work (see http://www.dfworkshop.net/) which begs the question – what about DaggerXL? Is there any point? And what about Dark Forces or Blood – have they been forgotten?
I will start by being as clear as possible:
*The XL Engine is not dead and will resume with regular work, updates and builds within the next few months – by the start of the new year.
*DaggerXL will continue, in no way reduced or affected negatively by Interkarma’s excellent work. There are still several reasons for DaggerXL to exist – improved Modding support, including support for existing mods; source-port accurate to the original game, with optional extended features while properly supporting modern systems – including support for software rendering; custom engine designed for high performance even on low-end systems; enhanced features such as extreme view distances (hundreds of km), enhanced texture filtering, enhanced lighting and shadows, etc.
*I have been building tools and other work that will allow me to release source-port accurate support for Dark Forces and Blood at the same time as Daggerfall early in the new year. They too will support software rendering as well as enhanced features. Outlaws has not been forgotten but has been put on hold until a later time. The XL Engine will even allow you to play with your existing save games.
*The XL Engine will be easier to use and setup, automatically setting up the supported games that you have on your system in most cases – easily supporting Steam and GoG versions of the games. It will feature a streamlined interface for adjusting features that the original games did not support (such as adjusting resolution, rendering quality, etc.), rather then implementing game specific interfaces as seen in previous releases of DarkXL or DaggerXL.
*There will be a single entry point – xlengine.exe – with the supported games being implemented as dynamic libraries, allowing for easy addition of new projects in the future. Of course you will be able to make shortcuts to specific games if you want. No launcher, no separate executables.
*Linux and OS X support is still planned but will not be available for the first Beta release.
The first Beta build, coming early in the new year, will feature support for Daggerfall, Dark Forces and Blood. However the initial release will be limited to the software renderer with only limited enhanced features (although basic stuff like higher resolutions will be supported). The XL Engine will still require a GPU with at least OpenGL 1.5 support for compositing and UI (any cards released within the last decade should work, assuming it supports any other games). GPU rendering support will follow shortly, with all the basic features you would expect. However the hardware renderer will require a GPU that supports at least OpenGL 2.0 , though higher end GPUs will be required for some extended features such as extreme view distance support (which will not be available in the initial releases). If you do not have a good enough GPU, you will always be able to fallback to the software renderer – assuming you have the aforementioned OpenGL 1.5 or better GPU.
What about source code access? I plan on releasing a few builds before I release the source code – unfortunately I’m too picky about the code for my own good – but I do plan on opening up read-only access to the repository (with the option to submit patches of course, if you are so inclined) within the first quarter of the year.
In the past DarkXL and DaggerXL releases, both games had custom “XL” title screens. These served multiple purposes: a place to display the version number – a very useful piece of information to know for a variety of reasons, a place for extra XL specific options such as Mods and multiplayer setup and as a nice extra element of polish.
However as of the next release you’ll need to launch the games using the Launcher, which could already be done in the previous build as well. The Launcher is where you’ll be able to see the version number and can setup Mods or other XL specific features. To that end I think the XL specific title screens have served their purpose but are no longer needed. Starting from the next build when a game is launched the game menus will be displayed immediately, just like in the vanilla versions.
There are several reasons for this change, other then simply not needing the title screens any longer:
* Adding new games no longer requires new custom art work.
* Later I plan on adding the ability to switch between games without shutting down the XL Engine.
* Once you start a game, focus is entirely on the game itself and not on the XL Engine, unless XL Engine specific features are used such as the console or XL Engine settings menus.
* A unified XL Engine interface is presented, no longer being game-specific.
In addition to the Title Screen change, there will also be a change to the way versioning is done. Instead of having a version per game, there will be a global XL Engine version. Whenever the support for a given game is improved the global version will be modified as well. Of course how complete support is for a given game will still be tracked but only one version number needs to be used for bug or feature tracking.