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

Questions about pwad bugs/problems

Recommended Posts

Hello. In the course of testing out some older pwads with the vanilla doom executables, or chocolate doom, I've encountered messages like these:

Bad V_DrawPatch
R_InitSprites: Sprite %s : %c : %c has two lumps mapped to it
R_InitSprites: Sprite %s frame %c has rotations and a rot=0 lump
In the attempt to fix them, is there any way I can 'debug', or specifically 'find' the lumps that are causing these errors?

The first message doesn't specify which patch is in error, and the latter two are semi-vague as to which sprite(s) is/are.

Share this post


Link to post

If you give the names of some of the wads, the people will find it easier to check what the problem is. It's unlikely that these maps were released in a state that was wholly unplayable.

Share this post


Link to post
E.J. said:

Hello. In the course of testing out some older pwads with the vanilla doom executables, or chocolate doom, I've encountered messages like these:

E.J. said:

Bad V_DrawPatch


A patch texture was attempted to be drawn off screen.

E.J. said:

R_InitSprites: Sprite %s : %c : %c has two lumps mapped to it


The same sprite exists twice between S_START and S_END.

E.J. said:

R_InitSprites: Sprite %s frame %c has rotations and a rot=0 lump


A sprite has a omni-directional sprite and a directional sprite. As an example, having both XXXXA0 and XXXXA1 lumps is illegal. This is between S_START and S_END.

E.J. said:

In the attempt to fix them, is there any way I can 'debug', or specifically 'find' the lumps that are causing these errors?

The first message doesn't specify which patch is in error, and the latter two are semi-vague as to which sprite(s) is/are.


Load the program with a debugger and break on I_Error and debug the game using the WADs that cause these errors.

Share this post


Link to post
GhostlyDeath said:

A patch texture was attempted to be drawn off screen.



The same sprite exists twice between S_START and S_END.



A sprite has a omni-directional sprite and a directional sprite. As an example, having both XXXXA0 and XXXXA1 lumps is illegal. This is between S_START and S_END.

Wow, and thanks for the info.

GhostlyDeath said:

Load the program with a debugger and break on I_Error and debug the game using the WADs that cause these errors.

Huh...? What type of debugging program would work, and what is an "I_Error"?

Share this post


Link to post
E.J. said:

Wow, and thanks for the info.


Huh...? What type of debugging program would work, and what is an "I_Error"?


Depends on your operating system.

I_Error is a function in Doom which prints an error message and quits the game.

Share this post


Link to post

Any Windows OS from 98 to Vista would be doable.

Could you give me some starter advice, or some links to the relevant info?

Share this post


Link to post
Grazza said:

If you give the names of some of the wads, the people will find it easier to check what the problem is.

Agreed. There's little point debugging the executables when the faults in a PWAD or the way it's being loaded.

Share this post


Link to post

The names of the offending resources should have been output inside the error message. If Chocolate Doom actually output "%s" and "%c" to the console, then something is seriously fucked up beyond anything you're going to be able to fix yourself. If it did that, report it as a bug to fraggle.

Share this post


Link to post

I've tried about 80 pwads recently, so I'm not sure which exact ones gave me the messages. I'd have to go back over them, but they occurred at launch most times.

If Chocolate Doom actually output "%s" and "%c" to the console, then something is seriously fucked up beyond anything you're going to be able to fix yourself. If it did that, report it as a bug to fraggle.

I took the generic error message format from this page. There was more than one wad with that type of error.

http://doom.wikia.com/wiki/Error_message

I'm not interested in troubleshooting chocodoom, or any custom dehacked executables. I want to find the specific resources that are causing the errors in an attempt to correct them.

Like how do I find a patch that is getting drawn off-screen? The error doesn't post that info...

Share this post


Link to post

Yes, but the thing is that there may not be any error with the wad itself. It might be that the wad needs some additional resources (in which case the txt may give details, and the zip may well include them). If you randomly load wads from the archive on their own in Doom2.exe, then you *will* get some error messages in some cases.

Tell us the name of some wads where this has happened, or this thread is little more than a waste of time and space. If the errors occurred on loading, then all you need to do is go back over the wads you have been testing and see if they fail at start-up. That shouldn't take very long.

Share this post


Link to post

[EDIT]
Based on GhostlyDeath's post above I was able to figure out why I got the error message of 2 lumps being mapped to one sprite.

For some reason, CPOSF1 and CPOSF1F8 were considered the same... I simply renamed the pwad sprite.

Using Goldeneye Doom as an example for the next type of error:

chocolate-doom -iwad doom2.wad -merge ge64levs.wad gold64.wad -deh gold64.deh
I got this:
R_InitSprites: Sprite GOR1 frame A has rotations and a rot=0 lump
I have no idea why this occured...

One time I was able to determine which custom sprite gave me a bad V_DrawPatch error, because it occurred on the end game enemy slideshow. I adjusted it's XY co-ordinates to match the equivalent Doom 2 sprite, and it was fixed.

The problem with these errors is that they don't tell you what resource caused it, and are the errors I'm most interested in locating.

Share this post


Link to post
E.J. said:

[EDIT]Using Goldeneye Doom as an example for the next type of error:

chocolate-doom -iwad doom2.wad -merge ge64levs.wad gold64.wad -deh gold64.deh
I got this:
R_InitSprites: Sprite GOR1 frame A has rotations and a rot=0 lump
I have no idea why this occured...

It's an error in the PWAD, sprite frames normally either have rotations (numbered 1-8) or face the player (number 0) but not both. Looks like that sprite's meant to have front and side views so you could try renaming GOR1A0, GOR1B0 and GOR1C0 as GOR1A1, GOR1B1 and GOR1C1. If Chocolate's not happy with that - revert to the original names and delete lumps GOR1A3A7, GOR1B3B7 and GOR1C3C7.

Share this post


Link to post

If Chocolate's not happy with that - revert to the original names and delete lumps GOR1A3A7, GOR1B3B7 and GOR1C3C7.

^ This worked, and looks fine enough. ^

Although this particular pwad is prone to visplane overflows if there is any clipping, incidental, or through cheating. Map 32 isn't compatible at all.


Anyone have an idea how to identify Bad V_DrawPatch errors, without going through the entire pwad while comparing resources?

Share this post


Link to post

E.J. said:
Although this particular pwad is prone to visplane overflows if there is any clipping, incidental, or through cheating. Map 32 isn't compatible at all.

That means it's extremely unlikely that the WAD was tested with vanilla. If you want precise answers, though, you're better off linking to or naming the WADs you're examining, as Grazza suggested.

Anyone have an idea how to identify Bad V_DrawPatch errors, without going through the entire pwad while comparing resources?

It means a graphic is drawn in a bad place. Often, the graphic is aligned in such a way that it's drawn over the edge of the screen. PWADs that do this are buggy or not compatible with vanilla.

Dark Fate 2 by Karthik Abhiram, for example, gets the Bad V_DrawPatch termination error from blank WIF and CWILV00 replacements with ridiculous and pointless X and Y alignments (-387, -86). Changing the alignments to null (0, 0) will fix the issue. That WAD has that problem because it was not tested with any engine that behaves like vanilla. This is not too surprising, as it is a "limit-removing" PWAD and was made before the Doom+ hack was released.

Share this post


Link to post
myk said:

That means it's extremely unlikely that the WAD was tested with vanilla. If you want precise answers, though, you're better off linking to or naming the WADs you're examining, as Grazza suggested.

...

That WAD has that problem because it was not tested with any engine that behaves like vanilla. This is not too surprising, as it is a "limit-removing" PWAD and was made before the Doom+ hack was released.

Been gone for a few days, sorry about the not getting back sooner.

I know GoldenEye doom was a poor example, but I suppose you guys are right. If I find any more issues, I may run them by everyone here in this thread.

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
×