doom-utils / deutex Goto Github PK

Hi there,

I sometimes wish for a "raw" mode in deutex in which all available lumps are extracted from a WAD as they are, i.e. I don't want sounds transformed into AU/WAV and pictures into PPM/GIF/whatever but only their raw byte streams.

• Fabian

It would be nice to have CI, such as Travis CI, in the repo. That way, contributors can easily check if their changes compile successfully, without having to compile the code themselves.

Most sections in a wadinfo.txt file support a * at the end of an entry, and it means the current entry will simply be a copy of the previous one, using the same offset and length in the output wad file. Seems the idea is to save space if you have a resource that is repeated.

The main exception is the [LEVELS] section, which currently ignores the repeat marker.

I have quite a lot of wadinfo files on my computer (over 100), including from most of the IWADS, and only two of them contain this repeat marker: the Heretic iwad and the Hexen iwad, used three times in each one, and all of them are zero-length lumps.

So I think this is actually a mis-feature with very low utility, and Deutex would be better without it. The code to support it really hampers understanding of the composition code in compose.c. It also makes it harder to add support for new sections in Deutex, e.g. I haven't coded support for it in the TX_START stuff yet.

Obsoive: http://imgur.com/a/M8Phw

Basically, what's happening is that it's not handling the tallpic format correctly. The correct post for whenever the current pixel of the column is y=254 is 254 + 0 + 0 + 0 + [number of transparent pixels inbetween previous post and the next] + [length of next post], or 254 + 0 + 0 + 0 + 255 if the rest of the column is transparent pixels.

Instead, what it's doing is just 254 + [length of next post]. As you can see, this is why non-transparency pics don't get mangled.

Basically, instead of setting WADINFO as the default filename, let Deutex give it the name as the WAD it's extracting/composing from.

Changing line 590
MakeFileName(WadInf, DataDir, "", "", "WADINFO", "TXT");

of deutex.c into

MakeFileName(WadInf, DataDir, "", "", MainWAD, "TXT");

might be enough for extracting a WAD named "maps.wad" and creating a directives file called "maps.txt", unless specified by the user.

Ogg Vorbis is a popular (and free) sound format used for both sounds and sometimes music in Doom WADs. I lack the knowledge to properly implement it, given how it's more complex than a Wave file.

Would it be possible for more experienced people familiar with the Ogg Vorbis codec to have a go with implementing it?

As I recall (apologies if you already fixed this), there are limits on the length of filenames for overrides. For example, you can do this:

[musics]
D_E1M1 = D_C1M1

But you can't do this:

[musics]
D_E1M1 = one/two/three/four/five/six/some/long/path_name/D_C1M1

This is annoying since it places restrictions on how a deutex tree can be structured - hence why Freedoom had to have an elaborate symlink-based setup.

I think there are also restrictions on file extensions? You can only specify the "stem" of the filename and have to let Freedoom work out the extension? And maybe that "stem" can only be 8 characters long, too?

If I get it correctly, -join is meant to merge 2 pwads.
So and I do that like "deutex -join a.wad b.wad"
And it stops on LisUkn word.

1. Is this an intended behavior or something is wrong?
2. How do I merge 2 pwads if I do something wrong?
   Here's a pic from cmd
   

Voros2@c7dbba4

Voros2@115658e

Deutex had a bootstrap IWAD in its distribution, users won't need any other IWAD to run Deutex. There might be a few exceptions, such as Strife or Hexen, but maybe that can be addressed Freedoom v0.9 bootstrap IWAD and Zauberer bootstrap IWAD could be used.

By the request of @chungy. Could be something like "D" or "DEUTEX", faded from blueprint sketch to gold/blue Doom colors.

Seems to not work as expected, trying to modify doom.wad in DOOMWADPATH directly:

$ deutex -doom freedoom1.wad -merge FD099.WAD 
i AA15 Main directory: freedoom1.wad
i ME46 Attempting to merge iwad /usr/share/games/doom/doom.wad and pwad FD099.WAD
i WR19 Reading WAD /usr/share/games/doom/doom.wad:	(2306 entries)
i ID50 IWAD entry identification...
i WR19 Reading WAD FD099.WAD:	(464 entries)
i ID10 PWAD entry identification...
i WW10 Modifying wad /usr/share/games/doom/doom.wad
E WW12 /usr/share/games/doom/doom.wad: Permission denied

After checking out the v5.2.2 tag and running ./bootstrap, errors are generated if you don't have asciidoc installed

configure.ac:14: error: possibly undefined macro: AS_IF
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:28: error: possibly undefined macro: AC_DEFINE
configure.ac:30: error: possibly undefined macro: AC_MSG_FAILURE
autoreconf: error: /usr/bin/autoconf failed with exit status: 1

After installing asciidoc, the errors dissapeared.

#65 is possibly related?

Voros2@46e9278

Unix-based and Windows systems usually have / and \ as the default path seperators. Would using something like this be considered a good way to set the default path seperators Deutex recognises? Is it even needed?

Voros2@b721462

Relevant thread
Sprites taller than 128 get tiled in game, which can look bad in vanilla exes. An example would be from Freedoom: (freedoom/freedoom#329). Final Doom also suffers from this, but it's more subtle.

Updating Deutex to support tall sprites would be nice.

The config parser allows you to specify a filename explicitly for most sections. For example you can do this:

[musics]
D_E1M1 = D_C1M1

You can't do this when specifying a texture lump in the [textures] section; it has to conform to the name of the lump.

This used to be annoying for Freedoom, but is slightly moot now, since we generate our own texture lump.

Right now deutex is autotools only which does not play very nice with CMake toolchains, especially in terms of pulling in deutex as a git submodule. Providing a CMake option would make modern source port toolchains easier to manage, and prevents the requirement of forking the thing.

I have several iwads at /usr/share/games/doom
deutex -doom2 /usr/share/games/doom/doom2.wad still reads in doom1, or even freedoom if I remove doom1.

the -doom2 thing just seems to set "main directory" to that path, here's an example output.

deutex -overwrite -v5 -doom2 /usr/share/games/doom/doom2.wad -extract

 AA28 Overwrite existing files
i AA10 Verbosity level is 5
i AA15 Main directory: /usr/share/games/doom/doom2.wad
i EX00 Extracting entries from wad /usr/share/games/doom/doom.wad
i WR19 Reading WAD /usr/share/games/doom/doom.wad:      (2194 entries)
i WR19 Reading WAD /usr/share/games/doom/doom.wad:      (2194 entries)
i ID10 PWAD entry identification...
i PL05 Palette is Doom

Do I really have to fukkin remove ALL the wads except the one I'm interested in?
By the way this also happens if I put the wad somewhere else, it still latches onto usr share games etc
https://www.youtube.com/watch?v=l60MnDJklnM

There is a bug in vanilla Doom where horizontally mirrored sprites don't have their horizontal offsets mirrored to match. So monsters can end up "jumping around" all over the place when viewed mirrored.

Example from Freedoom: freedoom/freedoom@f6f5ee88365c6846726

There's a fairly simple solution which is to add blank space on the left or right size, so that horizontal offset = sprite width / 2. It would be nice if there was an option for deutex to just do this automatically for all sprites, or at least those with a mirrored version.

http://freedoom.soulsphere.org/downloads/build.log

See wadptr for what I mean. It would be nice if deutex just did this automatically.

It should be straightforward enough to generate a cryptographic hash of each lump and use it to ensure the same lump is never written twice.

The function name is very vague, so I can't personally tell what it's supposed to do, but I assume it's for reading, compiling and inserting scripts into a PWAD.

On a sidenote, how about looking into KSSC, Kaiser's Strife Script Compiler?

By bisecting, I've found that commit 85d821d introduced a segfault on x86 (possibly others) while attempting to fix a crash on sparc64.

Missing / Unknown public key while Build deutex on Arch;

Solution is to add this key;

gpg --keyserver keys.gnupg.net --recv-keys 8649B37607A08042

Voros2@d536257

Recently, I had to compare two different versions of the same WAD. Both WAD files had a different size and a different checksum, but I needed to know which lump were different inside the WAD.

I had to extract the WAD and then compare all of the files using terminal commands. I would be great if DeuTex could do this by itself. Voros as suggested how this feature could work on Doomworld.

Using a simple command would make the task easy. There are two similar WADs here which are PG-RAW.WAD and PG-RAW-X.WAD. They have a similar size, a different checksum, but I think the content is the same. This feature should be able to confirm if they have the same lumps or if the only data that differs is not inside the lumps.

In the parse_argv section. Consider removing it.

If a user explicitly requests manpage generation, the configure script should report an error if the system is unable to perform the request -- otherwise the build will fail unexpectedly on machines that do not have a2x.

There are 3 possible scenarios:

• ./configure
  Here the configure script should check for a2x and build the manpage if able. If not able, the configure script will automatically disable the manpage build without error.
• ./configure --disable-man
  The user explicitly requests to bypass the manpage build so the configure script should disable it.
• ./configure --enable-man
  The user explicitly requests to enable the manpage build so the configure script should report an error if the system is unable to perform the build.