Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  

R_ProjectSprite Crash?

Recommended Posts

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.

Share this post

Link to post

Relevant code:

    // decide which patch to use for sprite relative to player
    if ((unsigned)thing->sprite >= numsprites)
	I_Error ("R_ProjectSprite: invalid sprite number %i ",
    sprdef = &sprites[thing->sprite];
    if ( (thing->frame&FF_FRAMEMASK) >= sprdef->numframes )
	I_Error ("R_ProjectSprite: invalid sprite frame %i : %i ",
		 thing->sprite, thing->frame);
    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.

Share this post

Link to post

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. ???????

Share this post

Link to post

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.

Share this post

Link to post
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.

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
Sign in to follow this