PrBoom-Plus, ver. 2.5.1.4

Doom_user said:

There's severe visual corruption in GLBoom+ when the player enters sectors with deep water and/or colormaps. It affects the status bar, the player's weapon, on-screen messages, and menu graphics.

Where is the bug precisely?

This?



Post link to your cfg.

entryway said:

Where is the bug precisely?

This?

https://dl.dropboxusercontent.com/u/235592644/clip/2014-09-26_10.27.42.png

Yes. Also
the m_doom logo and menu graphics in shot 1
the status bar, status bar face, the player's weapon, and the large health numbers in shots 1, 2, and 4
the key icons in shot 3
the large ammo numbers, large armor numbers, and the small ammo numbers in shots 1, 2, and 3
several of the small numbers above "arms" in all 4 shots

Post link to your cfg.

Here it is.

This happens even if I erase glboom-plus.cfg and let GLBoom+ generate a fresh one.

I also updated to Freedoom Doom 2 iwad (date modified 1/1/2014 4:17pm), this happens with it as well.

This also affects the numbers in the automap.


Just before entering deepwater/colormap sector.


Just after.

New svn location for PrBoom and PrBoom+

The repository has moved to https://svn.prboom.org/repos/ and is running svn 1.8.

There's a redirect from the old crowproductions url so those who care might not need to do anything, but I thought I would pass the message along regardless.

Sadly, it's still svn instead of git.

And it still doesn't get a browser-friendly interface like WebSVN or something... You gotta use an SVN client to see the logs.

entryway said:

Sadly, it's still svn instead of git.

This is a surprise to read. I've been under the impression for years that you were against moving to git.

I'd kind of like to throw it out there that if an SVN to Git migration is desired, I might be able to offer assistance with the move. Such migrations are often tricky and not really easy to handle well, I have suspicions that the PrBoom repository is not really well-put, even if only for the fact that PrBoom and PrBoom-Plus share the same repository, these could be split out if desired. (As a side note, is there any good reason PrBoom-Plus hasn't merged back in with (and replaced) the main project?)

I've had prior experience with migrating the Eternity Engine repository. Toyed with Chocolate Doom also, but fraggle wrote his own conversion program for the official move; also have toyed with Odamex but I've not actually talked to any of those devs about moving (and it's sufficiently complex that I haven't started a good cleanup script for it).

Is there some windows binary with the wiggle patch applied?

Also, for the love of all that is holy, please PLEASE make the enter key show the menu. When will this ESC torment end?

VGA said:

Also, for the love of all that is holy, please PLEASE make the enter key show the menu. When will this ESC torment end?

Enter is already used for 'accept' in the menu, it would clash horribly with the way Doom's menu works to make it open the menu.

That and I can't think of any game where ESC isn't used to open the menu.. this is standard even in modern games.

But enter does nothing when the menu isn't open, why? It's so convenient to be able to mash the enter key in zdoom and get in game fast.

Well, you could bind ESC to "select item" (it's the next-to-last item on the last page of "key bindings"). Then you just need to mash ESC to start a game quickly.

VGA said:

But enter does nothing when the menu isn't open, why? It's so convenient to be able to mash the enter key in zdoom and get in game fast.

I don't imagine anybody cares but it does actually have the function of displaying the last line of text you received for item pick ups.

Heh, I had absolutely no idea it did that.

I notice that in vanilla Doom, pressing Enter while the Start screen is showing (or internal demos are playing) does indeed bring up the menu. So it is not an unreasonable feature request... In fact, it could be considered a bug report, since it is a vanilla feature that has presumably been misguidedly or accidentally disabled at some point. (I notice that in MBF, it still worked during the start screen, but not during the internal demos.)

Uncommenting this code in G_Responder restores the MBF titlescreen/demoloop behaviour Grazza describes.

//e6y
  /*
      return gamestate == GS_DEMOSCREEN &&
  !(paused & 2) && !(automapmode & am_active) &&
  ((ev->type == ev_keydown) ||
   (ev->type == ev_mouse && ev->data1) ||
   (ev->type == ev_joystick && ev->data1)) ?
  M_StartControlPanel(), true : false;
    */

I am not sure why it was removed, it predates version control (svn blame cites r1328, initial import of pr+ 2.2.6.19).

Yeah, it's retarded to run a program/game and start off by pressing ESC...

Just checked Doom in Dosbox and Grazza is right, Enter is the key to get things going. Because logic.

But is there a compiled prboom 2.5.1.4+ with wiggly squiggly fix? I cannot unsee the glitches. At 1680x1050 it looks fantastically bad.

The current version is in its usual place.

Huh, for some reason I thought PrBoom-Plus already had the same behavior of pressing enter to get the menu to open at the titlescreen or demos like in Vanilla, which I knew did that, I just thought you were referring to when you were in gameplay.

In that case I take back my opinion that it would make no sense. It makes perfect sense from the title screen/demos. My habit of using ESC anyway to start off was pretty much in stone so I never realized this.

Since I had a problem with the viddump feature and the x264 giving me error about not supporting mp4 output, I found modded builds that worked for me here:
https://astrataro.wordpress.com/category/encode/x264/

So I have a zip here with the three programs needed to make the viddump feature work out of the box, just drop these in prboom folder:
https://1drv.ms/u/s!AiVQX0Or4E1vgyJOsGuh8DkQ1H4t?e=Tdvi9t

These are win32 builds.

Edited December 5, 2020 by VGA

Is there a way to increase the volume and pitch of the fluidsynth midi player?

Breezeep said:

Is there a way to increase the volume

mus_fluidsynth_gain

Why does the SC-55.sf2 soundfont sound great on gzdoom with timidity++, but on latest prboom+ with fluidsynth D_RUNNIN sounds like it's coming from inside a well?

(TimGM6mb.sf2 sounds fine)

Bug reports (Windows x64, 2.5.1.4 test)
---------------------------------------
1) Alt-F4 and Alt-TAB works only with the left Alt key. The right one is ignored?
2) After Alt-tabbing I think the state of the Alt key is "stuck", because after I come back to prboom+ and press F4 it exits and with ENTER it switches fullscreen.
3) I tried several soundfonts and they sound worse than in zdoom with timidity++. Especially sc-55.sf2 from here:
http://www.mediafire.com/download/cu0wncrd0ecmh5d/Patch93%27s+Roland+SC-55+Soundfont+V1.9.rar

VGA said:

1) Alt-F4 and Alt-TAB works only with the left Alt key. The right one is ignored?

This is normal behavior for any program.

VGA said:

2) After Alt-tabbing I think the state of the Alt key is "stuck", because after I come back to prboom+ and press F4 it exits and with ENTER it switches fullscreen.

Works fine for me. F4 opens Sound Volume menu after alttabing

1) That can't be true, both Alts should work. I just tried Zdoom, Dosbox and pcsx2 and even Potplayer, alt-enter works with either Alt. Please change it :-)

2) Also, I get the "alt gets stuck when alt-tabbing" bug only when alt-tabbing with the left alt, with the right one it works fine. Also, it happens only ONE time per prboom/glboom execution. And I can't reproduce it inside a win7 x86 VM...

3) Anyway, I ran into a "I_SignalHandler: Exiting on signal: signal 11" crash after saving while playing Back to Saturn X E1. The save was successful (I loaded it fine later) and the game did display the message "Game saved", so maybe the crash was after that code? I was scared shitless because I only keep one save :-)

Hmm, yesterday I tried AltR+Tab/F4 at home and these combinations did not work by some reasons (tried with notepad), but they work as expected at my work computer. Sorry. Will try again in the evening.

I don't know if any of you have a German keyboard, but these have special Alt-Gr keys on the right, which might get interepreted diefferently than regular Alt keys.

I can verify the alt lock bug. Some time ago there was this thread about capslock mashing. Could it be related?

fabian said:

I don't know if any of you have a German keyboard, but these have special Alt-Gr keys on the right, which might get interepreted diefferently than regular Alt keys.

It's not just for German keyboards. I have a Logitech G15 and it has an Alt Gr :-)

Microsoft doesn't differentiate the two Alt keys:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731%28v=vs.85%29.aspx
Using this program (which uses windows API since it's in Delphi) I can indeed confirm it returns the same virtual key code for both.
http://www.delphiforfun.org/programs/utilities/KeyCodes.htm

But prboom+ uses SDL I guess and they have separate codes:
http://sdl.beuc.net/sdl.wiki/SDLKey
SDLK_RALT
right alt / alt gr
SDLK_LALT
left alt

EDIT: Thanks dew for confirming the alt-lock when alttabbing bug, it doesn't happen on all windows it seems.

EDIT 2: Haha, Zdoom has an option to merge left and right Ctrl/Alt/Shift ...

While we're on keyboards, could we *please* fix that the WinKey is sorta being half-used? This totally prevents me from using PRB+ :(

I need the WinKey for strafe (hurts my hand to stretch further as much as we strafe in DOOM). And PRB+ lets me set it as a usable key. (Incidentally this was so all the way back to BOOM, as it was my feature request. :)

Anyway, it works the first time I use strafe, but soon after that (not always the next keypress), the WinKey will decide it belongs to Windows again. This throws me out of the game and to the desktop.

Maybe the way to make it work is to just disable the WinKey far as Windows sees it, but leave it alone in PRB+ I know other games allow use of the WinKey for motion (I think it was HalfLife that let me use it).

Also, are you interested in adding Fusion's new codepointers? they let you achieve all sorts of weird monster behavior. :)

PS. I'm on the road so will be out of touch for a couple weeks.

If you decide to do that, at least make it optional. Some people like having the windows key go back to windows.