PrBoom-Plus, ver. 2.5.1.4

Mike.Reiner said:

Whenever I change the lighting mode to 'Shader' and close the game, it always reverts to 'GLBOOM' is there a way to make this stick?

Does shaders mode work properly? GLBoom-Plus forces 'glboom' lighting mode if shaders failed during initialization.

It should look like this (gamma 0)

Yes, it works on both my laptop and desktop.

However this behavior of reverting only takes places on my desktop it seems, my laptop is holding shaders.

Laptop is running 2.5.1.4, desktop running some variant of 2.5.1.4test version.

Just updated laptop to latest 2.5.1.4.test from here:
http://prboom-plus.sourceforge.net/history.html

Seems to stick still. I'll update the drivers on my desktop and try again with a fresh .cfg.

Also this newest test has a different options menu that don't seem to be shown in the changelog there. Is there somewhere that you are keeping a changelog up to date on?

Thanks Entryway.

GLBoom-plus loads very long and works very slow on my computer. No problems with PrBoom-Plus and GZDoom.

Check that you don't have opengl32.dll (or a similarly named file, I forget the exact filename) in the same dir or somewhere in your PATH. That DLL would make glboom-plus use its software wrapper for GL rather than your video card's GL driver.

I tried to delete opengl32.dll, but the system says that I need a permission of TrustedInstaller.

I just installed PRBoom+/GLBoom+ for the first time yesterday, and was wondering: is there a place to specify the path to my IWAD folder? (Instead of having to copy all of my IWADs into my PRBoom+ folder...)

I don't think so. I use batch files to run prboom-plus for the most part, so with the -iwad arg you could get around needing them all in the engine's directory.

Salt-Man Z said:

I just installed PRBoom+/GLBoom+ for the first time yesterday, and was wondering: is there a place to specify the path to my IWAD folder? (Instead of having to copy all of my IWADs into my PRBoom+ folder...)

If you set up an environment variable called DOOMWADDIR, virtually all ports will look there for wads, including iwads.

Instructions on how to do that for WinXP and 7: http://www.computerhope.com/issues/ch000549.htm

I don't know Windows 8 well enough to even recommend a good site, I'm sure you can find something if you google for it though.

plums said:

If you set up an environment variable called DOOMWADDIR, virtually all ports will look there for wads, including iwads.

Instructions on how to do that for WinXP and 7: http://www.computerhope.com/issues/ch000549.htm

I don't know Windows 8 well enough to even recommend a good site, I'm sure you can find something if you google for it though.

Actually, that's perfect; I was trying to set up Chocolate Doom at the same time, and the documentation said to set up the DOOMWADDIR environment variable, but didn't explain what it was. Now I know. Thanks!

Hi, entryway. I was wondering if you're willing to tweak some rendering oddities in software and GL.

In software, it still retains this old bug in drawing sector borders when very close to them.

In GL, the aspect ratio correction is applied on the wrong step. It seems that the world coordinates are interpreted as 1:1, but is projected with 1.2x vertical stretching no matter the view pitch. While this does show the correct perspective when looking straight forward, it introduces incorrect distortion the moment the player is looking up or down to any degree. What should be happening is that the world coordinates should be scaled by 1.2 on the z-axis, while drawing remains 1:1. This way, you still get the same results as before when looking forward, but your view will be more distant from the floor and ceiling, and the flats will not be distorted.

Lastly, I was curious how feasible a sprite overdraw function could be. Of course, I'm not serious about this, as I know it's not all that trivial and would require multiple passes.

Sodaholic said:In software, it still retains this old bug in drawing sector borders when very close to them.

I noticed that while playing on a machine without 3D acceleration; it's enormously more visible at high resolutions, which I suspect is why I wasn't really aware of it in the DOOM.EXE days. I'd love it if it was fixed.

Yeah pretty much. prboom-plus at 1920x1080 in software makes it super noticeable. Pretty minor at 320x200 or whatever vanilla runs at..

I'd also love to see it fixed as I generally prefer software lighting with higher res.

How do I use the PC Speakers for sound FX? I have a winxp comp with no sound card. I set "PC Speaker Emulation" to "Yes" and restarted but there's no sound.

Also, idclev33+ doesn't work, if you don't already know.

Yes, that's because it's emulation. It's designed to output PC Speaker noise out of your system's sound card.

And yeah -warp is needed for map33.

Oh ok, so pc speakers aren't supported?

I wondered if it was a bug because chocodoom lets you clev to 33/34.

I don't think so.

Interesting, I didn't think you could do that in vanilla but I just tested it and it works.

IIRC Vanilla lets you idclev to 40, even though 36 and up will always crash.

Very nice game on the project's page. :)

Is the source of 2.5.1.4 test available anywhere as a .zip / tar.gz?

Patrol1985 said:

Is the source of 2.5.1.4 test available anywhere as a .zip / tar.gz?

I can svn checkout it for you:
https://dl.dropboxusercontent.com/u/235592644/files/prboom2.zip

Thanks Entryway! Are there any reasons why the test hasn't become the official 2.5.1.4 yet? Are there bugs present or something?

http://www.doomwadstation.net/main/otakon.html

I tried it on 2.5.1.3 prboom-plus on Linux. It almost worked--the replacement of the Marine's head in the status bar with Priss, and the cursor on the level select screen, didn't work.

Testing it with Doom Legacy 1.45 shows it still works on that. Chocolate doom refused to even play it, claiming "Sprite MISL frame A is missing rotations", so it could be a bad wad file. However, presumably the bad wad file works on original PC Doom, so ports really shouldn't just reject it.

With Chocolate Doom, you probably need to load the wads with -merge (or maybe -aa) instead of -file, and the dehacked patch with -deh.

I don't know why the marine head and cursor replacement don't work in PrB+ (maybe because the images are larger than the normal doom2 ones?) but I can confirm they don't in 2.5.1.4.test on Win32.

I tried using -merge on Chocolate Doom. You're correct; that makes it work there including the cursor and head. So it's just prboom-plus where it doesn't work.

How do I report a bug? There is a tracker on the Sourceforge page for prboom-plus, but the majority of the bugs on it are over a year old.

arromdee said:
How do I report a bug? There is a tracker on the Sourceforge page for prboom-plus, but the majority of the bugs on it are over a year old.

Me too! Mee toooo! I finally just tried it (yeah I live in a cave), and found a bug within 30 seconds, probably because I use an odd keybinding: I use the WinKey for strafe. Which works fine til suddenly it doesn't work and I find myself with the Windows menu instead, and have to manually switch back to the PRB screen. (I don't think this is a Win-bug, because the same keybinding in other games that allow it doesn't have this problem.) It might depend on a previous keypress, perhaps of a key that's NOT bound in PRB+, but I haven't got it nailed down yet.

PRB+ has also twice decided to go from filling the screen above the taskbar to filling the *entire* screen, which right now I can't pursue as I'm hampered by a flaky monitor (soon to be replaced, I hope... it won't tolerate changes of resolution anymore).

I should perhaps remind folks of my fearsome repute as "the beta tester who can break anything". :D

OTOH -- took a quick look at 2.5.1.4, and many thanks for adding jumping. I normally use a DOS port with jumping and it's all sorts of fun, so was glad to see this.

Andrey, seriously, why are you not simply releasing r4384 as 2.5.1.4, finally? People are either using unversioned ".test" releases or even the old 2.5.1.3 release of 2011 (!) and I don't know what is worse.

I actually thought this was looong dead.

VGA said:

I actually thought this was looong dead.

So did I, but am glad to see not, cuz if those couple issues can be resolved... might be the first Windows port I can happily use. (15 years of using Fusion has pretty much ruined me. :) )

Tho... I thought it did commandlines in the console box, just like a DOS port?? but it flat ignores me (it pops up the "Which WAD?" window, but that's all). What am I doing wrong??

Rez said:

Tho... I thought it did commandlines in the console box, just like a DOS port?? but it flat ignores me (it pops up the "Which WAD?" window, but that's all). What am I doing wrong??

I suggest giving an example of the command line invocation you are using (and, ideally, a like invocation working with (say) Chocolate Doom or DOOM.EXE).

damerell said:
I suggest giving an example of the command line invocation you are using (and, ideally, a like invocation working with (say) Chocolate Doom or DOOM.EXE).

The same old

exename -file wadname -playdemo lmpname

that's worked forever... (tried with and without extensions) ...is it different in PRB+??