News
Not According to Plan 2011-06-25 05:20:34
After developing the specification for the new map format for Wolfenstein 3D my plan was to have a working implementation at the beginning of this month. Well at least a partial implementation. Well as it turns out there wasn't really a way to simply augment the new code with the old so it's turning out to be a whole lot more work than expected (I was thinking it would take me a week at most). For the end user this is actually good news since not only will I have a nearly complete implementation at the start, but other systems which I planed on working on later will be done. For example it'll have the ability to handle custom actors (monsters, decorations, etc) much sooner than expected. Once that's done I'll be able to completely dump the old resource code which means the palette issues will be sorted out.
I believe this will also solve most of the issues I have with supporting Spear of Destiny as well. I suppose this means another way to look at things in the first public release of ECWolf may be happening sooner than expected. In the mean time, my planned work on Doomseeker and ACC++ is on hold until I get this major task done.
BitOwl Application Suite 2 Released 2011-05-30 07:09:36
With over three years in development BitOwl Application Suite 2.0 has been released! While it lacks the poll script from BOAS 1.x this release brings about a much more consistent and stable code base (and probably with it much more security). Because of this I am immediately ending support for the 1.x series. As usual the release can be found on the project page.
While my source repository only goes back to three years ago I'm sure it has been longer than that due to the size of the initial commit. That said the project represent mainly the needs of my high school's newspaper where most of the progress in the last two years has happened. In fact I wouldn't be surprised if most of the code from the initial commit has changed during this period due to various rewrites. Overall the improved code quality means I finally have a product that I should be able to support for many years where the previous versions pretty much broke if you weren't using my exact server settings and PHP version.
Also, I moved the BOAS source repository over to Mercurial so that can be found on Bitbucket now.
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.
« 1 2 …10 11 12 13 14 …22 23 »