Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
entryway

PrBoom-Plus, ver. 2.5.1.4

Recommended Posts

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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post
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 (!!!!).

Share this post


Link to post
entryway said:

More tolerant parser will be a reason of increasing incompatible dehs

Nevertheless, would you accept a patch, though?

Share this post


Link to post
fabian said:

Nevertheless, would you accept a patch, though?

For skipping empty lines? You are welcome.

Share this post


Link to post
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).

Share this post


Link to post

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

Share this post


Link to post

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.)

Share this post


Link to post

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?

Share this post


Link to post
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

Share this post


Link to post

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 :{

Share this post


Link to post

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

Share this post


Link to post
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)

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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?

Share this post


Link to post
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?

Share this post


Link to post
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!" ;-)

Share this post


Link to post

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!

Share this post


Link to post
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. :(

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×