Zip Support

[randi]

Graphics offsets are the first problem that springs to my mind.

I don't see why that's a problem. The offsets are stored in the image itself, not the wad directory. If you want to use a more standard image format, PNG files have the oFFs chunk for specifying offsets, so no problem there either.

Note: I'm not saying that zip support is on the way, just that graphic offsets are a non-issue if it was done.

[HotWax]

I just can't see the point of creating a new system with new conventions, requiring new tools (and thereby making many people's favourites obsolete) when a system exists that does the job perfectly already, especially when moving to a new system confers no real advantage over the old one.

It wouldn't make old tools obsolete, as the WAD format would still be supported fully. The keyword here is "optional." I agree that there doesn't seem to be a huge need for this, but if supporting a ZIP format would make handling lumps easier for some people, then those people would benefit.

As an example of what could be done faster using this system, let's say someone wants to make a 32-level replacement megawad using all the standard resources except the weapon sounds which they want to replace with some ub3r new sounds that are teh l33t.

Under the old system, they could make each map individually, merge them, and then use a lump editor to insert the sounds. Each one of these tasks requires a specialized program that can read and edit wadfiles and the lumps inside them.

Under the new system, they have the option to make each map individually, name them whatever they see fit (without the need for a lump editor to do so), drop them in a ZIP file along with the sound files, and they're done.

Which is easier? I guess it depends on what you're used to and what your preference is. Personally, the second method sounds a bit easier to me.

There is also another small advantage to ZIP files. Anyone with a newer version of Windows or who has WinZip installed can double-click the files and see exactly what's being replaced, without the need to run them in a WAD editor. Again, whether this is easier or not is a matter of preference.

[Enjay II]

Different username 'cos I can't log in under the old one for some reason.

I don't see why that's a problem. The offsets are stored in the image itself, not the wad directory. If you want to use a more standard image format, PNG files have the oFFs chunk for specifying offsets, so no problem there either.

OK, that was me making an assumption. The assumption being that along with zip support people would want support for proprietary graphics formats (such as BMP). Sure, if people want to use the Doom native graphics format, then offsets are part of that. But although there may be a tool that makes graphics in that format without sticking them in a WAD, I'm not aware of it. So people would end up sticking graphics into a WAD and setting their offsets with DeePSea/XWE/Wintex, then exporting the graphics as lumps and putting them in a Zip. Or at least have to make all their graphics as BMPs or whatever and then convert them to the Doom format and put them in a Zip. Which I think really does defeat the purpose of all this.

However, I did not know that it would be possible to use the PNG format to store offsets, so that problem can be got around, provided a tool exists/is created to store offsets in the format easily. Again, why bother though if nothing is being added to the system that already exists?

It wouldn't make old tools obsolete, as the WAD format would still be supported fully.

Fair point.

Under the old system, they could make each map individually, merge them, and then use a lump editor to insert the sounds. Each one of these tasks requires a specialized program that can read and edit wadfiles and the lumps inside them.

Under the new system, they have the option to make each map individually, name them whatever they see fit (without the need for a lump editor to do so), drop them in a ZIP file along with the sound files, and they're done.

I still don't see the advantage. With the proposed new system, you make your map with a map editor (which needs to save the map as seperate lumps - so 13 (or is it 12?) files kicking around instead of 1 wad), you use your sound editor to make your WAVs, you use your graphics editor to make a couple of replacement textures, then you use a Zip tool of some sort to put them all together.

With the existing system, you make your map with a map editor, you use your sound editor to make your WAVs, you use your graphics editor to make a couple of replacement textures, then you use a WAD tool of some sort to put them all together.

I really don't see a difference or an advantage. Either way, you still make your individual files in the editors of your choice, and then use a tool of some sort to put them all in one "container file".

[Graf Zahl]

.\MAP01\THINGS
.\MAP01\LINEDEFS
.\MAP01\SIDEDEFS
.\MAP01\VERTEXES
.\MAP01\SEGS
.\MAP01\SSECTORS
.\MAP01\NODES
.\MAP01\SECTORS
.\MAP01\REJECT
.\MAP01\BLOCKMAP
.\MAP01\BEHAVIOR
.\MAP02\THINGS
.\MAP02\LINEDEFS
...etc...

Baaaad!

Maps should be inserted as a full WAD and handled inside the game. The only real problems are the graphics/sprite offsets. Unfortunately there is no easy way to do this. Aside from this there is absolutely nothing that would make handling a zip file more complicated than a WAD file (except for the programmers of WAD management tools of course! ) The big advantage of Zip files is that there are a lot of tools that can handle them as virtual directories so adding a resource would become as easy as copying a file on the hard drive.

[randomlag]

Disagree. ZIPS make it MORE complicated for USERS who create levels. How can MORE steps and programs make something simpler? Answer: It doesn't make it simpler.

The issue is not that it can or can not work. The issue is that it's more complex. There's not a single thing that made easier. See Enjay(II)'s post about he organizes data.

[Fredrik]

Disagree. ZIPS make it MORE complicated for USERS who create levels. How can MORE steps and programs make something simpler? Answer: It doesn't make it simpler.

It's not more steps. For example, if I work with textures, I generally have a directory of all the files. When I need to compile a WAD, I have to open a WAD editor and go through several steps to create the WAD and load all the files. This can take minutes depending on the editor.

With Zip, I can just select the files I want, right-click, and select "add to zip". It's instantaneous and comfortable, gives better overlook than any entry manager of an editor too.

In fact I can't think of any process that would take longer time to do if using Zips. The example of maps is invalid, because you'd obviously keep all the level lumps in a WAD since that's how the level editors save levels.

[Ultraviolet]

Don't forget about multi-patch textures...

[HotWax]

Enjay, Gref, and Fred: Please read my posts fully before you tell me how bad one of my ideas is.

What I said was, in ADDITION to being able to use the directory structure (the example Gref posted), you would also be able to just drop the entire WAD (containing each individual map lump) in the file with a custom name. I also suggested the extension .LVL to easily identify the file as a map file, but the actual format would still be WAD.

Example:

You create a map in Zeth, you save it as MAP01.WAD. You rename MAP01.WAD to MYMAP.LVL and insert it into a ZIP. Done.

The disadvantage to this method is that if you need to edit the maps later, you're going to have to extract them and then open them in a WAD editor anyway, making two steps out of one.

Alternatively, you could use the directory-structure method and easily swap files in and out using already well-established ZIPfile tools.

RL, as usual you're stubbornly sticking to the "My way is the only right way" attitude you usually adopt and defend with 9-paragraph posts. I'm proud of you for keeping your posts so short in this thread. Also, the assumption that something that takes more steps must be harder is flawed. Renaming a file in Windows takes more steps than it does in DOS, but most people prefer it and would agree that using DOS is harder. There is something to be said for user-friendliness, so long as it doesn't go too far.

As I've been saying all along, the point here is choice. If it's easier for Fredrik to use ZIP files than it is for him to use a WAD tool, then he benefits. If it's easier for you to use a WAD tool, that's your option.

[GooberMan]

HotWax: There's no need to keep map lumps separate (indeed, the fact that maps are dependant on the WAD format would suggest keeping it in one file is a good idea, although if ZIPs are incorporated you could have a ZIP with the necessary lumps in it and treat it as if it were a WAD), and as I noted there's no need to even segregate the data in to folders thanks to the fact that ZDoom will be supporting any graphic any where (graphics were treated differently than everything else, and now that they're not there's no need for lump markers at all - excepting that darn map format).

randomlag: if you're going to quote Enjay constantly, at least quote him when he pointed out that using ZIPs makes it the same amount of steps but a different program used to put it all in one big file. Perhaps you're looking at it from the wrong angle if you think it'll take more steps. As I've been trying to point out, it's completely unneccessary to create new lumps, directory structures, etc, and indeed if ZIPs are incorporated you'd find that the code for handling zips is quite alot neater and more robust than working with the WAD format, which would make things easier from both code, and as a newbie to editing - no need to learn the WAD format and lump markers but instead work with something familiar.

ultraviolet: no reason at all that multi patch textures can't be supported with PNG loading.

[randomlag]

I simply disagree. I wasn't quoting - do you see quotes? Just cut the b.s. eh. Think conceptually how Enjay stated he works. Should be obvious in context.

I don't care how many ways you want to twist this around, it's MORE steps and NOT simpler.

Just because some people use a certain set of antique methods doesn't mean everyone does. I can put stuff together just as fast/faster than a zip method. A zip is not inherently more robust - arguably less robust. Let's see you recover a zip that is damaged. IOW, saying something is so, does not make it so.

Markers have nothing to do with this. One has to make EQUAL comparisons. If one makes an effort for zips, then the same effort can be done with PWADS. As far as "newbies", do you really think all those tutorials are going to be rewritten? Of course not. So life gets to be even more complex for those starting out. MORE complex, not less.

Everything stated is NEW and just as much work. Just because it can be done, does not mean it's a good idea. Period. If you want to debate, give the exact steps (including all the mods that have to be made - including zdoom and including all editing requirements) for setting up this supposedly easier method. For sure it's not as clean and elegant a package as a PWAD.

[Mighty Duck X-treme]

Suggestions for randomlag: Take deep breathes, count to ten...

Meanwhile...

No Fredrik, you edit out insertwackynamehere's post like this:

EVERYBODY LOOK AT ME!!!!!! I POST OFF TOPIC!!!!!!!!

[Fredrik]

Let's see you recover a zip that is damaged.

1. Disable compression then, and you'd have a simple container file - without most of the WAD format's restrictions - easy to recover data from if damaged.

2. Zip files are much less likely to get damaged than WAD files. I've had several WADs get screwed up because of editors crashing etc, but never had a zip break to this date.

3. Since I'd normally be working with a directory structure outside the zip, damage to the file would only require me to re-pack.

If one makes an effort for zips, then the same effort can be done with PWADS.

Effort as in what? If you change anything about the WAD format, you wouldn't have any editors that supported it.

As far as "newbies", do you really think all those tutorials are going to be rewritten?

No, they wouldn't need any tutorials at all! People'd just have to select a couple of files and put them in a Zip. Even newbies are familiar with that procedure.

For sure it's not as clean and elegant a package as a PWAD.

Just the fact that you can have a directory structure makes it more elegant than the WAD format.

[GooberMan]

I simply disagree. I wasn't quoting - do you see quotes? Just cut the b.s. eh.

I see you referring to Enjay's posts instead of copying/pasting. Quote was the best word that came to mind, and yes it isn't exactly the right word but it gets my point across

I don't care how many ways you want to twist this around, it's MORE steps and NOT simpler.

Refer to my post about thinking from a different perspective. Also notice how Enjay posted the exact same amount of steps to make a WAD and to make a ZIP. Same amount of work, different program used for the last step (or if incorporated in to WAD managers, it can even be the same program).

Just because some people use a certain set of antique methods doesn't mean everyone does.

And there's the perfect argument as to why ZIPs should be implemented. Sure, ZIP has been around longer than WAD, but what's the standard worldwide archive format today? Should be a no brainer to answer that one.

Markers have nothing to do with this. One has to make EQUAL comparisons. If one makes an effort for zips, then the same effort can be done with PWADS.

Or you could provide a set of functions that act as a common interface for WADs and ZIPs. Quite easy to do, and saves trying to make a ZIP act exactly as a WAD and vice versa.

As far as "newbies", do you really think all those tutorials are going to be rewritten? Of course not. So life gets to be even more complex for those starting out. MORE complex, not less.

As Fredrik pointed out, people already know how to ZIP. If not, there's probably a ZIPs for dummies book out there. Learning a new format makes it more complex for newbies. With ZIP, they have the option of learning a standard archive format, or a format specifically designed for a near 10 year old game. Which do you think an absolute newbie would choose?

Everything stated is NEW and just as much work. Just because it can be done, does not mean it's a good idea. Period. If you want to debate, give the exact steps (including all the mods that have to be made - including zdoom and including all editing requirements) for setting up this supposedly easier method.

It would require some design thought on my part for that common interface I mentioned. If you really are interested I can write up something when I get home, or are you just trying to make your own point and don't really care about it?

For sure it's not as clean and elegant a package as a PWAD.

You crack me up. I sure do miss reading a deep/everyone else thread on Doomworld Oh, Fredrik pretty much stated my thoughts on why that statement is flawed, so refer to that post if you must.

Anything else you think needs adressing?

EDIT: I remember an old util back in the PKZip days called PKZIPFIX, which reparied archives 99% of the time. I'm not sure if WinZip or other ZIP tools have that these days, but other compression formats like RAR and ACE come with those build in to the archiver.

[Mighty Duck X-treme]

I remember an old util back in the PKZip days called PKZIPFIX, which reparied archives 99% of the time. I'm not sure if WinZip or other ZIP tools have that these days, but other compression formats like RAR and ACE come with those build in to the archiver.

http://www.florida.plus.com/izarc/

http://www.webattack.com/freeware/downl ... wzip.shtml


I can't be too sure what computer you're running, but I'm running Windows XP Pro, and I'm too lazy to buy another utility for my newly supercharged PC heh

[GooberMan]

But although there may be a tool that makes graphics in that format without sticking them in a WAD, I'm not aware of it.

I'm not aware of one either, but it's not terribly hard to create one. Converting to Doom format for graphics in a ZIP though is rather counter-productive though, especially when most graphic editing programs these days support PNG.

Mighty Duck: Running dual boot Win98 and Win2K at the moment, considering dumping both and migrating to XP.