PrBoom-Plus, ver. 2.5.1.4

[Never_Again]

noshutdown said:

one reported here:
http://sourceforge.net/p/prboom-plus/bugs/240/

Two more off the top of my head:
#211 bnb2_na.lmp desyncs in vanilla
Missedbackside Overflow emulation in Prb+

Both deal with Prb+ recording vanilla-format demos that desync in vanilla, each for a different reason.

noshutdown said:

but yeah, such cases have become pretty rare in recent years.

Yeah, they have; but when they continue to pop up and go on without being resolved as the years go by while such a barebone (comparatively speaking) port as Chocolate Doom starts to outshine the demo powerhouse that is Prb+ in compatibility department you can't help feeling disconcerted.

Linguica said:

I think it's high time to polish up the current codebase and release 2.6, if only for the wigglefix (which is really essential for playing software mode in high resolution).

You seriously think that the wigglefix merits a new version number while the rest of the issues mentioned earlier in this thread and on the bug track remain unresolved? And did you notice the big fat zero that is the developer's response to all of those issues? It's staring you and everyone else in the face but has apparently become "the elephant in the room".

It's going to take a lot more than polishing to make the compat options system alone user-friendly and intuitive, not to mention the desync issues. And this is not going to happen unless someone with considerable knowledge, skill and motivation steps up to the plate and forks the project. Barring that, Prboom-plus is doomed to die in the same quiet peaceful manner as its predecessor.

[ReFracture]

Linguica said:

I think it's high time to polish up the current codebase and release 2.6, if only for the wigglefix (which is really essential for playing software mode in high resolution).

Absolutely, that wigglefix is a must have.

Never_Again said:

And did you notice the big fat zero that is the developer's response to all of those issues?

Yeah.. I've been saddened by that, I figured maybe entryway's just putting it on the back burner while he deals with other stuff but he never really said anything.

[Szymanski]

I have a demo recorded with prboom-plus -complevel 9 which will crash at apparently random times. Do I need to add the -complevel 9 when playing the demo back? I assumed it would autodetect.

[entryway]

Szymanski said:

I have a demo recorded with prboom-plus -complevel 9 which will crash at apparently random times. Do I need to add the -complevel 9 when playing the demo back? I assumed it would autodetect.

You should not. Do you use the latest build? Software mode? Does the level have music changer thing (IIRC, music changer code calls z_malloc from another thread, but it's not thread safe)?

[Szymanski]

I'm using v2.5.1.4, software mode fullscreen 1600x1200. Level uses boom effects (floor and ceiling light transfer linedefs, floor height transfer) but no music changer or other special things.

I can send the files if that would help. I don't know what build was used to create the lmp, I'll ask.

[noshutdown]

according to this post from chocolate team, the cause of the reverie desync has been found:
https://github.com/chocolate-doom/chocolate-doom/issues/530

it seems related to vanilla's thinkers and memory management. that is, even vanilla doom may desync its own demos if running with different amount of heapsize, did i get it right?

anyway, at least complevel2/3/4 should behave closely to vanilla, right? maybe you can add a "preserve vanilla limits" option for cl2/3/4:
when on, it preserves vanilla's limits just like chocolate.
when off, it works as a limit-removing vanilla port.

[Szymanski]

entryway said:

You should not. Do you use the latest build?

I've tested with 2.5.1.4 in a new directory and the demo plays perfectly. Looks like user error, sorry.

[Afterglow]

Szymanski said:

I've tested with 2.5.1.4 in a new directory and the demo plays perfectly. Looks like user error, sorry.

To the gallows with you.

[clarry]

Bug: if a key is bound to autorun, then any cheat requiring that key will not work. I happen to have autorun bound to i, so none of the vanilla cheats work for me...

It's processed in M_Responder whereas for cheats it'd need to reach ST_Responder. For now I'm changing the return at autorun to false as a workaround.

[Memfis]

Also if I type IDMUS but don't type any numbers, my first two attempts at pressing the arrow keys don't do anything, is that normal?

[scifista42]

@Memfis: This has always been normal, same with IDCLEV.

EDIT: Well, it's normal since Boom. Vanilla and Chocolate Doom don't behave that way, but Boom and all Boom derived ports do (including ZDoom based ones).

[Never_Again]

clarry said:

Bug: if a key is bound to autorun, then any cheat requiring that key will not work. I happen to have autorun bound to i, so none of the vanilla cheats work for me...

This is a subset of bug #216 on the tracker.

[Linguica]

Just came across this on Map29 of Hellbound, in the middle of the final arena. Software renderer, 2.5.1.4.

[joe-ilya]

What I get in any other port (including vanilla) :

What I get in GL/PRboom :


EDIT:The new GL/PRboom version also can't play chex.wad as an Iwad now, a very previous version I played with; had support.

[entryway]

Linguica said:

Just came across this on Map29 of Hellbound, in the middle of the final arena. Software renderer, 2.5.1.4.

Can't reproduce. Savegame, please.

[entryway]

joe-ilya said:

EDIT:The new GL/PRboom version also can't play chex.wad as an Iwad now, a very previous version I played with; had support.

How to reproduce? I have only PWAD from http://chexmania.tripod.com/downloads.htm and it works fine.

[joe-ilya]

entryway said:

How to reproduce? I have only PWAD from http://chexmania.tripod.com/downloads.htm and it works fine.

I downloaded the version you posted, but:

[Rez]

Didn't they re-release ChexQuest as a PWAD?

[entryway]

joe-ilya said:

I downloaded the version you posted, but:

Works for me.

prboom-plus -iwad CHEX.WAD

2.5.1.4 from http://prboom-plus.sourceforge.net/history.html

[VGA]

entryway said:

Can't reproduce. Savegame, please.

Happens here, too:
http://s000.tinyupload.com/index.php?file_id=76808218723902075637

Load it with HBFM29.wad, not the main wad. I used software renderer of some 2.5.1.4 (built Jan 31 2015)

EDIT: Load the standanole dehacked, too, otherwise the stdout gets flooded with errors.

[entryway]

VGA said:

I used software renderer of some 2.5.1.4 (built Jan 31 2015)

Outdated.

[VGA]

I updated and the glitch doesn't happen. At least not at that spot.

[noshutdown]

entryway said:

Outdated.

hello entryway, can you give some info on whats being worked on recently? how many bugs are currently known to remain unsolved, and when do you think the 2.5.1.4test would be a formal stable release?

[fabian]

joe-ilya said:

I downloaded the version you posted, but:

From the PrBoom-Plus icon in your Windows task bar (showing the original IWAD resource) it becomes clear that the PrBoom-Plus version you use is *heavily* outdated.

[joe-ilya]

But I use the one provided at the OP.

[fabian]

joe-ilya said:

But I use the one provided at the OP.

But the OP is "Last edited by entryway on May 28 2009 at 15:12"!

Always use the version provided at the top of this page:
http://prboom-plus.sourceforge.net/history.html

[joe-ilya]

It works now, thanks and sorry for disturbing, just fix that wierd graphical error I posted earlier.

[fabian]

joe-ilya said:

It works now, thanks and sorry for disturbing, just fix that wierd graphical error I posted earlier.

As absurd as this may sound, I think it has to do with your choice of colors. If I extract the TITLEPIC lump, change its colors in Gimp and rebuild the WAD file, the title is displayed correctly.

[Never_Again]

Two unrelated graphical issues.

* case A: HOM in latest test version *

TNT MAP09


Perdition Gate MAP29


DOOM2.WAD (CRC-32 EC8725DB as per Wiki) used as the IWAD in both cases (a lot of Compet-N Final Doom demos use D2 as the IWAD).
Latest test version from May 6, unzipped into a new directory and run with the default config.
Affects both the GL and the software (used for the screenshots) renderers.
Using TNT.WAD as the IWAD fixes the HOM on TNT09, but not PG29.
This issue doesn't exist in the stable v2.5.1.3 or v2.5.1.4-test from August 2012.


* case B: Armadosia MAP32 in GL *



The entire first section of the map (the original as well as v2) is displayed glitchily.
Doesn't seem to be HOM, as TNTHOM doesn't make it flash red.
Looks fine in the software renderer and GZDoom's GL renderer (dev build 2.1.pre-1159 from June 4).
Unlike case A, this is not a new problem, I just tested v2.5.0.6 and got the same result.

[fabian]

I can confirm the HOM on TNT09 with "-iwad doom2.wad -file tnt.wad", but not the one on PG29.