prboom Issues Thread

[cph]

2.2.5 is out, and should address the deh flags issues and the intermission screen desyncs.

[Grazza]

Hacx still fails, I'm afraid (2.2.5 or 2.3.1), so there are still deh issues. For example, on map13, if you go forward and to the left from the start, your path is blocked. I think it's because a lamp has been modified with dehacked and is no longer meant to be an obstacle; however, it still blocks player movement. This is just one example of what is clearly some wider problem.

It's not some remnant of this old issue, is it?

[Quasar]

OMG, cph! I'll get back with you guys really soon on proff's proposals about putting Eternity in subversion and making a new merger fork of it. Our project is currently in a vicious stall, with v3.31 final not yet released, so I've been too busy.

[Grazza]

The changes in dehacked support seem to have introduced a serious problem in 2.2.5 and 2.3.1. Watch the demo here to see what I mean.

You see lots of stuck zombiemen who are meant to be wholly invisible (they are used to create ambient sounds). This doesn't affect behaviour (the demo plays back correctly), but ruins things visually. It's fine in 2.2.4 and 2.3.0 (and Eternity).

[cph]

Grazza said:

The changes in dehacked support seem to have introduced a serious problem in 2.2.5 and 2.3.1. You see lots of stuck zombiemen who are meant to be wholly invisible (they are used to create ambient sounds).

Thanks for the example. Yes, I got NOBLOCKMAP and NOSECTOR the wrong way around. 2.2.4 is missing NOBLOCKMAP entirely, messing up all the higher flaos; in 2.2.5 I added NOBLOCKMAP, and put it in front of NOSECTOR by mistake. Fixed in the development version.

[Janizdreg]

Whenever I run PrBoom (2.2.6), Windows' midi volume settings change so that the speaker balance slider moves far left, causing the midis to only play through left speaker/speakers. Here's my specs in case needed:
Windows XP Home Edition (Finnish) SP1, DirectX 9.0c
Integrated Realtek AC97 sound card
Midi playback: Microsoft GS Wavetable SW Synth

[myk]

I'd suggest getting some good GUS patches and using TiMidity... you can control the music sound volume then without issues.

[Quasar]

Please report that you've had this MIDI problem to the SDL team at libsdl.org -- it is an issue in SDL's native Win32 MIDI support which is also adversely affecting Eternity. Unless enough people complain about it to the SDL guys, it will probably never be fixed :/

[RottingZombie]

In PRBoom, latest version, How do I use a joystick, I 'enabled' it in PRBoom, but can't simply map the controls through the menu. It's windows XP Home, logitech dual action USB, tried it in both USB ports. The docs say something about the keycodes are the codes as reported by the kernal/drivers but while I vaguely understand this I don't know how to get windows to spit those codes at me so I can use them! ANy help? Because I'm sick of ZDoom and it's coop bugs and my girlfriend won't use a mouse/kb and needs a pad.

Also, are there any ports that don't have something majorly wrong with them? I mean I just want a simple classic doom with no updated graphics (except 640x480 res+), no altered gameplay, no altered settings etc. PRBoom is cool cept the controller thing, zdoom owns but I like PRboom's feel and compat modes better.

I wish id would update doom95 and make the mouse work with XP , that's all I'd need :)

[Grazza]

I've never used a joystick with Doom, but have you tried editing the cfg file? In prboom.cfg or glboom.cfg, you should find something like this (this is from my cfg, with joystick disabled):

# Joystick settings
use_joystick                  0
joy_left                      0
joy_right                     0
joy_up                        0
joy_down                      0
joyb_fire                     0
joyb_strafe                   1
joyb_speed                    2
joyb_use                      3

Play around with those numbers, and see if that helps.

Edit: I fiddled around a bit, and got my joystick (a Wingman Extreme) working with Prboom 2.2.4 without undue difficulty. I calibrated it via the Windows Control Panel (Game Controllers - Properties), and then once I'd enabled it in Prboom, it worked fine. I didn't need to edit the cfg beforehand. When I looked at the cfg afterwards, it had the following for the joystick settings:

# Joystick settings
use_joystick                  1
joy_left                  -32768
joy_right                 32767
joy_up                    32767
joy_down                  -32768
joyb_fire                     0
joyb_strafe                   1
joyb_speed                    2
joyb_use                      3

I imagine it is easiest to remap the buttons to whatever you're happiest with by editing the cfg. Note that in Prboom, you can't remap the mouse buttons with complete freedom (you couldn't in the original game either), so I presume the same goes for joystick buttons.

[RottingZombie]

Thanks, I'll try calibrating in in windows first then enabling it in the game. My pad's buttons are labeled with numbers, but i tried setting those numbers first in the config, that didn't work. So I'll try your method and pray. Thanks alot.

[Pirx]

ok, i use glboom if i want to play maps purist style, and for watching demos. it ran perfectly under windows2000. i've recently switched to xp, mouse input is as always after i reg-patched xp's default mouse accel. only glboom's mouse input behaves strangely, my turns are completely inconsistent. most times when i try to do a quick 180° i either turn too far or too short, it's random (not even normal accel, i don't turn farther if moving the mouse quickly). wtf. prboom doesn't suffer from this disease.

[Grazza]

Which version(s)? The only difference between prboom.exe and glboom.exe is the renderer, so if you're getting different behaviour (for non-rendering issues) within the same version (e.g. prboom 2.2.4 behaving differently from glboom 2.2.4), that would seem odd indeed.

[Pirx]

thanks. glboom 2.2.6 behaves differently from prboom 2.2.6, no matter what resolution.

i tested it again before posting this, and it's quite noticeable.
prboom has the normal doom2 mouse input.
in glboom a quick 180° turn may become randomly 120° or 220°.
it feels like my sens is too low right now, and a second later too high.
(or i'm not used with accel, but it's neither constant, nor have i played with it)

i tried with both mice, an intelli optical 3.0 which i use for applications, and a wingman modded with 3.0 optics i use for playing.
intellidrivers 4.2, default speed, sens 12 notches from the left horizontally, zero vertically.

i'll test it on a friend's comp with xp and a mx300, plus v.2.2.4 which was error free iirc.

this is particularly annoying for me as i have some performance issues on large maps with jdoom, while glboom runs with most wads, fast and i can watch demos in it before attempting to play a level in the same style, heh ;)

[KSquad24]

Using PRBoom, I create a server on my machine and join it. Another computer in my home also joins it and Doom launches, but...both machines seem to be spawning at the same location (player 1 start.) Nobody can move or anything and the game must be aborted.

I don't see any networking problems since other games work fine. So what's the deal? Any ideas?

[entryway]

Torr Samaho said:

prboom has the normal doom2 mouse input.
in glboom a quick 180° turn may become randomly 120° or 220°.

It's true. GLBoom processes a mouse much worse than PRBoom. Anyway - so it seems. I think it a problem of the opengl rendering realization.

[Grazza]

entryway said:

GLBoom processes a mouse much worse than PRBoom.

Not for me. It's completely fine* in glboom.exe, whereas with prboom.exe I often get the standard (visual?) foul-up at start-up (but it's OK thereafter). Must be one of those awkward system-dependent things.

* Well, apart from not being able to get a quick start, like with Doom2.exe, but that's not really a mouse control issue.

[entryway]

Grazza said:

Not for me. It's completely fine* in glboom.exe, whereas with prboom.exe

Start GLBoom and pass to the 12-th level. Turn a head to the right and to the left. Movements will be smooth. Now go forward and again turn a head. Turns will not be smooth.

[VinceDSS]

On my dad's comp I cannot run prboom at all, it crashes everytime I move the mouse.
I have to use GLBoom on his system.

[Janizdreg]

Just in case someone hasn't noticed yet, there's a new SDL mixer version (1.2.6) out that fixes the midi bug. Get it here.

[TheShep]

few things:

-no way to turn music off from in game...volume all the way down doesn't even do it, so have to turn off synth in main settings of system.
-cannot run winamp in background and hear it, PRBOOM dominates the sound system.

[Grazza]

These are probably SDL issues. Have you got the most recent versions of SDL.dll, SDL_mixer.dll and SDL_net.dll? They're still not perfect, but each new release seems to iron out a few more issues. I believe Andrey Budko includes the current versions in his the zip for his modified Prboom, so that's an easy way to get hold of the files.

My experience is that these things are system-specific too. On my desktop machine the in-game music volume control doesn't work, but I can change the music volume using the volume up/down buttons on my keyboard without leaving the game (or affecting the sound effects volume). As for WinAmp, I don't use it myself, but don't recall problems using other music programs while running PrBoom (not that I do so very often).

[entryway]

If I start prboom.exe (2.2.6) in a window mode (-nofullscreen) and with a sfx and music it always crash for me after start of new game

[entryway]

It occur only on 800x600
screen_width 800
screen_height 600

[bejiitas_wrath]

I am wondering if the demo recording facility in Prboom 2.3.1 has been fixed on Linux yet? I have tried to record demos with prboom 2.3.1 on Linux and I have had no success. Please tell me this is fixed?

I am using Suse 10.0 and Kernel 2.6.14.4 and I downloaded the i386 binary release from sourceforge. I am dowloading 2.4 as I speak so I will try that.

#define OFFTOPIC 1

I have also uploaded my newstuff reloaded and my new Ultimate Doom Tecbase map to /incoming so hopefully there will be a couple of good maps in /newstuff soon.

Btw, when is the next /newstuff update?

#undef

[VinceDSS]

prboom 2.3.1 is experiemental and unstable. It's screwy but has great features ... which prboom+ should get, like the new filters for software mode (which could be applied to GL too, too soothe things a bit more).

now prboom 2.4.0 is out, but it doesnt have any one of the great features in 2.3.1 ... sad ... maybe entryway can fix this.

[proff_fs]

VinceDSS said:

prboom 2.3.1 is experiemental and unstable. It's screwy but has great features ... which prboom+ should get, like the new filters for software mode (which could be applied to GL too, too soothe things a bit more).

now prboom 2.4.0 is out, but it doesnt have any one of the great features in 2.3.1 ... sad ... maybe entryway can fix this.

They will come back, we wanted to make a stable release with some internal new features from 2.3.1 and the rest will come back step by step. 2.3.1 had too many changes and wasn't really maintainable anymore. We plan to do smaller releases from now on, as we don't have much time anymore and don't want to make the same mistake as with 2.3 which took way too long and wasn't properly tested.

[myk]

Grazza said in a sticky in Demos:
Thus if you mostly want to record vanilla demos (and Boom when necessary), you can put 2 as your default compatibility for Doom2, 3 as the default compatibility for Ultimate Doom, and put -complevel 9 in the command line when recording on a Boom map. Nothing more to worry about.

True, although wouldn't it be more convenient if there were two CFG entries for this, one for DOOM and one for DOOM II? It's true that that only applies to "vanilla" demos, yet in a way that is an important function of the engine. Plus these two would just be -1 by default.

[myk]

What is the automapmode CFG entry for? It seems to do nothing. And map_point_coord seems equally nonfunctional.

Also, for some reason PrBoom eliminated the 4 player colors, replacing them with a generic "friend" color, plus a "me" color for the guy playing. Why would you do that? Both Boom and MBF left the four player color entries alone, as in the real game.

Additionally, the screenblocks function is not supposed to affect the automap at all, but PrBoom applies it there, hiding portions of the map when screenblocks is 9 or less.

[RjY]

automapmode is a bitfield which says whether or not the map was

• active (bit 0)
• in overlay mode (bit 1)
• in rotate mode (bit 2)
• in follow mode (bit 3)
• with the grid on (bit 4)

when the config was saved. So if you prefer an overlaid, rotating map it will save your preference.

map_point_coord appears to be an MBF option to display coordinates of the dot in the centre of the automap (as opposed to the player coordinates) but hasn't been ported to PrBoom yet.