Interkarma's http://dfworkshop.net is back, and it has some new stuff I want to comment on, yet comments are disabled - therefore I am going to talk about it here darnit!

---

DF Scout. The final versions of this will allow full interactions just like it was Daggerfall, lighting, movement, access, interactions etc. This is quitei nteresting, I didn't realize that the Daggerfall map formats were this well known. It'd be interesting if we could modify these formats - in a sense, create a sortof CS or map editor for Daggerfall.

http://www.dfworkshop.net/wp-content/uploads/2009/04/daggerfall-dungeon.jpg, this out of cell perspective really shows just how bloody large the dungeons in DF were. Fun

This is really interesting, and I thought his would be a nice place to discuss it.

Fun? FUN!? Oh god, the hours it takes to navigate those horrible mazes, lord almighty!

Very cool news B) Scout looks very neat too! ^_^

Probably the best daggerfall related news this year

Thanks for posting this :foodndrink: I can't wait to try it out.

Amazing.

Thanks for your enthusiasm, everyone. I'll stick my head into the thread and reply to the comments so far.


Sorry mate, I don't plan on opening forums or comments. From past experience they add a lot of moderation overhead. Sidestepping this is in line with my goal of "keep it simple". I know lots of people would volunteer to moderate on my behalf, but then I'd have to coordinate with moderators. I just don't have that much time to spare. You can always reach me via email, or PM on this forum.


SubProperty did an amazing job of pulling apart the RDB (dungeon) block format, I can't take much credit there. Objects like levers and platforms have an action record defining transforms (rotation and translation) over time. This will cover many of the interactions, but there are still a great many blanks in the file formats. Building a read-only world viewer is an easier task because you can focus on the knowns to build a fun tool, and just ignore the unknowns. Creating a fan-made Daggerfall CS, while feasible in concept, would have to face those unknowns head on. I'm not saying it's impossible, but building a CS would be very challenging and is not one of my objectives.

For anyone unfamiliar with my older tools, DF Scout just reads the contents of your Daggerfall CD and renders things for you to explore. It's not a remake, or an editor, or a cure for halitosis. It's just a bit of fun to see all those places on a hi-res display. Oh, and you need to own a copy of Daggerfall. I don't distribute any assets or files from the game with my programs.

The first release of DF Scout is going to be pretty much what you see now, with as few bugs as possible. I'll add new features in bits in pieces as my schedule allows. This makes the project realistic to manage and allows me to add new layers of effects (like lighting) over time rather than get bogged down at the start.

If anyone has questions, I'll do my best to answer them.

Not that there's all that much Daggerfall news these days anyway

But Daggerfall Scout looks really nice. :goodjob:

What can be done to help? I'd like to do anything I could to help out with this awesome project, seeing as it may aswell be the last Daggerfall Project (or atleast the last for a very long time).

Wonderful news! I missed this website heavily. DFScout looks like it's coming along quite nicely. I had no idea this much progress had been made in deciphering the inner workings of the game. This is a testament to the endless devotion to this great game and its undying community.

I look forward to more news in the months to come.

so youa re back working on your remake? really? please? :singlehopefultear:

Hi TOYB. Most of the initial work on DF Scout is already done. Right now I'm dealing with making it as bug free as possible and putting in as many features as I can before handing it over to you guys to play with. The best help I can get is positive feedback and enthusiasm. Constructive criticism is good too. You'll all be able to help with that once it's available. Thanks for the offer mate, I do appreciate it.


Hi Luzur. Not quite mate. The Daggerfall Project is really more than I could take on and I've moved back to building exploring tools. However, DF Scout uses the world-building code from my abandoned remake, and I hope it's going to be a fun tool to play with. Unlike my previous programs, this one is all about exploring places in detail. Chiefly, it's an example of how pretty Daggerfall can look on modern hardware, even without upgrading the low-poly meshes and low-res textures.

Some small degrees of Daggerfall "location" editing can already be done. Examples at http://andux.svatopluk.com/.

I think Andrew Polis of ANDYFALL fame may know a thing or too as well as the mod allegedly added The Angry Porcupine to a town. I don't know the extent of this - whether he actually put a building in a town or if he simply changed the name of a pre-existing inn. Still, it'd be amazing if Daggerfall's limits could be pushed further with potential world creation. Still, that's a long-term goal. One thing rather interesting is that some of the data files in the game show placeholder sprites saying things such as "RANDOM MONSTER", like you'd find as indicators in an editor. Probably what Bethesda once used.

Will Freddo STICKY this thread?? Please? *heh heh*

He actually patched fall.exe. All generic names of shops, taverns, etc. are hardcoded in fall.exe.

The problem with adding new towns or buildings to Daggerfall is that the file formats are not fully understood yet.

There's a solution for that. If it was possible to extract all known Daggerfall game data and convert it to xml files and known data formats for images, sounds and 3d objects, then someone could make a replacement Daggerfall engine. All of this would be legal because players still have to own a copy of Daggerfall to extract the data.

Plugging a scripting engine like Lua to Daggerfall Scout, would be a way for other people to help creating exporter scripts, similar to how Blender has exporters in Python.

This is definitely the best approach, and it was the one I took with The Daggerfall Project. My old tools converted directly in memory to the display engine. With TDP this was taking too long at runtime, so I put in a pre-conversion step to build a cache from the Daggerfall CD.

Daggerfall Scout uses this concept as well. The first time you run it, you need to insert your Daggerfall CD and build a personal cache. Low-level media like images are saved as standard bitmaps, and high-level constructs (like blocks and maps) are a perfect fit for XML. This has the added benefit of being readable by Humans as well as computers. I've tried to keep the XML elements and attributes straight-forward and descriptive.

As for scripting, I would be interested to see what people do with DF Scout after release. I'm using a custom control (a .Net assembly that can be dropped in to another program) to encapsulate the cache-aware graphics engine. The cache builder is likewise a .Net assembly. So while all the underlying stuff is written in C++, you can consume the builder and renderer in C#, VB, etc. It would be possible to do this for other languages as well, but someone would have to build appropriate wrappers. That won't be me, I have no plans beyond DF Scout.

Edit: I've posted some information on my site demonstrating how the cache is built by DF Scout.

Wow, this is awesome! oo:

Too bad I know nothing of scripting, otherwise I'd pounce on this and try to 'remake' Daggerfall on the engine you've got there.

Amazing, though, that the engine is such a mystery, even after all these years. What makes it tick? The world may never know. :mellow:

Though remaking Daggerfall in it's entirity would be the pinnacle of awesome, it's not something anyone should take on lightly, there's just too much that would need to be done.



I'll tell you: Cardboard nailed together with plastic, Adamantium and ancient forgotten bits and pieces, running on a mix of magic, (vin) diesel, and http://en.wikipedia.org/wiki/Algae_fuel.

Awesome work, Interkarma. I'm glad I can see DF dungeons in all their glory, without the ~100-foot view distance. It really helps put them into perspective in a way that the map was never able to.

I personally always wanted some sort of remake for Daggerfall, and even considered a partial-remake as a mod for Oblivion. (that'd include only a couple cities and dungeons) Of course, it's a ludicrously ambitious undertaking...

Yeah, there's that; I figured they were in there, since I couldn't find them elsewhere.


That, and the fact that due to the space-saving procedural style of the game, (done to make such large-scale maps possible with only megabytes of space) adding a single building would require creating a whole new block to have the building, and THEN going in and replacing an existing block with the new one.

I do believe my head just asploded reading that..

Last time I began to consider anything along these lines was back in the late 70's. I came across a couple of pretty cool algorithms that each generated random 2D mazes, one of which further translated a resulting maze into 3D hallways (presented in BASIC). I decided I was going to render one of these algorithms in Assembly/Machine Language and write a game.. *HAH!* That project lasted about a week once I got to it..

I'm sure there are many more qualified who can actually do it, though..

The site blog has been updated again. This time with town lights, town decorations and it looks like background skies are on too.

http://www.dfworkshop.net

Very cool. Can't wait to see the flickering light effects.

Hey mate Just to clarify, those latest screenies are from Daggerfall running in DOSBox. I was changing texture data in the game to see how it placed lights, and sounds for animal flats. DF Scout isn't too far off that stage however. The only thing I'm missing is the sky and flickering light effects, all the other town details are in.

I'm playing with lighting now, trying to find an efficient per-pixel technique that will work with dozens of point lights around a big city. This has been challenging, but I'm a a shader novice. Hopefully this is something I can achieve without compromising somewhere else, but we'll have to wait and see.

Oh my mistake then. I'm glad to see you are making progresses in uncovering the remaining secrets of Daggerfall data.

As for rendering many per-pixel lights in a city, you have several options:

* Render each light or group of lights as an additional pass. This is geometry heavy, but with simpler geometry this may not be a big issue. Of course only rendering geometry the lights affect helps alot. Another optimization would be to use scissor or stencil to mask areas in screenspace that the light could affect, thus limiting the overdraw.

* Full on deferred renderer - probably not the best choice for lower end hardware due to memory and bandwidth issues. However with moderate to high-end hardware you could render a lot of lights - on the order of thousands depending on light shader complexity and light overlap.

* http://levelofdetail.wordpress.com/2008/01/24/light-indexed-deferred-rendering/ - instead of storing full g-buffers, you store per-pixel light indices. As long as you have less then 256 lights overlapping each pixel this works well. Its an interesting comprimise between forward and fully deferred rendering.

If performance is really an issue, given the simplicity of the geometry, simply generate the minimum set of geometry for each light as its created and cache it (the individual triangles). Then when rendering each light, you only render that minimum set in the light pass (with the possible addition of scissoring or stencil). This requires some processing but you should be able to do it fast enough to do it on load and cache it. If you keep a global light cache you can keep the memory bounded, removing unused geometry caches as needed for new data.

If that's still too much of a fillrate drain (I honestly don't think it will be) then clip the geometry to the light bounds on the CPU when caching it and apply a small z bias (since the polygons will be different sized, thus generating slightly different z values). If you do this, I'd clip it the polygons to a tight fitting box or other simple shape in order to keep the number of planes down.

With properly bounded light geometry, you should be able to draw hundreds of lights. With a deferred renderer you could draw thousands. So I trust you'll be able to make it work without compromises.


Oh by the way, thanks for all the work deciphering Daggerfall's formats.