May 4, 2011
April 22, 2011
Edit – the site is back online faster then I expected. When I posted this I expected extended down-time.
This post is not directly related to DaggerXL but rather to the new XL Engine site. Since it is currently offline, I’m posting this on the blogs and old forums so people know what’s going on.
The new XL Engine site is down temporarily and will probably be down all of today and maybe even tomorrow. This is only a temporary issue that I’m attempting to get solved right now. Please be patient, the site will be back up as soon as possible.
Thanks for your patience.
April 17, 2011
As previously discussed, I’ve moved to a centralized XL Engine site and blog. So from now on I will be linking posts from the new blog from here, until everything is moved over.
April 15, 2011
The DaggerXL project will soon be merged together with DarkXL as the XL Engine. While the merge itself hasn’t begun yet (see the previous post for a time table), I have begun to consolidate the communities and sites that are dealing with these projects. The forums for all these projects will now be here: xlengine.com/forums. The new site, xlengine.com will now host a new blog that will cover all the projects and the site will host news and downloads when it’s setup. I will be setting things up in the next week, after which point I’ll remove downloads from these blogs. This will also be the last blog post made specifically for this blog, though I will still put up posts here with links to the new blog so returning visitors aren’t left behind. To that end the blogs will remain operational for a while yet.
So please visit the new forums to get acquainted with them and register if you like. The site/blog isn’t fully setup yet, but as I said that will be happening within the next week.
The good news is that the new site is a properly hosted site, meaning that I have more control and things can be centralized (site, blog, forum and file hosting all on that site). This also means that things like a wiki or other features can be added later.
April 13, 2011
Version 0.20 Update
I’ll start by saying that the 0.20 version is still on track for release and will be probably come out this weekend. I’m going to be busy for the rest of the week – which is the reason for the delay, but it’s very close to completion. All the weapon types are in and working, including the different materials (with bonuses and weight changes) – with the exception of bows, which will come later once I work on the ranged combat and spells. Currently I’m working on getting all the different armor types and materials working as well.
Once version 0.20 is released, the plan is to spend some time getting the Beta for DarkXL done, which is where the changes below come in.
I’ve been thinking about this, off and on, for a while now. But with the DarkXL Beta coming up this is basically my “last” good chance to get this done if it’s going to be done at all. I plan on merging the DaggerXL and DarkXL projects into one engine, the XL Engine. But the engine rendering and many other aspects are different, you may say – and it’s true. But there is a lot of code that can and should be shared between the projects. For example, much of the software renderer and hardware driver abstraction layers. The in-game console. The sound system. The midi playback system. The window/OS management and input systems, the scripting system. UI scripting ability, AI scripting, and so on. As I start supporting different OS’s and rendering APIs, this will save a lot of duplicate work. I’ve been considering, way down the road – post DaggerXL beta if it happens – adding ArenaXL as a project supported by DaggerXL. With the shared code base, I can use a lot of the same code that DarkXL will use for it’s sector rendering, for example.
There are other benefits: releases that work on technology now benefit all projects, no need to “port” from one to the other. As I brushed upon before, when I add support for other platforms – I add support for all the projects. When I make releases, it will be easy to make improvements for multiple games simultaneously. Some tools and mod support can be shared across projects (for example adding the DaggerXL texture replacers support to DarkXL). And finally I can merge the communities under a single engine/site/forum so that I can be active on all the projects and not just one at a time.
So what happens to all the different sites and forums that currently exist?
DF-21 will remain a resource for Dark Forces related files and forums. However I plan on setting up a new forum, for the XL Engine, and migrate all the projects to that forum. The DaggerXL forum will remain open for quite some time, but once I get things moving I will probably focus on posting over there and this one will slowly fade away. ( As sad as that is ) For the time being, I’ll keep the blogs around but I’ll probably start putting together an XL Engine blog and mirror posts across the others. As support for more games is added in the future, this will be a more scalable solution as well.
Does this change future plans for DaggerXL, modding support or other DaggerXL specific plans?
No. Full modding support is still planned, though many of the tools may be shared with DarkXL modding, BloodXL modding and so on.
Isn’t DarkXL a sector engine and DaggerXL a true 3D polygon engine? Aren’t these incompatible?
It is true that they are different but both can exist in the same engine. DarkXL actually supports rendering models already, they are used in Dark Forces for things like bridges, Tie Fighters, The Moldy Crow and so on. The way the level geometry is rendered is indeed much different, but the engine will be able to support both sector and “free-form” polygonal geometry. This has potential implications for modding, though those will be explored later. Things like scene traversal and level geometry rendering are different, but this won’t be the first engine to support multiple methods of scene traversal and rendering. A lot of the surrounding code will still be shared, so the savings offset the cost.
So here is my plan:
1) Release version 0.20 of DaggerXL.
2) Finish the DarkXL Beta.
3) Merge DaggerXL and DarkXL under the new XL Engine, where DaggerXL and DarkXL are two games supported by the engine.
4+) Continue to work on the projects as I have been, but with everything together it’ll much easier for me to keep everything going rather then letting one or another stagnate.
The order of 2 and 3 may change. My gut instinct is to get the merge done before the Beta but completing the Beta first gets a long overdue build out sooner…, but that is beyond the scope of this topic.
Finally, I have to ask the community: Are you guys willing to do this? To move to new forums, to intermingle with Dark Forces, Outlaws and Blood fans? Of course each game gets it’s own sub-forum so it’s not complete anarchy, but you get the idea. I know it’s sudden for you guys, but it’s been on my mind for a while now. Ultimately I think this change would be an improvement for all the projects – DaggerXL included – but I would appreciate it if you guys let me know what you think.
April 3, 2011
In this post I’ll talk more about the upcoming software renderer including progress, performance and future plans. Note that this work is happening in parallel to the version 0.20 support, the software renderer won’t be available until after the next build.
As I’ve been working on the next release, I occasionally fiddle with the software renderer. Currently I’m writing it in a separate test app, to avoid integration issues until after version 0.20 is released. Until recently, screenshots would be really boring since it was all boilerplate code but I’ll go ahead and show the first screenshot now:
Statistics for images shown:
- 32 bit renderer (8 bit will also be supported with all the palette effects)
- Perspective correct texturing
- 16 bit Z-Buffer (will probably be upgraded 32 bit)
- Sub-pixel/sub-texel accuracy (no wobbling edges or textures)
- Per polygon color, used for lighting (supports RGB, only intensity shown here)
- Z-Fogging using a fog table.
And of course it supports 2D blits (including arbitrary scaling):
Currently performance isn’t where I want it to be for multiple reasons:
- It’s using GDI for the final blit which can be slow. Obviously it should use DirectDraw and/or Direct 3D when available (just for the final blit though).
- The bottleneck is the actual rasterization, in the future this will be optimized using SSE/SSE2 when available. However this won’t occur until it has all the base features.
- SSE/SSE2 optimizations for other parts of the pipeline as needed (transform, clipping, etc.).
Some of the additional features required before integration (post-0.20):
- Dynamic lights (using the proper radial attenuation).
- Mipmapping (probably with mip selection done per scanline).
- Various pipeline improvements, backface culling and so on.
Finally I plan on adding hierarchical z-buffer based occlusion culling – at the batch, polygon and maybe even span level in order to reduce overdraw to near zero. This, combined with an optimized rasterizer, should allow the software renderer to run at very high resolutions on modern CPUs. This is more practical with software rendering (or at least simpler to get right) due to the lack of latency and also the fact that it handles small batches very well, which means that rendering can be sorted from front to back at a finer granularity without hurting batch performance or state switching performance.
Ultimately the goal is 60fps at 1024×768 on a 1 GHz CPU. Once the final blit is fixed (i.e. not taking 11ms at 1680×1050 because of GDI), I’m close to that goal now but still have to make it faster using the above methods in order to also have gameplay too (i.e. collision detection, AI, combat, etc.).
SSE will only be used when available, potentially widening the CPU support if you run at low resolutions (i.e. 320×200 or 640×480).
Hopefully this will allow anyone with a semi-modern computer (i.e. a computer purchased within the last 11 years) to play DaggerXL at good framerates, at least with the basic feature set. In addition the hardware renderer will go through another round of optimizations, as well as general program speed improvements and loading improvements upon start up.