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

PrBoom-Plus, ver. 2.5.1.4

Recommended Posts

@Rathori Oh my god, thank you so much. The problem the whole time was that I was putting it in the wrong /Library/Application Support (Why is there two?). As it turns out, the Library in Users (the correct one in this case) is hidden, and unhiding in MacOS is a bit more obfuscated than it is in Windows (as seems to be the case with just about everything). I had Chocolate running without issue, but I much prefer PrBoom+.

 

Thanks so much again for putting up with all my shit, hopefully I won't have to bother you anymore.

Share this post


Link to post

Hello everyone. I have strange issue with demo playback.

I downloaded last revision of PrBoom-Plus sources (from SVN repo) and built binary on MacOS. Then i recorded UV-MAX demo of one hella-big slaughtermap. This demo plays back correctly on this MacOS version of PrBoom+ but gets desynced on exactly same revision on windows/linux (built from exactly same sources). Desync happens after 86th minute. What could cause this?

 

Also if anyone here uses Mac too please test this demo file. Does it play back correctly?

 

PWAD and demo in attachment. Demo was recorded with "complevel 9". IWAD is doom2.wad

hhr.zip

Edited by cryoniq

Share this post


Link to post
2 hours ago, cryoniq said:

Also if anyone here uses Mac too please test this demo file. Does it play back correctly?

 

Greetings, I tried to play your demo back in prb+2.5.1.5 on mac, and it desynced at about 86 minutes. So I don't think it's an OS thing.

 

What version of prb+ did you use, specifically? 2.5.1.5test, or the 2.5.1.7 umapinfo fork? Can you share the exe that plays the demo back correctly?

Share this post


Link to post
8 hours ago, Ribbiks said:

What version of prb+ did you use, specifically? 2.5.1.5test, or the 2.5.1.7 umapinfo fork?

 

Thank you for reply. As I mentioned earlier I built binaries from last 2.5.1.5 sources (link). It's the official repo, not UMAPINFO fork repo.

 

8 hours ago, Ribbiks said:

Can you share the exe that plays the demo back correctly?

 

I can but I don't really think it's necessary. Last PrBoom-Plus app from Alexey Lysiuk's repo works well for me too (plays demo back correctly) whereas 2.5.1.4 from his repo has exact same issue. My friend also discovered that 2.5.1.5r4493 app plays demo back correctly too and it's the first 2.5.1.5 release in AL's repo after 2.5.1.4.

 

Here's a link to comparing changes between these versions/revisions.

Share this post


Link to post
17 hours ago, cryoniq said:

I can but I don't really think it's necessary. Last PrBoom-Plus app from Alexey Lysiuk's repo works well for me too (plays demo back correctly.

 

Interesting, so r4523 plays back the demo successfully, but the version I currently have installed on my comp doesn't (compiled in August 2019, so probably... r4539). But you're saying the demo was recorded on the latest? i.e. r4543?

Share this post


Link to post
12 hours ago, Ribbiks said:

But you're saying the demo was recorded on the latest? i.e. r4543?

 

Yes. I compiled r4543 and used it to record that demo. Once again I'll mention that I downloaded sources from SVN (not from AL's repo) and compiled it by myself. 
BTW me and my friend tested all app packages from AL's repo with 2.5.1.5 version and we had no desyncs. I suspect the compilation process or compiler might be a problem. Can you describe please how exactly you compiled your r4539?

Share this post


Link to post
2 hours ago, cryoniq said:

Can you describe please how exactly you compiled your r4539?

 

Some of this is out of date now (see some of the recent posts from Rathori in this thread), but this is more or less what I did:

 

Share this post


Link to post

So we've narrowed down the list of suspects to:

  • 32/64-bit error in PrBoom+ code happening only on macOS (?)
  • A compilation process error (bad configure/makefile, compiler version, flags, etc.)
  • SDL (1 or 2) version/build

We created a virtual machine with clean macOS installation, set up the build environment, grabbed all the dependencies, and built 32-bit and 64-bit versions of PrBoom+ (2.5.1.5 r4543). The results are interesting: the 64-bit version plays the demo back correctly without any demo desync; the 32-bit version however desyncs at the same time Windows, Linux and AL's macOS 2.5.1.4 builds do. As such the problem is in something listed above. 

 

Here's how I produced the builds:

  1. Installed macOS 10.13.6 (17G66, latest App Store version, no security updates); I used VMware Fusion for that
  2. Installed Xcode 9.4.1 (9F2000, build from Apple Developer website (login required))
  3. Installed command-line tools (xcode-select --install)
  4. Installed Homebrew and all dependencies listed here (except SDL2) plus autotools and pkg-config through it
  5. Built fat SDL2 (2.0.10 from SDL website) using instructions from here
  6. Built PrBoom+ 32-bit version using the instructions here but with additional flags to configure: ../configure CFLAGS=-m32 CXXFLAGS=-m32
  7. Built PrBoom+ 64-bit version using the same instructions but with no additional flags

The resulting binaries exhibit the behavior mentioned above. Please see if you can reproduce this.

Share this post


Link to post

I have macOS Catalina, so no 32-bit build, but my 64-bit build also doesn't desync on mac, and I can confirm that it does desync on Windows in 2.5.1.5.r4526.

 

Also I would say that suspect #1 should be simply "32/64 error", but whether it's specific to macOS or happens on all OSes with 64-bit prboom+ is to be determined. I suspect that you've recorded your demo on a 64-bit build, and due to some 32/64-bit error in the code the demo wasn't recorded properly, and thus only plays back properly in 64-bit prboom+.

Share this post


Link to post
8 minutes ago, Rathori said:

whether it's specific to macOS or happens on all OSes with 64-bit prboom+

 

I also tested it on 64-bit Linux build (under Ubuntu 19.10) and it desynced much like it did on Windows and 32-bit macOS builds.

Share this post


Link to post

I'm shocked a little of how the operation system is involved in video recording process. When my OS was installed on an HDD, the loseless -viddump recording speed in Full HD was about 14 fps. Now it's installed on an SSD, a video is still saved on an HHD, but process is 6 times faster. What a paradox! How does it work?

Share this post


Link to post
2 hours ago, Rathori said:

@Dimon12321 most likely, the temporary files are saved to the SSD during the encoding process.

During the recording process, a video and an audio files are created in the PrBoom+ folder. When a demo is finished, they get merged together. You can even open them if you adjust this line in the config file:

cap_remove_tempfiles          0

 

I think x264 can utilize the speed of SSD since it's operated by the OS.

Share this post


Link to post

So we've figured out the problem is not on Mac only but it can be reproduced on Linux if you compile 64-bit binary using clang. On Mac clang is used by default and as such the problem appeared. We compiled 64-bit PrBoom+ on Linux issuing these commands before compiling:

export CC=/usr/bin/clang
export CXX=/usr/bin/clang++

 

The resulting binary plays the demo back correctly as does the Mac 64-bit binary. Alexey Lysiuk's fork builds do not have the problem as they use cmake as the build system. This leads me to believe the configure script is broken and contains some kind of dangerous compiler flag that breaks something only on 64-bit builds produced with clang.

 

We will be investigating this further and try to figure out which flag is responsible for this.

Edited by cryoniq

Share this post


Link to post

Is there a way to disable the render of arch-vile's fire? Especially in tandem with BFG, sometimes there's a lot of s**t on the screen I barely see anything.

Share this post


Link to post
7 minutes ago, Spectre01 said:

@Dimon12321 Do you have translucency turned on?

Yes, it's set to 1. I turned it to 0, but it doesn't seem to change anything.

Share this post


Link to post
17 minutes ago, Spectre01 said:

Are you using GL or PRBoom+ and on which complevel/map format?

PrBoom+ (inside XDRE 2) on -complevel 2. The WAD is vanilla-compatible, so the map format seem to be "Doom: Doom 2". Tried in GLBoom+, but the fire still surrounds me, no matter of translucency option.

Share this post


Link to post

Try loading trans_on.7z to enable projectile translucency. You will still see Vile flames, but they won't completely block your view and the transparency can be adjusted in the menu (default is at 66%). Normally, PRBoom+ only has projectile/flame translucency in Boom or MBF formats, while GLBoom+ doesn't support it at all. I have no clue as to why since it's able to display translucent midtextures just fine by default.

Edited by Spectre01

Share this post


Link to post

I have a dumb question: Does PrBoom+ properly support MAPINFO in the same way ZDoom or other such ports do? I'm a little bit confused because I always just assumed that this wasn't the case, but I keep finding MAPINFO lumps in maps aimed at Boom compatibility.

Share this post


Link to post

@Agentbromsnor It does not. There is a fork with UMAPINFO but that's not the same thing. MAPINFO lumps are frequently included in Vanilla or Boom maps because many people play those in GZDoom. Same with EMAPINFO for those running Eternity, though that one is less common to see. 

Share this post


Link to post
1 minute ago, Spectre01 said:

@Agentbromsnor It does not. There is a fork with UMAPINFO but that's not the same thing. MAPINFO lumps are frequently included in Vanilla or Boom maps because many people play those in GZDoom. Same with EMAPINFO for those running Eternity, though that one is less common to see. 


Right, I expected as much. Thanks for clearing that up. How does one configure the map names in Boom maps?

Share this post


Link to post
21 minutes ago, Agentbromsnor said:


Right, I expected as much. Thanks for clearing that up. How does one configure the map names in Boom maps?

With Dehacked. You can use Whacked to create a deh file on Windows.

Share this post


Link to post

What does demo_insurance parameter actually do? I found a strange thing in XDRE 2.20 when setting a savepoint at a specific tic leads to a desync if I change any input after it, and I results immediately (like I changed not a tic X, but a tic X-200 and then fast-forwarded the demo by 200 tics). So I think there might be a problem with RNG and that parameter will prevent it somehow. Maybe, it's a tool bug, but still, what does demo_insurance do?

Edited by Dimon12321

Share this post


Link to post

@goldenblue That's the sky dome effect when using freelook. The original texture only has so much height, so it ends up fading into a colour if you look up/down too far. I think that's how it is in most OpenGL ports, while in Software the sky ends up stretching with freelook.

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
×