WadAuthor Progress Update #2

[Phileosophos]

One week ago today I posted a progress update regarding the ongoing work on WadAuthor. Because I’ve received such a positive response and useful feedback, this is something I’m going to try to remember to do on a weekly basis. At least, I’ll try to remember to do so as long as there is any news worth reporting (grin).

The Dragon is Slain
Having said that, then, there are only minimal confirmed changes in place as of today, though they are surely quite important. When last I wrote, I had taken the first steps toward slaying a dragon from WadAuthor’s past, namely, its zoom limitations. I said then that scrolling was still broken, and oh how it was broken! Not surprisingly lots of other things were broken as well: drag and drop, keyboard placement of new items, panning, rubber-band selection, etc. The biggest news to report for today, I suppose, is that all such problems I could find are fixed. WadAuthor today seems as functional as it was when I first began ripping out the awful old zooming code. The big difference, of course, is that I can zoom in until I get positively dizzy expecting my head to hit the map floor, and that’s a plus in my book. I think I can safely say that the zoom-dragon is finally dead!

Research
Now that I have fixed the zoom and added support for multiple maps, which were previously the two greatest limitations of WadAuthor, I have been working on brand new stuff. Some of it involves code I wrote years ago but never got around to developing more fully while some of it involves entirely new classes. The two items foremost on my research agenda at present are (1) lump management and (2) image browsing.

WadAuthor has never really managed lumps. The WadAuthor Value Pack, a collection of utilities made available to registered users, provides limited features, but WadAuthor doesn’t integrate these features within its own user interface. At least, it didn’t a week ago (grin). I’m not going to promise that this feature will ever see the light of day, but the work at present is promising. I have added code to my development build to let me choose to open maps within a wadfile or work directly with the resources (i.e., lumps).

If one chooses to work with lumps, then the view is essentially much as a detailed file listing in Windows Explorer. The direction I’m headed right now involves supporting all the basic operations one might want with lumps: adding new lumps, deleting lumps, renaming lumps, etc. I’m not sure yet whether these operations will be immediate or whether they will be queued and then applied to the file at time of save. The former is simpler to code, but I could see how making lots of little changes to a large wadfile could take an enormous amount of time if they are applied singly. I prefer the latter approach, but I don’t yet have a feel for the development cost.

Note well: user feedback on how this ought to work would be very helpful.

Regarding image browsing, I always thought WadAuthor’s image handling was second to none. I still think this is the case in terms of speed and ease of use, but I must admit that a user suggestion on the board caught my eye. I forget who it was, but someone pointed out that one could see only a handful of images in the image browser dialog box. Since reading that suggestion, I’ve found the limit kind of annoying myself, so I’ve been researching possible solutions.

Step one was to make the dialog box fully resizable. This code is done, tested and seems to be working just fine. The dialog box was sized originally for systems running at a resolution of 640 x 480. On my desktop, which I typically keep at 1280 x 1024, the dialog is a bit small to say the least. With the new resizing code in place, however, I can expand it to fill the whole screen. Unfortunately, the image browser does not tile graphics, so it doesn’t matter that much how big I make it. I still get maybe eight or nine images at most before I hit the vertical limit. Thus, I’m working on a replacement for the image display control. If I can get past some technical hurdles, the new code will allow display of a much greater number of images by tiling them to make best use of the available space. I don’t know yet whether a zoom setting will be included or not. I can say this much with confidence: the image browser dialog will be resizable. It might also provide a better display than ever previously available in WadAuthor.

Well, that’s it for now. I’ve spent very little time on the code base this week because I’ve had all kinds of other projects clogging up my to-do list. Note to self: never give users the ability to delete records in a database system because (1) they will screw up and delete what ought not be deleted, and (2) they will expect you to fix it. Suffice it to say that WadAuthor has been suffering as the result of mistakes made by users of other software I have written. I have hope that the upcoming week will be better, however, if only I can dig myself out of database hell. Until then, stay tuned for more WadAuthor updates and keep the feedback coming!

[Guest D|RE]

Thank you Mr. Williston for all your hard work. It is not under appriciated.

[Phileosophos]

You're welcome. It's actually kind of fun to work with this code base again after so many years. I just got a first rough version of my new graphics list working in the image browsing dialog box, and it looks sweet. The zooming worked the first time out--I guess I really did learn something from my problems with the main view. If I can get the scrolling behavior nailed down and add all the typical UI crap to the graphical list view, WadAuthor is going to have some sweet image browsing.

[Wildman]

Great news. It would be awesome to have lump management as well. The gui sounds perfect. As far as manipulating the lumps singly or at once, I personally don't have a preference. Wintex does it singly and DeepSea does it all at once and the end result seems to be the same really. I personally don't have a perference. Go with whatever is easy.

Thanks for the update.

[ReX]

Thanks for the update. Just a couple of comments:

1. Lump management -- excellent idea to incorporate it. When you say "making lots of little changes to a large wadfile could take an enormous amount of time if they are applied singly" do you mean the amount of time to save/compile the changes to the wad? In your description you implied that there would be a lump management menu, within which the changes would be made. Perhaps the changes to the wad could be saved at the time the user exits the lump management menu (as opposed to when the map is saved). This would be a compromise between saving each time a change is made, and queuing them to save at the end.

2. Image browsing -- It would be nice to see several images simultaneously, such as in DeePSea and other editors. However, I personally don't have a problem the way you currently have it set up (perhaps I've gotten used to it). Still, if you've decided to add this feature I'm sure it'll improve an already good product.

3. Zooming -- I'm not sure what all the fuss is about. I use WA both in Win95 and Win2K and the extra zooming that Win2K provides is nice but not terribly important to me. What would be nicer would be the creating of a 1*1 size grid, as opposed to the current 2*2 minimum. As none of the editors I've seen have a 1*1 size minimum, I imagine there's some sort of DooM or other software limitation. I frequently work with angled linedefs that have odd-numbered lengths, and it would be nice to anchor a vertex wherever I choose, instead of the program selecting the closest grid point. (Nevertheless, as Jack of SBSoftware pointed out, differences of 1 pixel are unnoticeable in the game.)

4. Rubber-banding -- The current system of square/rectangular windows to select stuff on the map works fine in most instances, particularly when dealing with square/rectangular sectors. However, when trying to select everything within an odd-shaped sector the current system sometimes causes unnecessary sections of a map to be included in the selection. Granted that the unnecessary sections can then be manually de-selected, but this can sometimes be a painstaking process. (Not to mention that if you accidentally include a stray vertex as part of the selection, pasting your selection causes WA to crash.) Allowing a free-hand selection window (such as in MS Paint) would solve this problem. In my opinion this is not a terribly important feature, but I figured that since you were asking I'd put in my 2c worth.

Thanks again.

[Phileosophos]

>When you say "making lots of little changes to a large
>wadfile could take an enormous amount of time if they
>are applied singly" do you mean the amount of time to >save/compile the changes to the wad?

Yes, that's exactly what I mean. For safety's sake, WadAuthor always generates a completely new wad file during the save process. In this way, if *anything* goes wrong--even the most disastrous crash one can envison under Windows--short of your partition/FAT table getting wiped during the save, the original data is intact. I got burned so many times with other editors, I decided that losing data during a save operation was simply verboten with WadAuthor.

With that in mind, consider what would happen if someone had five new lumps to add to a file the size of the DOOM.WAD file. The user would have to add them one at a time, writing a monstrous file each time (shudder). Not my idea of a good time.

>In your description you implied that there would be a
>lump management menu, within which the changes would be made.

If that's what I implied, then I screwed up (grin). Lump management would not be supported by just another menu. It would be an entirely new doc/view combo. That is, opening a wadfile for lump editing would be a completely different kind of task than opening it for map editing. When opening it for lump editing, the window would look very much like a Windows Explorer window when showing a detailed view of the files in a folder.

>2. Image browsing -- It would be nice to see several
>images simultaneously, such as in DeePSea and other
>editors. However, I personally don't have a problem the
>way you currently have it set up (perhaps I've gotten
>used to it).

Yeah, but wait until you see how it looks now (grin). I have almost got the graphic viewer control finished, and I think it's pretty sweet. I can crank the zoom up on the image graphics so that they are easily distinguished, or turn it down and resize the dialog box until I can see *all* of the flats at once. I rather like that.

>3. Zooming -- I'm not sure what all the fuss is about.

Neither was I, but it was always something people complained about. My main beef with the zooming was that the code was so awful (grin). If you're not a programmer, you probably can't understand it, but just knowing that yucky stuff was in there was like a poison in my very soul.

>What would be nicer would be the creating of a 1*1 size
>grid, as opposed to the current 2*2 minimum.

Done. The minmum grid is now set to one pixel.

>Allowing a free-hand selection window (such as in
>MS Paint) would solve this problem.

Hmm... That's a good idea. I wonder: how on earth could I do that? (laughing) I honestly don't know how such "lasso" selection tools work. I suppose I could sample the cursor position or maintain a list of them or something like that until the user lets up on the button. It would then be a matter of writing some code to do polygon hit testing. I'll think about it.

[ReX]

Phileosophos said:

With that in mind, consider what would happen if someone had five new lumps to add to a file the size of the DOOM.WAD file. The user would have to add them one at a time, writing a monstrous file each

Currently, a .bak file is created each time a wad is saved. I imagine the same system will continue, even when dealing with lump changes. If that's the case, I envision 2 scenarios -- in the first case, the user is given the option of saving the wad at any time during the lump "editing" process. Thus if the user wants to make 3 changes, and chooses to save after each change, then only one .bak file is being created at a time (i.e., each time a wad is saved, the previous .wad file replaces the .bak file, as is the case currently). In the second case, the user is only given the option of saving the file after ALL lump editing changes have been made for the session and the user is about to exit the lump management mode. This is similar to how WinTex handles texture editing -- you insert all the patches you want into the various textures, and WinTex prompts you to save your changes when you exit the texture editing mode. In this case only a single .bak file is being created. Under either scenario there is only one .bak file in the directory at any time.

I always thought the saving/compiling process took a long time because of the node-building process, and not the inclusion of data or other lumps. For example, in DeePSea and WinTex, saving a wad after adding sound, music, graphic and text-based lumps appears to be practically instantaneous. Is this because the changes are being written into the file in real time? If so, then I see what your dilemma is. Still, if it's simpler to program, perhaps you shouldn't worry as much about making this feature idiot-proof. As a compromise, you could program it this easier way but have a message window pop up when a user opens up the lump management mode. The message will tell the user that any changes made during this mode will automatically be made to the wad. You can suggest that the users make a back-up of the wad in case they make changes that they're not certain they want to be permanent.

[DeePsea]

ReX said:

As none of the editors I've seen have a 1*1 size minimum
---------------------------------------------------------

You can have any size grid you like in DeePsea, including 1 and "odd" sizes (not powers of 2). Set the minimum in F5/Map. Press Shift+Ctrl+g to set any size grid you want, like 3:) Has to do with being able to scale proportionally from one design to DOOM coordinates.

I think I know what you mean by "anchor" - so let me explain. All the editors "anchor" (if snap to grid is off). You can't put the vertex "anywhere" on the visual screen because Doom coordinates are Integers. So when you see the end point of drawing move in increments (even with snap off) it's because of the translation to the DOOM coordinate system. You see the same effect when you use a paint program. When you zoom the image, it moves in "blocks" as you "paint". Hope you get the idea.

Zooming is a big deal, just depends on how tight your levels are and what size monitor. DeePsea has a limit of 3200% (32x) since in very tight complicated areas it makes it a breeze. As John noted, one has to work around the driver problems. It's not trivial.

[Phileosophos]

ReX said:

I would bet that the reason saving is "practically instantaneous" in WinTex and DeepSea is because you're dealing with small files. I mean, try fussing with DOOM.WAD sometime and see if saving doesn't take several seconds--not because the operation is complex, but because the file is just bloody large! Of course, it could be that those programs take a more incremental approach to saving, but I don't know.

What I do know is that WadAuthor does *not* take the incremental approach to saving. Let me explain. The wad file format is pretty simple, consisting of a (1) header, (2) directory and (3) lumps. To add a single lump to a file, then, requires nothing more than adding a single directory entry and shoving the lump data somewhere in the file. Let's say a given wadfile had the directory at the end of the file; in this case, a program could read that into memory, write the new lump at the same location at which the directory used to reside, write the updated directory after that new lump and update the file header to "point" to the new directory location. Such an approach means that adding a lump takes no more time than (1) writing the new lump data, (2) writing the directory data, and (3) writing a new value into the file header.

When I wrote the wadfile handling code for WadAuthor, I decided against pursuing such a save strategy because it can (1) lead to file fragmentation if taken to the extreme (i.e., there can be blank spaces left in the wadfile if a lump is deleted simply by removing its directory entry) and (2) confuse other wad editing programs and utilities that expect to find the directory in a given place. WadAuthor's saving function works differently insofar as it always rewrites the entire file. Adding a lump to a wadfile in WadAuthor would involve the same three steps as the other approach: (1) writing the new lump data, (2) writing the directory data, and (3) writing a new value into the file header. But it would also involve a large fourth step: (4) copy *all* of the other lumps from the original file to the new file. That's why the time hit could be enormous. Can you imagine how little fun it would be adding three tiny lumps to DOOM.WAD?

The reasons it would be much simpler to code such an approach, however, are many: (1) I don't have to worry about an undo feature, (2) I don't have to worry about the order of operations (e.g., a delete doesn't screw up the lump numbering), etc. Still, I prefer the deferred approach and that's what I'm going work toward.

[DeePsea]

John, if you expect to get "rewarded" for your work, change the install. Everybody just reinstalls to defeat the time limit.

Have a good one.

[Guest D|RE]

deepteam said:

John, if you expect to get "rewarded" for your work, change the install. Everybody just reinstalls to defeat the time limit.Have a good one.

I hope people would respect Mr. Williston and his hard work and register the program. its only 20 bux. I felt morally obligated to register this program, because i see how much mr. Williston cares about the End user. but I guess there are always the people who dont care, and will do anything they can to avoid paying money. Its sad, becasue if you like a program, you should buy it, because you are investing in the future of the program.

[DeePsea]

Phileosophos said:

I don't see any noticable difference? Could be he's referring instead to the node building step, which is a big difference for large levels. Link to the newer BSP and you too will see a difference:)

DeePsea saves the whole shooting match all at once. The standard .BAK files ( a convention started a long time ago by somebody) is also done. There is a different approach in -some- lump management tools. .BAK can overlay other .BAKs, so it not always a good idea.

In my "development" of any sort, I prefer my own "by hand" copies of code, since the .bak system really does not produce a "reliable" backup. Good for last ditch, but not much else.

[DeePsea]

wildman said:

Great news. It would be awesome to have lump management as well. The gui sounds perfect. As far as manipulating the lumps singly or at once, I personally don't have a preference. Wintex does it singly and DeepSea does it all at once and the end result seems to be the same really. I personally don't have a perference. Go with whatever is easy.

Thanks for the update.

All depends on how extensive a change one is making. If one is manipulating many many lumps, there is a huge difference in efficiency and time.

In DeePsea, you can "stack" multiple files from the open dialog box without having to go back to the "open" dialog every time.

The second advantage is that you can comfortably review your work before committing the changes.

To "stack", use the standard Windows Ctrl+left click multiple "anywhere" selection command in the Open Dialog box. For creating large texture modifications (or anything with lots of files), we are about talking 10x less effort to accomplish the same thing.

For a very few changes, it's not a big deal. The "stacking" was done by request to solve exactly this time problem.

Talking about Wintex, the end result is not exactly the same - it has a mind of it's own:) Which reminds me, how come nobody ever noticed (or mentions) it merges Textures/Pnames incorrectly? The more I check it out, the more odds and ends I discover.

[pming]

Phileosophos said:

You're welcome. It's actually kind of fun to work with this code base again after so many years. I just got a first rough version of my new graphics list working in the image browsing dialog box, and it looks sweet. The zooming worked the first time out--I guess I really did learn something from my problems with the main view. If I can get the scrolling behavior nailed down and add all the typical UI crap to the graphical list view, WadAuthor is going to have some sweet image browsing.

WHOO-HOO!!! You don't know how long I've been waiting for this (well, maybe you do...depends on how far back your email logs go...;-)

Keep pluggin' away at it!