Blzut3's Weblog

Weblog ECWolf ECWolf Wiki

Universal Wolfenstein 3D Map Format 2011-05-07 05:50:54

So recently I've been discussing a new map format for Wolfenstein 3D with Adam Biser (WDC/WinWolf3D). We have reached an agreement on the details of the format, which you can read on Google docs. It's not really a formal specification, but it will do for now.

For those who aren't technically inclined here is an overview of the features offered by the format. First off it's loosely based off the textual map format for Doom known as Universal Doom Map Format (UDMF). As a result the format is extremely flexible and, most importantly, I can add new features later without any issues. Even though it is a text format, there is no expectation that anyone will be writing a map in notepad or anything like that.

Those who design maps for Wolf 3D will be happy to hear that the format isn't going to make map editing significantly more complex than it already it. At its core, the format still supports the idea of planes of data which act as canvas which can be "painted." The big difference now is that the set of textures is defined on the map by name instead of a global index. This makes maps a whole lot more portable than before. The editor will, however, likely hide most of the details in defining the palettes for textures, flats, and sound zones (previously floor codes). While technically you could give each wall a unique texture I highly doubt this will be common practice, and the format has been designed to take this into account.

One thing the format does away with is special floor codes. A secret exit will now be defined by assigning a secret exit trigger to a wall. "Deaf" enemies are defined by simply flagging them as such. While the format will open many possibilities for triggers (you can define a secret push wall that can only be opened from one side for example), an editor will likely automatically handle common trigger assignments, such as doors, in order to keep things as simple as they are now.

It is important to remember though that neither WDC or ECWolf will be able to support the entirety of the new format in the beginning. While the format allows things to be placed independently on the grid, Adam tells me that this would be nearly impossible to support with WDC in its current state. Probably more obviously, the format is designed assuming the possibility of stacking planes. This is a long term goal for ECWolf, but obviously the map format needs to be ready for it. At this time maps are limited to one plane (a plane in the new format is a Z layer).

ECWolf will be forcing the new map format for all mods distributed in the new package formats (WAD, PK3, etc). Old maps will be converted on the fly. This is particularly necessary since thing numbers will differ between the two formats. I'll probably be starting work on this at the beginning of June.

On a completely off topic note, since I'm writing here, BitOwl Application Suit 2.0 should be finally releasing soon. All I think I need to do is run it through a final round of testing and get the thing uploaded!

Wolfenstein 2011-04-03 20:23:00

I recently started work on resolving symbols (variables, functions, etc) in my ACS compiler. One of the things I determined was that ACC++ was going to treat any variable type as a object. This will allow for the definition of custom primitive types, which will make handling fixed point variables much easier. There will still be a difference between normal classes and primitives, namely primitives will not have member variables. (Which should be expected since they would be represented by a single value.) So in essence you'll be able to define custom operators and functions without having the overhead of going through allocating room on the heap. It also means I have to build much less logic into the compiler, instead moving most of the code into the optimization stage of the assembler. I hope that this summer I can get the work needed to get ACC++ compiling done, but I can't make any guarantees.

I didn't get very far with that though as my attention was diverted over to the ECWolf project. I completed the request for aspect ratio correction code. ECWolf now renders with rectangular pixels as well as proper support for wide screen. This only applies to the game renderer, as much more work is required to correct the 2D elements. Even if I tried I would probably end up doing twice the amount of work required, which brings me to my next point.

I've imported the entirety of ZDoom's texture loading code into ECWolf along with everything it depends on (palette, translations, random number generator, etc). As a result it is now able to load any graphic format that ZDoom can, minus the graphics for the build engine since that would have brought in more dependencies and would probably never get used (at least it should never get used). At this point a few other things are disabled in order to get things compiling, for example the animation system is not hooked into the game yet, but there's no reason these things can't be enabled with a little bit of work. I can't really show anything here in screen shots since at this point it looks unimpressive since it's still using a mix of the old and new texture system (so there are palette conflicts), and besides once everything is done you shouldn't notice anything different unless you're making mods for the game.

Once that is done, which implies quite a bit since I need to move all graphic drawing to a name based system instead of an indexed one, all I need to do is figure out a new map format for the game (or find some way to adapt the existing one since I have to support it any ways). Once the engine doesn't depend on the non-user friendly file formats I'll be able to do a stable release of the source port within about a year which will finally support Spear of Destiny as well. In regards to Wolfenstein 3D, I'm only going to support one version which means I need to find a way to generate patch data. I'm still not sure if I should support the 1.4 with or without the "Read This" option, the former is probably more favorable to mod authors, the latter to players as I'm sure that's the one distributed through steam.

And for anyone wondering about my other projects such as ZDoom's Doom 64 branch. Yes I'm still planning to finish them.

The Life of a Completist 2011-02-18 03:51:41

Time for a rant that's not about Apple: I like to consider myself a completist. Having recently gotten into Front Line Assembly I've feel into a compulsive need to collect every track put out by them... and then I discovered all of their side projects. But that in itself is not worth talking about. However, re-releases are something to discuss. Why do record labels do them they way they do? Particularly I'm looking at Cleopatra which seems to be unable to do re-releases without changing something in the track list in some way.

What annoys me the most, however, is when the label decides to remove tracks from the re-release. If this is due to licensing issues then fine, but at the very least don't make my life difficult by adding additional tracks to the release. This can be seen on Delerium's Faces, Forms, and Illusions album and their Syrophenikan album. Fortunately the former's bonus tracks can be found on a compilation disc, but in order to collect every song from Delerium I would need to get the latter album twice. It certainly doesn't help sources sometimes don't very clearly mark which tracks are on what releases. Lets not forget that sellers on sites like Amazon, Half, and even to a lesser extent eBay are usually un-knowledgeable about these quirks and thus make it difficult to find the particular release I need.

And then there are re-releases that are done for the purpose of transferring old recordings to CD. In the case of FLA, there are two CD releases that are missing one track from their source material. I can't really say much about the re-release of their Total Terror demo missing a track, but there was no excuse for the re-releases of Corrosion and Disorder. Especially when there is a re-re-release which drops yet another track, but adds a few bonus tracks. So basically I'm stuck buying the vinyl release of Corrosion and maybe even picking up both Convergence and Corroded Disorder.

Finally, what is up with all the regional stuff. Nettwerk seems to love doing this and is fortunately where my completism comes to an end. (I have no interest in tracking down 20 different regional releases of the same thing for some obscure remix. In fact I'm more looking for exclusive B-sides on the singles any ways.) Of course it's just as bad when the availability of physical copies is limited by the region (fortunately Dependent has free shipping world wide).

Also limited edition releases are also annoying, but much less so.

Looking Back 2011-01-17 21:47:44

Recently there was a bit of interest in my old Overload/Harvester mods for Skulltag. It's always a bit interesting looking back on old projects. Not so much because the code was bad on those projects, but rather due to the vast amount of new features available in Skulltag. As such a new release of the Overload/Harvester mods may be in order within the coming months. There are also some changes planned that will make them less of a port of the Quake 3 Team Arena mode, but will hopefully improve game play a bit. (Particularly on Overload.) Something that will be coming out of that soon is a DesignatedTeam property for DECORATE. This will allow any actor to be assigned to a team and have friendly fire calculations apply to them. What's interesting though is I had requested this many years ago and have actually found it to be quite easy to implement. Odd that it got shot down.

My Descent Maximum lets play should be continuing shortly as well. I got an S-Video cables and a splitter for Christmas and recently worked out some issues with it. Namely the S-Video port on my projector being too loose to hold the splitter, but fortunately 25ft was just enough to reach the AV receiver. So now it's just a matter of rehearsing the levels and remembering how I did the recordings.

Also I moved ECWolf's source repository over to Bitbucket. This shall serve as my first experience in maintaining a Mercurial repository and if everything goes well (and I'm sure it will) then I'll probably be converting more projects over as well.

« 1 29 10 11 12 1320 21 »


© 2004-2018 Braden "Blzut3" Obrzut