R_ProjectSprite Crash?

[Csonicgo]

While playing epic2 on vanilla doom today (patched with deutex, of course, so dont' ask) I got this rather odd error:

R_ProjectSprite: invalid sprite frame 34 : 32768

I haven't gotten it to happen again, but it was a revenant attacking me with a rocket.

This sounds like a really odd error when the wad entries are "OK". Can anyone explain this weirdness to me, or was this a very rare occurance?

Edit: got it to happen again:

R_ProjectSprite: invalid sprite frame 93 : 0

Something is definitely wrong here.

[Gez]

Relevant code:

    // decide which patch to use for sprite relative to player
#ifdef RANGECHECK
    if ((unsigned)thing->sprite >= numsprites)
	I_Error ("R_ProjectSprite: invalid sprite number %i ",
		 thing->sprite);
#endif
    sprdef = &sprites[thing->sprite];
#ifdef RANGECHECK
    if ( (thing->frame&FF_FRAMEMASK) >= sprdef->numframes )
	I_Error ("R_ProjectSprite: invalid sprite frame %i : %i ",
		 thing->sprite, thing->frame);
#endif
    sprframe = &sprdef->spriteframes[ thing->frame & FF_FRAMEMASK];

The frame is the letter. 0 is A, 1 is B, etc. 32768 is a flag to make it bright. Sprite 34 is FBXP and sprite 93 is SGN2.

So FBXP A and SGN2 A are both deemed invalid.

[entryway]

Wrong IWAD was used by deutex during merging (doom.wad instead of doom2.wad).

Unfortunately, there is no way to specify required IWAD for deutex, so you have to deceive it. For example:

1. Put doom2.wad, epic2.wad and deutex into separate folder
2. Remove DOOMWADDIR environment variable
3. Start «deutex -as epic2.wad»
4. ???????
5. PROFIT

[Csonicgo]

I should have known. Deutex is an awful utility.

[Quasar]

Fact: there's a bug in DOOM's sprite loading routine. If there are *no* frames for a sprite that the engine expects to be valid amongst all loaded wad files, the sprdef_t structure corresponding to that sprite name will remain uninitialized.

This is fine so long as nothing tries to actually use that sprite. For example, Ultimate DOOM doesn't crash out for lacking the DOOM II sprites - until you try to add a DOOM II thing to a map after changing its DoomEd number to one that P_LoadThings doesn't block, that is!

To try it out, apply a DeHackEd patch to the original executable to change the Mancubus's DoomEd number to 666. Now place a thing of type 666 into a map and load it in Ultimate DOOM. The game will usually crash with a venetian blinds crash. When it doesn't these strange error messages may appear instead.

This bug was not recognized by the BOOM team and remained even in Eternity for several years until the sprite loading code was refactored so that missing sprites no longer constituted an error condition.

[fraggle]

Csonicgo said:

I should have known. Deutex is an awful utility.

Totally agree with this. Unfortunately it's still better than all the other tools that do what it does, of which there are none.