Fredrik wrote:And you shouldn't compare Deepsea with Winzip. The very point is that you'd do the management in your operating system's file manager - and you are more familiar with that than you are with Deepsea, right?
- and then just use a compression utility to compile the zip.
True enough, but that's basically what I do. I organise my files in directories then use a "zip" tool to put them all into one container. It's just that in this case the container is a WAD and has no compression. I'll concede that there is an extra step in doing it the way I do because with zipping things up, I would drop the folders onto the zip to preserve the paths (which is the suggestion for identifying flats/texture/sprites etc - yes?), but with a lump management tool, you need to go into the directory and select all files.
I don't see any problem with sticking the various lumps between F_, P_, S_ markers provided you have a good util to work with - it's dead easy if you do. I'll agree, there is room for people to make a mistake and people have to learn that part of lump management rather than just using their (presumably) existing knowledge of path structures. There is the possibility of errors with zips too. A number of times with a zip, I've put everything into an archive using paths, then modified a file, dropped it into the zip and it has ended up outwith the path structure contained in the zip. From experience, moving an errant sprite from outside the S_ markers in a WAD (again, with a good tool) is easier than moving a file around the path sructure inside a zip.
With Zdoom, however, in future there may be no need to have flats/textures/patches individually identified a lot of the time. Zdoom will soon have a release version that supports "any graphic anywhere" so all you have to do in most cases is include all your new graphics as patches and use them as and where you see fit. No need for paths, or even markers in a WAD if you want to be untidy about it.
Not wanting to get bogged down with the one issue, as this is a bigger question than just this, but sprite offsets are still a stumbling block IMO. The ways suggested: a control file, incorporating it into the name etc would increase the time involved getting sprites to reasonable offsets hugely. I'm not sure how many lump tools actually do this, but when you import a projectile or monster/decoration sprite using DeePsea, it analyses the dimensions of the graphic and imports it at reasonable offsets. eg 500 sprites all offset in one go automatically without the user even noticing the time it took. If I had to type a control lump, or individually name the sprites it would take ages.
Once the sprites are in a WAD, you may still want to tweak their position. DeePsea, XWE and Wintex all provide similar tools for doing this. Sprites are shown on screen and can be moved around in single pixel increments, quickly checking how they line up with the next sprite by simply clicking on the next one in the list and going back and forward between them. I'm not aware of any Zip tool that allows you to preview graphics simply by highlighting them, much less see how they would line up in a game with the next graphic in a series. So, with the zip method, I'd have to go into game, try and spot how well my sprites were lining up, try and work out which ones were the problem, remember them, quit, go to my control lump/file name, re type the offset, then go back into the game to see if what I had done looked OK.
I guess someone could write a tool that auto generates whichever control method was opted for. This tool could perhaps even allow interactive adjustment of sprite offsets in a zip and modify the control method appropriately. However, that's getting into a new, specific Zdoom-zip management tool which pretty much defeats the purpose of what this thread is about.
There is also another issue, which is a pretty big one IMO. No wad editing tools support zips. "So what?" You might be saying - the OS does it for you. But, for example, how do you propose an editor would allow you to preview a wall or flat graphic if it doesn't suport the format? You'd end up putting texture name onto side defs "blind" or doing something odd like browsing your texture directory using PSP and switching backwards and forwards to your editor to type in texture names (no selecting from drop down lists either). Or perhaps putting everything into a WAD for editing purposes, loading that into an editor and using it whilst you make the level, then compiling a zip for the distribution version. In other words, any editing tools would really have to be updated to support zips or lumps/graphics in a seperate directory before this would be a practical option. Already I see things getting messy with that kind of support and plenty of tools aren't updated anymore either.
I think really what I am saying is that the WAD format is a format designed for the job. Zips aren't, and do not natively offer all the reqirements of lump storeage for a Doom game. To make them provide those functions would mean the need for additional conventions, options and lumps for people to learn and for updated/new tools to support them. These would just be un-necessary work arounds IMO, to provide something the WAD format already does.
