Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Cacowad

Deutex error: "error: GIF too short"

Recommended Posts

This is a question for you deutex wizards out there.
I'm currently trying to build an Heretic iwad from the Blasphemer repository, if you don't know what blasphemer is: it is basically the equivalent to FreeDoom, but for Heretic instead.

Now, getting to the meat of the problem: i picked up deutex, downloaded the complimentary cwsdpmi.exe and run it in dosbox using the command: "deutex -make wadinfo.txt blasp.wad" as usual.
Now, it manages to make sounds, graphics, sprites and wall patches, it starts making flats and then spit out this error message from the title: "Error: GIF: too short".

Obviously this error is a bit too vague to understand what's going on, and looking at the github repository this seems related to an incorrect read:

   /* Initialize the Compression routines */
   if (fread(&c,1,1,fd)!=1) ProgError("GIF: read error" );
   if (LWZReadByte(fd, TRUE, c) < 0) ProgError("GIF: bad code in image" );
   /* read the file */
   for(rawpos=0;rawpos<rawSz;rawpos++)
   { if ((v = LWZReadByte(fd,FALSE,c)) < 0 ) ProgError("GIF: too short");
     raw[rawpos]=(v&0xFF);
   }
   while (LWZReadByte(fd,FALSE,c)>=0);  /* ignore extra data */
this is an extract of the deutex code, you can find the full one here.

So my question is: someone know what is happening here?

Share this post


Link to post

I haven't looked into any details, but it almost has to be one of the following:

1. The GIF is of an format not supported by Deutex (There's a GIF87, and a GIF89, I believe).

2. The GIF is *slightly* damaged, making it fail Deutex checks, but maybe close enough that the source editor could work with it without problems.

3. The Deutex checks are incorrectly flagging a valid GIF as damaged.

4. The GIF is truly damaged, and Deutex is reporting it properly.

For issue #1 thru #3, maybe you can export the GIF, import it into an image editor, save it to another format, and finally bring it back into the WAD, bypassing the issue.

Share this post


Link to post

Protox ran into the same problem once, so instead he just saved the image in a different image editor and it worked.

Share this post


Link to post

Thank you deutex wizards, i converted them to .bmp and now it work (albeit with a warning message about the quantization being slow). It was probably my image converter doing something finniky, so for the time being i'll keep them to .bmp until i find a compatible converter.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×