PrBoom-Plus, ver. 2.5.1.4

[Blondie]

This is unrelated to what you guys were discussing, but would it be possible, e6y, to create a config variable to force transparency off for Boom's translucent sprites in software mode? I know that "comp_translucency" technically already does this, but the problem is that it doesn't work at either the Boom or MBF complevels, which are the two complevels I use for playing Boom-compatible WADs.

The reason I ask is because I play on an old computer with a single-core CPU, and I get severe framerate drops whenever a lot of transparent sprites are on the screen at once, such as the plasma gun being fired at close range. Transparent sprites are already disabled at all complevels in OpenGL mode due to the sprites/walls sorting bug in GLBoom, but there is no way for me to achieve this in software mode other than to disable translucency altogether, which I don't want to do.

A config variable like "sprite_translucency," however, would easily solve this problem for those of us who still use legacy hardware and prefer the software renderer. Thanks in advance.

[Memfis]

You can use this deh patch for non-translucent things: http://gkburgess.mysite.wanadoo-members.co.uk/notransl.zip
edit: oops, link doesn't work. Ask vdgg/Grazza/myk, they should have it.

[Blondie]

That would work, although inconvenient. Wouldn't it just be easier to add a config variable that toggles sprite translucency in software mode? I don't see why this can't be done since transparent sprites are already universally disabled in GL mode.

Edit: Or you could simply expand the preexisting compat option "comp_translucency" to apply to all complevels. Either way, I think that transparent sprites need to be universally togglable in the engine itself for software mode users with legacy hardware.

[Blondie]

And since Memfis mentioned it (thanks, Memfis!), could somebody who still has Grazza's translucent things dehacked patches upload them somewhere, just in case Andrey decides not to implement a config variable? Grazza's old post contains broken links to both: http://www.doomworld.com/vb/showthread.php?s=&postid=593019#post593019

I still believe that PrBoom needs a way to universally disable transparent sprites internal to the engine, though, because having to use dehacked patches is inconvenient, unreliable, and confusing — particularly to anybody who isn't aware of them.

Edit: Nevermind. Myk attached the file here: http://www.doomworld.com/vb/showthread.php?s=&postid=871780#post871780

[fabian]

Graf Zahl said:

Well, ZDoom handles that patch properly. It wouldn't really be that hard to concatenate the lines if they end with a backslash, and strip out all those whitespace, isn't it?

The concatenation of the lines ending with a backslash isn't the problem, prboom-plus already does this properly. The blank lines that interrupt the [STRINGS] block are the problem here.

[Quasar]

fabian said:

The concatenation of the lines ending with a backslash isn't the problem, prboom-plus already does this properly. The blank lines that interrupt the [STRINGS] block are the problem here.

I can vouch for that.

BEX blocks tolerate neither blank lines nor, in some cases at least, comments (!!!!).

[fabian]

entryway said:

More tolerant parser will be a reason of increasing incompatible dehs

Nevertheless, would you accept a patch, though?

[entryway]

fabian said:

Nevertheless, would you accept a patch, though?

For skipping empty lines? You are welcome.

[fabian]

entryway said:

For skipping empty lines? You are welcome.

It's not *that* simple. :p

The problem is that the empty line is already eaten by the string parser deh_procStrings(), which has been called because of the "[STRINGS]" directive in the first line of that file. Since it cannot parse that empty line it returns to ProcessDehFile(), which reads the *next* line and expects another directive like "[STRINGS]" there (i.e. one of deh_blocks[i].key) but finds "E1TEXT = [...]" and thus fails for the rest of that file.

We need to tell ProcessDehFile() that if it does not find a valid directive in the current line, it should pass that same line again to the last valid deh_proc*() parser (i.e. one of deh_blocks[i].fptr()) or fail if there wasn't one bvefore (i.e. comments at the beginning of a file).

[Holering]

Fov-aspect ratio differs from vanilla doom:
see here http://www.doomworld.com/vb/source-ports/64638-source-ports-dont-render-doom-aspect-fov-properly/

[Blondie]

entryway said:

I added mlook to software mode to prboom-plus this night.

The new software mlook code distorted the sky in widescreen resolutions.

Added to the tracker: https://sourceforge.net/p/prboom-plus/bugs/229/

[Plut]

How to run server and record cooperative demos in PrBoom-Plus (including server's owner)?

[myk]

One guy runs the server from a command line. Each runs a command line for the client (a second one for the server guy). The command line can also be a shortcut or batch file or whatever, of course. Demos are recorded normally from the clients. In vanilla short tics (normal v1.9 demos), both need to record or the guy who doesn't needs the short tics parameter (unless this is automatic, not sure.)

[Andy Olivera]

This may have been asked before, but can we get rid of the 'SR50 on turns' option in future versions? Most TAS demos seem to use this, even though it's actually cheating, unlike straight SR50 automation. It was determined that it wasn't actually possible, right?

[Urban Space Cowboy]

Andy Olivera said:

This may have been asked before, but can we get rid of the 'SR50 on turns' option in future versions? Most TAS demos seem to use this, even though it's actually cheating, unlike straight SR50 automation. It was determined that it wasn't actually possible, right?

I certainly hope that the option won't be removed, because
(a.) it's out there anyway; deleting it in future versions will just encourage sticking with old versions or patching new ones
(b.) I wouldn't count anything that can be played back in whatever target engine (vanilla, Boom, MBF, etc.) to be "cheating" or not "actually possible"
(c.) I disagree that tool-assisted demos using ANY particular feature count as "cheating" as opposed to, y'know, tool-assisted

[abyrvalg]

As a taser, i'll throw in my opinion too:
(a) Someone will stick to older versions, someone won't. At least it will encourage more people to record "legit" tas runs, and i've already seen many tasers do so in the past years.
(b) turbo255 demos playback in vanilla too, so do strafe70 ones and so on. You can draw basically any input in a lmp file. The difference is that you can't actually create such demos in vanilla, or produce such an input by any means except for using that sr50-option, which is unique in its kind among all source ports. Imagine it was sr60 on turns instead of sr50. Suddenly sounds not so legit, right? Despite of being equally unachievable as of our current knowledge.
(c) didnt understand your point here.

I'll second Andy's question though. Was anything established about sr50 on turns being theoretically doable in vanilla? I remember seeing some weird unofficial driver on doomworld forums last year, which allowed injecting inputs and effectively tasing in vanilla, wonder if it's usable for that kind of thing. I dont remember any details though :{

[Memfis]

Is there any reason why 320x240 is disabled in the settings? (at least I can't get the resolution lower than 640x480) I would like to use it for e.g. very simple maps where there is nothing to look at and it's better to leave everything to imagination. :p

[entryway]

Memfis said:

Is there any reason why 320x240 is disabled in the settings? (at least I can't get the resolution lower than 640x480) I would like to use it for e.g. very simple maps where there is nothing to look at and it's better to leave everything to imagination. :p

Use windowed mode for resolutions which are not supported by drivers.

I've noticed that the newest SDL doesn't allow low resolutions even in windowed mode, so you need SDL.dll from 2.5.1.3 release

-geom 80x50w



Also you can resize prboom's window with mouse (hold shift for any resolutions)

[GreyGhost]

Memfis said:

Is there any reason why 320x240 is disabled in the settings?

Probably a victim of "progress". I've only one flat-screen monitor which supports that resolution, an old 5x4 aspect Acer, everything else (TVs included) expects at least 640x480.

[xepop]

Andy & jongo:
How do you define your "legal tas" rules? For example it is possible to turn while sr50 with -control parameter, but probably not without it.

[RjY]

entryway said:

-geom 80x50w

Hah! This makes the game surprisingly difficult. I managed to max map01 at 80x60 but at 40x30 I took too much damage that I didn't see coming in time.

entryway said:

I've noticed that the newest SDL doesn't allow low resolutions even in windowed mode, so you need SDL.dll from 2.5.1.3 release

Out of curiosity, which version do you mean by the "latest SDL"? I have 1.2.15 from Debian's repositories, it works fine in "postage stamp" modes.

[Sp00kyFox]

just to clarify: the new sector light mode "shaders" is supposed to emulate the behavior of the software renderer, right?
coudn't find any documentation about it.

[Creaphis]

I'm sure this has been discussed in a billion threads already, so if someone can just post some relevant links I'd be more than happy with that. I'm running a fresh Windows 8 install, and my default MIDI device is the Microsoft GS Software Wavetable Synthesizer. When MIDI output in PrBoom+ is set to MIDI then it's very loud even just one notch above zero. If I turn MIDI off completely then my sound effects turn off as well. When I change my "preferred MIDI player" to one of the other three options then I don't get any music as well, but at least I can still hear sound effects. If anyone knows how to make my computer be less dumb then that would be great.

[Dragonsbrethren]

Speaking of shaders, I'm almost sure I asked before, but is there any chance of getting the spectre fuzz shader options from GZDoom in the GL renderer? I definitely prefer the pixel fuzz shader to the plain shadow effect GLBoom is currently using when I want to use the hardware renderer (which, more and more, is most of the time now).

Edit: Support for No Rest For The Living's secret exit would be great too, now that there's an official PC version.

[Patrol1985]

Is there a way to properly play No Rest for the Living (nerve.wad) from the BFG edition using PrBoom+? By "properly" I mean with correct map names and music. There is a thread on Steam forums containing a fix (nerveinfo.wad), but it doesn't work for me. I tried to run it in this way:

glboom-plus.exe -iwad doom2.wad -file nerve.wad nerveinfo.wad

Unfortunately it didn't work (the doom2.wad comes from the original doom 2, not the BFG one). The map names and soundtrack are still assigned badly.

[entryway]

Patrol1985 said:

Is there a way to properly play No Rest for the Living (nerve.wad) from the BFG edition using PrBoom+?

Fabian Greffrath made some improvements to support BFG Edition.

Firstly, be sure you are using the lates prboom-plus from here:
http://prboom-plus.sourceforge.net/history.html

Then copy DOOM2.WAD and NERVE.WAD from BFG Edition to prboom-plus folder and just start "glboom-plus nerve".

Does it work?

[Patrol1985]

entryway said:

Fabian Greffrath made some improvements to support BFG Edition.

Firstly, be sure you are using the lates prboom-plus from here:
http://prboom-plus.sourceforge.net/history.html

Then copy DOOM2.WAD and NERVE.WAD from BFG Edition to prboom-plus folder and just start "glboom-plus nerve".

Does it work?

It doesn't. I downloaded the newest Prboom+ from the site (2.5.1.4 test release) and there is a slight improvement, because doom2.wad from the BFG edition works (it doesn't work in the latest stable 2.5.1.3 version). However, nerve.wad still has its issues.

What's funny is that BFG's Doom2.wad also has its map names wrong. Everything else is like ID wanted it to be - the splash screen is different, health packs have pills instead of crosses, secret levels feature zombies instead of SS soldiers etc. etc., but map31 is named "Wolfenstein" (instead of "IDKFA") and map32 is named "Grosse" (instead of "Keen").

Does it mean that map names and their respective soundtracks are stored outside .wad files?

[RjY]

Patrol1985 said:

[...] but map31 is named "Wolfenstein" (instead of "IDKFA") and map32 is named "Grosse" (instead of "Keen").

Does it mean that map names and their respective soundtracks are stored outside .wad files?

Although the level names on the intermission screen are graphics stored in the wad file, the names on the automap are hard-coded into the game engine. They can only be changed by wads using Dehacked patches or the like.

I expect nerveinfo.wad is using a Hexen/ZDoom-style MAPINFO lump to change them. One could make a Dehacked patch to change the names in Boom-based engines, but Dehacked can't change which map is considered "next", so accessing and returning from the secret level won't work properly no matter what you do... The author of nerveinfo.wad probably threw up his hands and went "ZDoom only!" ;-)

[Patrol1985]

So do I understand correctly that for the time being there is no way to play BFG edition's "No Rest for the Living" using PrBoom+ the way it was supposed to be played?

Also, entryway and RjY - thanks for quick responses!

[fabian]

Patrol1985 said:

So do I understand correctly that for the time being there is no way to play BFG edition's "No Rest for the Living" using PrBoom+ the way it was supposed to be played?

I think we can change the automap strings for levels 31 and 32 in bfg-mode as well. I am not sure about level music, level placement and secret exits, though, as I unfortunately don't have access to Doom 3 BFG currently. :(