PrBoom-Plus, ver. 2.5.1.4

[Ashstrodamus]

Edward850 said:

The correct answer is that Doom has a major problem with "close range misses at point blank range" (technically not the exact situation for the issue). PRBoom+ cannot afford to fix that without dropping demo compatibility, a rather critical and intended aspect of the port.

I guess I never really noticed until playing wads and playing at a higher level of competition as regular ass Doom doesn't exactly require you to be up in the face of monsters.

[RottingZombie]

Does anyone know how to turn off vsync in v2514?

I changed use_doublebuffer to 0 to no effect (i read that used to be use_vsync or something), the game when capped runs at 30 instead of 35fps, and even if i try uncapped there's terrible mouselag. All my graphics card settings are good and no other port has this issue.

[VGA]

RottingZombie said:

Does anyone know how to turn off vsync in v2514?

I changed use_doublebuffer to 0 to no effect (i read that used to be use_vsync or something), the game when capped runs at 30 instead of 35fps, and even if i try uncapped there's terrible mouselag. All my graphics card settings are good and no other port has this issue.

Are you running the software executable or the opengl?

[RottingZombie]

Software, I tried openGL but didn't like the blurry textures. I get the correct 35fps in GL mode with capped framerate though.

[dugan]

RottingZombie said:

Software, I tried openGL but didn't like the blurry textures. I get the correct 35fps in GL mode with capped framerate though.

Set your Texture Filter Mode and Sprite Filter Mode to "Nearest Mipmap", and you have OpenGL without the blurry textures.

[RottingZombie]

Will try, thanks. I turn off filters in zandronum and GZDoom, I didn't even think to look around in PRBoom because I didn't plan on using GL mode at first

[Linguica]

Joe-ilya noticed that in a Youtube of an Evilution TAS you can clearly see the player appear to be beneath the floor directly after teleporting:

IIRC the Final Doom engine doesn't reset the player's Z-position upon teleporting. I'm working off the assumption that the video was recorded in prboom-plus and it seems like this is not playing well with the interpolation code, causing the player to teleport beneath the ground and a frame or two is rendered before the engine notices and resets the player's Z position to the new ground level.

Maybe this has fixed since this video was recorded, or I'm wrong altogether, but I thought it was worth noting at least.

[joe-ilya]

I contacted the video author and he said the following :

yeah, no problem. it was 2.5.1.4.test. can't figure out a more specific version number but here are some data about the file which will probably help to identify it:

name: prboom-plus.exe
size: 1.961.984
CRC: 90D9668C
created: 2015-05-06 20:48
changed: 2015-06-18 17:13

[RjY]

In one tic the player is teleported, which as you say, in (and only in) final doom compatibility, does not set player z to the destination floor height. player z is not corrected until P_ZMovement in the next tic.

Thus you have one D_Display call where the player view is below the floor, which shows up in the video. It's not caused by uncapped framerate specifically.

[Danfun64]

So...is it possible to playback final doom id anthology demos in prboom-plus? If so, how?

[damerell]

Ashstrodamus said:

I guess I never really noticed until playing wads and playing at a higher level of competition as regular ass Doom doesn't exactly require you to be up in the face of monsters.

If you play on -fast pinkbeasts and invisibeasts turn up in your face whether you wanted any or not...

[Sp00kyFox]

entryway said:

I added cap_fps config variable for smooth viddump.

'--fps 35' part of cap_videocommand command line could be changed to '--fps %r' for auto replacement.

this is awesome, thank you! it makes 60fps video dumping so much more convenient. before that I always played a demo in slowmo and recorded it with dxtory.

[Danfun64]

Danfun64 said:

So...is it possible to playback final doom id anthology demos in prboom-plus? If so, how?

...nobody has an answer?

[Chris Hansen]

Danfun64 said:

So...is it possible to playback final doom id anthology demos in prboom-plus? If so, how?

Do you mean the pre-recorded demos that start shortly after the titlescreen? The demos that come with Plutonia Experiment and TNT:Evilution? If yes, then I just start the game with -complevel 2 and let the demos run. They seem to run just fine without going out of sync or anything.

[noshutdown]

Danfun64 said:

So...is it possible to playback final doom id anthology demos in prboom-plus? If so, how?

cl2: doom(1 or 3 episodes version) and doom2
cl3: ultimate doom(4 episodes version)
cl4: final doom(common version)
i heard that the id anthology version of final doom behaves like cl3 instead of cl4.

[Danfun64]

Chungy said complevel 3 won't work properly with final2 demos here

edit: Then again, axdoom1 said it would work on the same thread. Weird.

[VGA]

The sample wad that Linguica posted here is glitchy in prboom, there's a HOM:
https://github.com/chocolate-doom/chocolate-doom/issues/660

[Voros]

We know prBoom+ supports freelook in OpenGL, but it is limited to viewing the environment. Is there a way to disable Autoaim in PrBoom+?

[plums]

Yeah, Allow Vertical Aiming, it's under "Compatibility with common mapping errors". Options -> General -> Right arrow key x6.

[Linguica]

VGA said:

The sample wad that Linguica posted here is glitchy in prboom, there's a HOM:
https://github.com/chocolate-doom/chocolate-doom/issues/660

What are you talking about, it worked fine in prboom-plus when I tried. Were you using software or hardware renderer?

[vadrig4r]

Linguica said:

What are you talking about, it worked fine in prboom-plus when I tried. Were you using software or hardware renderer?

Works fine for me in both software and hardware for the last stable release (2.1.5.4). Works fine in software for the last test realease, HoMs in hardware for me (2.5.1.5.test). So a test release 'issue'?

Might as well throw in a bug I'm having:

If I alt-tab it seems the alt key gets 'locked' and the game behaves as if it's still being pressed after switching back in. Most visible when you try to load a game by pressing enter after alt-tabbing and alt-enter is sent instead switching from fullscreen to windowed mode.

Steps to reproduce:

1. Launch game fullscreen
2. Alt-tab out
3. Select game window from taskbar/alt-tab back
4. Press enter
5. Program becomes windowed

Windows 7 SP1 PrBoom-Plus 2.5.1.4 and 2.5.1.5.test.

I also seem to experience mouse decelleration/skipping which is particularly noticeable at high DPI and low resolution (640x480). I use a Logitech G400s at 800 DPI that I know doesn't have any issues with decell/skipping (in other games or other source ports such as Crispy/ZDoom/the original .exes). This is something I was hesitant to report because it was reasonably difficult to notice and the potential difficulty in reproducing it. Experienced in prboom-plus.exe and glboom-plus.exe, use_doublebuffer 0 or 1.

[Danfun64]

I'm confused by Sourceforge's Priority setup. Does 1 mean top priority or does 9?

The reason I ask is because "configure.ac:292: error: required file 'src/TEXTSCREEN/Makefile.in' not found"

In other words, I can't compile. Fixing this issue should be top priority.

https://sourceforge.net/p/prboom-plus/bugs/243/

[damerell]

Danfun64 said:

In other words, I can't compile. Fixing this issue should be top priority.

Easily done with your exhaustive description of the build environment?

[Danfun64]

I compiled PrBoom-Plus successfully before on the same system. But if it will really help, the OS I was using to compile is Xubuntu 15.10 64-bit.

edit: what does a missing file have to do with my build environment? I did a clean checkout of the latest prboom-plus, ./bootstrap , and I get that error.

[damerell]

Danfun64 said:

edit: what does a missing file have to do with my build environment?

I don't know. I do know that people very, very rarely make the error of including too much data in a bug report, and I don't think you were in any immediate danger of that, with no mention of

* what OS you were using
* what you invoked to download what you think is the latest version (don't angrily respond that of course you got it right; it's entirely possible that you did - and if you did that is best demonstrated by putting the command you ran in the bug so there is no doubt on that subject - and you might have got it "right" from svn, via git clone from github, or by grabbing the latest source tarball)
* whether you know that Makefile.in is generated by the configure script or whether you literally think it's missing from the source distribution
* whether other Makefile.in files have been generated at this point
* whether you followed any of the other instructions in INSTALL and, if so, what they output

What this leaves anyone reading the bug wondering is whether _no-one_ can compile (top priority, but hard to check with no real indication of what version you're trying to compile) or whether _you_ can't compile (low priority, quite possibly not a bug but pilot error on your part.)

What you want is a situation where anyone reading the bug with access to a similar Linux system can immediately run the same commands you did and, you hope, get the same result. That's good for them - they know there's a widespread problem - and it's good for you - the person who can fix your problem isn't wondering if it's just you.

[RjY]

It's not just him, a file went missing during the switch to sdl2. This is being worked on. Sorry.

[Danfun64]

damerell said:

I don't know. I do know that people very, very rarely make the error of including too much data in a bug report, and I don't think you were in any immediate danger of that, with no mention of

* what OS you were using
* what you invoked to download what you think is the latest version (don't angrily respond that of course you got it right; it's entirely possible that you did - and if you did that is best demonstrated by putting the command you ran in the bug so there is no doubt on that subject - and you might have got it "right" from svn, via git clone from github, or by grabbing the latest source tarball)
* whether you know that Makefile.in is generated by the configure script or whether you literally think it's missing from the source distribution
* whether other Makefile.in files have been generated at this point
* whether you followed any of the other instructions in INSTALL and, if so, what they output

-I already mentioned the OS i am using.
-Through the terminal I typed in "svn checkout https://svn.prboom.org/repos/branches/prboom-plus-24/prboom2/ prboom-plus && cd prboom-plus && bootstrap"
-The Makefile.in in question was literally missing from the source distribution.

RjY said:

It's not just him, a file went missing during the switch to sdl2. This is being worked on. Sorry.

aaaand another port loses compatibility with windows 9x. Oh well...

I don't remember you announcing such a big change as a switch to sdl2 though.

edit: I got a new error while trying to compile, this time near the end instead of the beginning.

https://paste.debian.net/hidden/74d73a8c/

For those who don't want to read the whole thing...

SDL/libsdldoom.a(i_sshot.o): In function `I_ScreenShot':
/home/danfun64/Documents/doom-src/prboom-plus/src/SDL/i_sshot.c:69: undefined reference to `IMG_SavePNG'

[RjY]

Danfun64 said:

I don't remember you announcing such a big change as a switch to sdl2 though.

I was just as surprised as you. Couple of weeks ago this giant 10k-line patch landed in my inbox—I went and hid behind the sofa.

[Voros]

plums said:

Yeah, Allow Vertical Aiming, it's under "Compatibility with common mapping errors". Options -> General -> Right arrow key x6.

Its not there.

I'm using D Touch 3.2 to run it.

[vadrig4r]

Is it possible mouse input behaviour was affected by the transition to SDL2 (as mentioned in my above post)?