prboom Issues Thread

[Doom_user]

In ZDoom and Legacy I had absolutely no problems enabling and using a gamepad (it took me less than 30 seconds with each), but in PRBoom I was unable to get it working, even after 3 hours of trying. I've never been able to play Doom with a keyboard or mouse, so at the moment this renders PRBoom unusable.

[myk]

I would suggest changing the samplerate settings:

Why not make it play each wave file at its applicable sample rate, like Doom does?

I'd leave the samplerate for Timidity, since that can consume a lot of CPU power if not regulated by the user.

I'm not sure, is the current setting just an upper sample rate limit, or does it resample every sound to the specified rate?

[myk]

Shouldn't complevel 0 apply pitch variation?

[Quasar]

It should, although pitch variation is broken.

The pitch value determined in S_StartSound is only used when the sound is first started. It is not maintained when the sound is adjusted (which happens once every mainloop execution), so the effect disappears almost immediately if you are moving around.

I only mention this because I just fixed it in Eternity the other day because pitch variation is an editing feature now.

[myk]

The default_skill is changed if you load the difficulty from the menu, and not if you use the command line. I don't think the default should be modified by the skill chosen for a particular game. In any case, add a menu entry somewhere where you can modify the default instead.

[Opulent]

Hmm... maybe this has been mentioned before... with Andrey's 226 versions of prboom, I cannot bind the left_shift key to forward. In the very latest versions, it won't even let me set it to it in the Key Bindings menu.

What gives?

[Belial]

I've reported it and it's fixed in the latest test version I have. Replacing the SDL dlls in 29 with older ones works as a temporary fix.

The bind works for me in older versions as well.

[RjY]

Why does Boom allow teleporters and lighting change effects with zero tags even when comp_zerotags is off?

Also, while I happen to think about it, does anyone happen to know why PrBoom (and Eternity, for that matter) has its own snprintf implementation? What's wrong with the one from libc (or whatever the windows equivalent of libc is)? Never mind, it's only in v2.3 :)

[Grazza]

My understanding of comp_zerotags is:
On/Yes means it behaves like vanilla, and an action that needs a tag but lacks one is applied to all untagged sectors (often resulting in the map falling apart)
Off/No means it behaves like Boom in this respect.

On that basis, is Prboom(+) behaving as expected?

[RjY]

Grazza said:

On that basis, is Prboom(+) behaving as expected?

Yes, yes it is. My query was regarding the Boom behaviour itself, so in retrospect I should have maybe started a new thread instead of using this one. But I don't like starting new threads unless it's for something major :)

Anyway I can only assume that Boom allows teleporters with zero tags because there are some really old maps that rely on them, and the Boom developers didn't want to break those maps.

[myk]

PrBoom is a Boom port, but it's also a Doom port (it emulates it very well). Thus shouldn't it more or less share Doom's DeHackEd capabilities, and not just Boom's? I mean especially the text info (F7 menu in DHE). In Boom you can't change things like the graphics lumps names and other similar stuff (ENDOOM, etc.) If Boom can change the music and other such lump names, I don't see why these others can't be added as well. Although Chocolate Doom uses another system for DeHackEd, I've been told, it's still a place to look into to see what to add.

[Quasar]

You crossed out your question but I'm going to answer it anyways. Up until 3.31 public beta 1, Eternity used simple sprintf everywhere. Misuse of this function is what caused the "two-week" bug that nearly caused me to cancel the project for good.

sprintf is a dangerous function because it has no overflow checking. It will overwrite as much memory as it wants in the process of producing the requested output, and doesn't guarantee null-termination of resulting strings even when they do fit.

snprintf (and the corresponding vsnprintf) is an alternative which is supposed to guarantee these two things:
1. The output buffer will never be overflowed.
2. The output buffer will always be null-terminated regardless of whether output was truncated.

(v)snprintf is SUPPOSED to be an ANSI-standard function, but for some reason compiler writers have historically decided that it is not important. Because of this, some compilers lack the functions altogether. Others which have it have buggy implementations that do things like calling down to normal sprintf's private implementation functions, and thus they may overrun the buffer or leave it unterminated (ie, the function's behavior is not standards-compliant). Even Visual C++ changes the name of this function to _snprintf, as if though it was a non-standard function when in reality it is ANSI and ISO mandated.

In order to avoid all of this retardation, I just found an open source implementation of portable snprintf (called psnprintf) and integrated it into Eternity. Now I don't need to worry about what platforms do or do not have an appropriate implementation.

[CODOR]

Quasar said:
(v)snprintf is SUPPOSED to be an ANSI-standard function, but for some reason compiler writers have historically decided that it is not important.

snprintf wasn't "officially" added until C99, even though it originated in 4.4BSD sometime in or before 1993. So any implementations more than about 5 years old could have got it wrong. There's a bit in the Unix Incompatibility Notes on it, too.

[proff_fs]

Quasar said:

…
In order to avoid all of this retardation, I just found an open source implementation of portable snprintf (called psnprintf) and integrated it into Eternity. Now I don't need to worry about what platforms do or do not have an appropriate implementation.

This reminds me that I wanted to add this to PrBoom 2.4 as well. I forgot it while I was porting stuff from PrBoom 2.3. Thanks Quasar!

[Quasar]

There is something to watch out for. You also need the m_fcvt.c module, which contains DJGPP libc's implementation of the fcvt family of functions which are responsible for floating point number formatting (they are very complicated and are not something you can write by hand without an intimate bit-by-bit knowledge of the IEEE floating point specs -- they are also not standard).

[Searcher]

I also repoted this at sourceforge bug tracker:
http://sourceforge.net/projects/prboom

I loaded up a map I recently downloaded and had a few issues with it. Not sure if these are port issues.

Anyone else have these problems with this map?

Title : Castle of the damned.
Filename : pit.wad
Author : John Cartwright
Date : 26, dec, 2000.

Requires Gothic DM textures (GOTHICTX.WAD)

PRBoom 245 will NOT work the doors in this map.
PRBoom 246 won't load it - missing texture.
PRBoom 223 works fine
PRBoom Plus 246 works fine
Boom 202 works fine

The Map is here:
http://www.doomworld.com/idgames/index.php?id=11018

[Grazza]

Searcher: My guess is that you're fouling foul of this bug.

What that means is that the program won't look in the directory in which it was launched when trying to load wads (certainly a nasty bug to have found its way into an actual release). Thus it may not be loading gothictx.wad at all. To remedy this, you can add the full path to the file, or copy it to your doomwaddir (if you have one - if you do, then it is probably wherever you have your iwads).

If you're wondering why this bug does not affect prboom-plus, it is because the 2.4.6.1 release was from before the bug was introduced, and the current 2.4.6.2test version includes the fix that is now in the SVN. (It had existed in an earlier test version, but the fix was included before I had a chance to report it!)

As for the door problem you mention, are you using -complevel 9 in that case? You need to use that in order to make the program emulate Boom 2.02's behaviour.

[Searcher]

Grazza thanks, I will try the complevel change altho' I can't figure out why it would need to be done.

The missing texture issue I will double check, but I am thinking it was not the texture wad but a missing texture instead.

I keep all the PRBoom's in doom2 subfolders and they all seem to run from there once I tell them where to go look or add to the wad dir entry. OR use a shortcut or .bat file with the needed IWAD path info.
I run most everything from the command line in a win 98 dos box.

I don't really think it is because of that bug, altho' it does appear to be a nasty one. I do suppose it may be the reason. I'll try the full path to check it.

[Searcher]

OK, With complevel 9 and prboom 245 pit.wad works. Thanks, altho I still don't know why prboom had to be told to act like a boom compat. port. Anyway that is Ok now.

The following is from the startup for PRboom 246:

prboom v2.4.6 (http://prboom.sourceforge.net/)
M_LoadDefaults: Load system defaults.
default file: D:\DOOM2\PRBOOM~2/prboom.cfg
found doom2.wad
IWAD found: doom2.wad
PrBoom (built Aug 12 2006), playing: DOOM 2: Hell on Earth
PrBoom is released under the GNU General Public license v2.0.
You are welcome to redistribute it under certain conditions.
It comes with ABSOLUTELY NO WARRANTY. See the file COPYING for details.
V_Init: allocate screens.
found D:\doom2\doom2.wad
Failed to autoload prboom.wad
D_InitNetGame: Checking for network game.
W_Init: Init WADfiles.
adding doom2.wad
adding pit.wad
adding GOTHICTX.WAD
W_InitCache

W_GetNumForName: CRBRICK not found

Then it quits. Won't load the map. I think it is actually adding the texture wad, but something in the map is missing a texture? Or the map/line def specifies a texture that does not exist in the texture wad.
I opened the gothic texture wad and looked for it (CRBRICK) then I ran the error checker over the map to have it look for missing textures.

The error checker does not show any missing textures. The texture crbrick is not part of the gothic texture wad nor is it a doom2 texture. The error checker did identify some 68 map errors but none of them are texture related.

Even with the full path to the pwad and the full path to the texture wad it will not load that map.

BTW, Eternity 3.33 and zdoom 210 both run this map just fine.

So, for whatever reason, prboom 246 just does not like that map.

======
EDIT:
I was just re-reading the post and saw this, just below. Perhaps the crbrick texture is in the prboom.wad that it failed to load.

"Failed to autoload prboom.wad"

Perhaps is is that bug you mentioned Grazza. I assumed it would look for its own prboom.wad in the folder it started from.

[Grazza]

Searcher said:

I still don't know why prboom had to be told to act like a boom compat. port.

Because it can act like various exes, including Doom2.exe, Boom and MBF. If you tell it to act like Doom2.exe, then Boom specials won't work, and Boom behaviour won't be applied (this includes things like stair building method, floor motion, linedef trigger model - pretty fundamental stuff). Likewise if you tell it to behave like Boom, then some vanilla maps will be fouled up by this. If you leave it on the default compat setting, then the behaviour will depend on the individual settings for the many compatibility options, together with the weapon and monster behaviour options. Obviously the default options can't be appropriate in all cases, and if you adjust them to play one map, then they may not be appropriate for the next map you play. Most of the wads I play are either for vanilla or for Boom, so I just have the default compability set for vanilla, and adjust it to Boom for those maps that need it. (Well, I use prboom-plus pretty much exclusively, but the same principle applies.)

Searcher said:

I was just re-reading the post and saw this, just below. Perhaps the crbrick texture is in the prboom.wad that it failed to load.
"Failed to autoload prboom.wad"
Perhaps is is that bug you mentioned Grazza. I assumed it would look for its own prboom.wad in the folder it started from.

If it is failing to find prboom.wad, then that will definitely cause serious problems. It's hard for me to say if this bug is causing this problem, but it sounds likely. For me, it does find prboom.wad, but maybe that is because it is locating another file with this name somewhere in the PATH.

[Quasar]

Normal programs do not use the PATH environment variable when searching for files. That only affects the command shell. More than likely, it's just looking in the wrong place (the current working directory instead of the EXE's directory, or something similar).

I'll note that EE had serious problems with this sort of thing when it was first ported to Windows, but only under XP. This is because XP changed the behavior of argv[0].

[Hobbs]

Searcher: CRBRICK is IIRC the first texture prboom.wad tries to open. So my guess is that somethings wrong with your prboom.wad

[Quasar]

Actually CRBRICK is a color range translation table for the DOOM font.

[RjY]

Sorry gentlemen, this is my fault. PrBoom is meant to search in a number of directories for IWADs and the data wad. The list includes the current directory, the same directory as the executable, the directory given by the environment variable DOOMWADDIR, and some other platform-specific locations.

To cut a long story short I made a patch to correct a Unix-specific problem with this search list, but unfortunately - as the link Grazza posted shows - missed a line that makes it search the directory in which prboom.exe was installed. Even more unfortunately, nobody noticed until after 2.4.6 was released.

I am guessing Searcher has a directory for IWADs and PWADs, and a separate directory that contains prboom.exe and prboom.wad. He changes to his WADs directory, then attempts to run PrBoom. Hence the current release fails to find prboom.wad, since it isn't looking in the executable's directory for it, then bombs out with an admittedly cryptic error message about a missing colour translation lump.

This will be fixed in the next version, but, as a workaround, try setting DOOMWADDIR (or HOME) to the location of prboom.wad (although this might affect other programs that use either) Alternatively, just for 2.4.6, place a copy of prboom.wad in your current directory (or make the windows equivalent of a symlink, shortcuts or whatever, I don't know how that stuff works)

[Searcher]

RjY you are exactly correct.

As a work around I simply placed a copy of the prboom.wad into the doom2 directory, there wasn't one in there. That is where I always run my wads from. I do keep all the engines apart so nothing gets over written. Prboom is in a sub folder like this: d:\doom2\prboom246\

That worked just fine as well. Thanks.

It works just perfectly now.

[myk]

Two bugs that have not been dealt with in v2.4.6:

1) It still modifies the default skill setting if you change it on the menu. A default is what is expected to be the case in general, and the menu choice refers to the the current game. Another menu entry should be added somewhere in Options where you can modify the default. In any case the menu behavior is inconsistent with that of the command line (that does not modify the default setting).

2) This bug is still present software more (no idea if this affects hardware mode since I'm not using it; maybe it was introduced adding GL support and it affected software mode adversely?).

[Doom_user]

If it's of any use, I did some tests to figure out which row of the colormap is used to draw the player's weapon at all of the light levels.

In all other ports

160-255 Row 0
144 Row 1
128 Row 5
112 Row 9
96 Row 13
80 Row 17
64 Row 21
48 Row 25
32 Row 29
16-0 Row 31

In PRBoom

208-255 Row 0
192 Row 4
176 Row 8
160 Row 12
144 Row 16
128 Row 20
112 Row 24
96 Row 28
80-0 Row 31

[myk]

Is the OPTIONS lump feature from MBF unsupported by PrBoom? I tried adding such a lump with some CFG settings on it but didn't see any effects... unless I did something wrong. I added game and compatibility options in the format used in the CFG.

Aside from allowing specific settings a wad author may recommend, that feature is pretty essential to an engine that can behave in so many ways, as often maps break if they don't have the proper compatibility settings. I'm pretty sure that's why Lee Killough added it.

It's not mentioned anywhere in PrBoom's documentation, so (coupling that with the fact I couldn't get it to have any effect) I'm fearing perhaps its absent.

[emailking]

If you go to level 3 of HR2, you can immediately turn around and kill the arachnotron behind you through the bars. The corpse then moves from one side of the exit block to the other, forever. Is this known? I can't find anything about this bug either here or in the open bugs on the tracker site. I checked and doom2.exe keeps the corpse still, but the lateest prboom along with 2.2.6 (only ones I tried) have the problem described.

[myk]

emailking said:
The corpse then moves from one side of the exit block to the other, forever. Is this known?

It's just a change made in MBF where things fall off ledges when dead. Since it's oo top of the exit ridges it just keeps sliding around. MBF also behaves this way. To get rid of that set comp_falloff to 1, or use compatibility level 2, for Doom (or 9, for Boom).