PrBoom-Plus, ver. 2.5.1.4

[Gez]

Voros said:

I'm using D Touch 3.2 to run it.

You should have started with this.

[Danfun64]

Danfun64 said:

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'

I'm still having this problem. Any ideas?

[vadrig4r]

Danfun64 said:

I'm still having this problem. Any ideas?

Just a guess, but do you have libpng installed?

http://svn.prboom.org/repos/branches/prboom-plus-24/prboom2/INSTALL

[Danfun64]

Everything on that list has already been installed.

[entryway]

vadrig4r said:

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

Test build is available at:
http://prboom-plus.sourceforge.net/history.html

[RjY]

Danfun64 said:

I'm still having this problem. Any ideas?

IMG_SavePNG is an SDL2_image function, the screenshot code switched from using libpng directly to letting SDL2_image do the work. So you need libsdl2-image-dev installed now instead of libpng12-dev. Sorry about this! I've updated the packages list in the INSTALL file vadrig4r posted and updated all the autoconf tests to look for the SDL2 versions of libraries.

------------

Also another apology, you'll also need to rebind PrtSc (the Print Screen key) if you had it set to anything. SDL2 changed the keycode, which unfortunately PrBoom+ (and its ancestors) exposed to user configuration (it should have remained internal). The key still works (I use it for screenshots for example) but you will need to rebind it to whatever you had it bound to, or go into your prboom-plus.cfg and change key_screenshot (or whatever you used it for) to 0xfe. Again sorry about this, it was overlooked for years, only noticed when SDL2 renumbered its keycodes...

[Danfun64]

That was already installed as well.

[Danfun64]

I don't know what you guys did, but it's working now.

I'm still getting the mp3/ogg/flac not looping bug though.

[vadrig4r]

entryway said:

Test build is available at:
http://prboom-plus.sourceforge.net/history.html

Thank you so much entryway, this fixed the mouse problem I was having. Much appreciated keep up the great work guys.

[damerell]

Danfun64 said:

-I already mentioned the OS i am using.

When prompted; not in the bug report. What I was trying to explain to you is why your bug report was missing all kinds of potentially pertinent data.

-The Makefile.in in question was literally missing from the source distribution.

No, it wasn't. It wasn't missing because it doesn't belong there, because - as I told you once already - it is generated during the build process.

_A_ file was missing; revision r4469 shows it was "Makefile.am".

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

The point you have missed is that it's better to supply the whole thing in case it is needed.

[Danfun64]

Are you done listing my faults, damerell? Yes, I forgot to put OS info in the bug report itself, and yes I got the name of the file a little wrong. Nobody is perfect, and I did give the info when asked. Also, as you already saw, I did supply that whole log, but I wasn't sure everything else in the log was relevant.

If you were the one who submitted the fixes to the svn trunk, I apologize for my rudeness and ungratefulness. If you weren't, you could at least have been nicer about showing me what I did wrong, as opposed to the passive-aggressive tone you came off as.

If you were doing something important and I repeatedly told you the things you did wrong even after the issue was fixed, how would you feel?

[damerell]

Danfun64 said:

Are you done listing my faults, damerell?

The idea is not to berate you but that next time you report a bug in something you'll bear in mind that it's generally better to provide lots of information than almost none.

That said, I imagine I might have been a bit less tetchy had you resisted the crack about people wanting to "read the whole thing" and if you'd also believed me the first time I told you that Makefile.in wasn't missing from the source distribution, which it wasn't and isn't (and you may even find it useful in future to know that it's generated by the build process).

[damerell]

On another note, is there a hook to run some function automatically when an option is changed by the user?

[Xeriphas1994]

chungy, a bloody long time ago, said:

I was thinking along like the lines of Chocolate Doom as well where I'm able to set it to 1280x800 for my native laptop screen resolution, and it'll pillarbox the image to retain the game's 4:3 aspect.

In other words, is there a way to get the vanilla FOV, vanilla aspect ratio, and software rendered mode on non-4:3 hardware?  I couldn't find a response to that post and it's not mentioned in the sourceforge request list (open or closed).

If the answer is "only in the newest builds", that's fantastic (even though I cannot use those yet because I have a Mac).

Or I just need to wander around at graduation weekend and look for another CRT on the curb.  ^_^

[damerell]

I've just sent a pull request on github: https://github.com/andrey-budko/prboom-plus/pull/2

C&P from the pull request, it does this:

This patch changes the following HUD-related behaviour. I'm sorry it encompasses more than one thing; because it changes more than one option in m_menu.c, it doesn't nicely split into several patches.

1) Fix a rounding error in hu_stuff.c introduced by the ammo_color_behaviour option added by, er, me.
2) Change the spelling of that option from ammo_colour_behaviour because 3) introduces a variable called armor_color_behavior and all the other armor_foo variables use US spelling & if the variables aren't named consistently it's very annoying.
3) Add an armor_color_behavior option which allows the player to make the HUD and status bar armour display be green or blue based on the type of armour not the amount. This lets you try and avoid replacing 99 points of blue armour with a new green armour which will absorb less damage. The default is off.
4) add a hud_bar_maximum option which can change the behaviour of the health and armour bars. At the moment they go from 0 to 100. This option can let them go from 0 to 200 and/or respect dehacked changes to health and armour maxima. The default is to respect dehacked changes but still only to have the bars go up to the ordinary health / green armour maxima.

[kuchitsu]

I either forgot or didn't know to begin with... How to make prboom-plus create (and write to) stdout.txt? I tried creating an empty one by myself but that didn't change anything: it still appears empty after playing.

[Ribbiks]

are you just trying to redirect the normal console output (stdout + stderr) to a file?

./prboom-plus &> myText.txt

[kuchitsu]

OK, this works, thanks!

[noshutdown]

is there a "todo" list on what's being worked on?

[Danfun64]

I've discovered a bug which concerns the score tally screen. In this demo, the kill percentage in E1M1 is supposed to be 75% for me and 3% for the other person involved. That is how it appears in Chocolate Doom 2.2.1 (where the demo was recorded from) and when the demo is played back through Crispy Doom (I think the build is b0c0aba75cc61dc228726d17a18793ca21c98870) and doom.exe with the patch from here (yes, it's a longtics demo)

However, in the latest PrBoom-Plus, the results are 82% for me and 17% for the other person. I don't understand why PrBoom-Plus gives such different percentages...

Demo in question: http://www.mediafire.com/download/3mvm9n9kvoe7ao5/coope1p1.lmp.zip

Yes, the zip is too big for the Speed Demo Archive, and yes, a real demo is in there.

edit: to get to the important part quickly, -skipsec 270

[damerell]

Danfun64 said:

I've discovered a bug which concerns the score tally screen. In this demo, the kill percentage in E1M1 is supposed to be 75% for me and 3% for the other person involved.
However, in the latest PrBoom-Plus, the results are 82% for me and 17% for the other person. I don't understand why PrBoom-Plus gives such different percentages...

And of course you haven't said anything about difficulty level, respawn, complevel, etc., because you still think bug reports should be minimalist.

Modulo rounding, 82% and 17% make 100%. I suspect (almost) all the monsters were killed but some were killed by infighting. If this is the case, code in p_inter.c from line 689 onwards is responsible.

In single-player Doom, all kills are attributed to the player, which means you can get 100% kills even with infighting. In co-op (vanilla or vanilla-like ports) infighting kills just disappear. In prboom an infighting kill is always attributed to a player, but which? Compatibility level doesn't do what one might expect. As I read it:

  if ((compatibility_level < lxdoom_1_compatibility)

If this lower complevel is set, if the dead monster had a target, that target is a player, and that player is still alive, they get the kill. Otherwise we give the kill to the first player who's in the game (which is a bit unsatisfactory).

If complevel is higher, the same procedure is followed except that "Otherwise" the kill is given to a player at random.

There is no complevel which gives the vanilla behaviour of infighting kills vanishing.

Before you have another go at me, please observe that I have done my best to answer your question in spite of the limited information you provided. You don't have a bug report; you might have a feature request.

[Danfun64]

Sorry.

The demo was recorded in Chocolate Doom 2.2.1 with Ultimate Doom as the iwad, so I set the -complevel to 3 in PrBoom-Plus. The difficulty level is UV -fast. For those who haven't looked at the demo, there was some monster infighting involved.

I guess the problem is the vanilla disappearance of infighting kills.

Thanks for explaining what the problem is. Here is the feature request. https://sourceforge.net/p/prboom-plus/feature-requests/100/

[damerell]

It would be easy enough to patch this to give the vanilla behaviour by complevel but I wonder if infighting kills vanishing is felt to be so buggy it should need an extra option to turn it on, kind of like how there's no complevel that will give you a visplanes overflow?

[Danfun64]

Well damerell, it's time to do this dance again. :P

For whatever reason, new videos recorded with -viddump don't sync properly. Old videos still sync right, just not new ones.

I have no idea whether this issue has to do with an update to prboom-plus or ffmpeg, or if it's a completely different issue altogether.

To reiterate, I am using Xubuntu 15.10 x86_64 with all the latest updates.

The zip file I am about to link to contains a video that has been desynced from the initial -viddump encode (A small portion of the E1M9 from the demo linked earlier), along with video_stderr.txt, sound_stderr.txt, and mux_stderr.txt.

http://www.mediafire.com/download/zt8gyiyrdog3m8n/prboom-plus.zip

Also, the terminal output (https://paste.debian.net/hidden/eb7bac35/) and a list of all files in my prboom-plus directory (just in case by any chance this problem is related to all the files in the directory) (https://paste.debian.net/hidden/cbcd50e6/)

[GoneAway]

In the most recent 2.5.1.5 test build, my mouse sensitivity is noticeably different than in 2.5.1.4, with the same exact settings in the config file, also verified in the interface in-game. Using a higher sensitivity seems to be able to reproduce the desired speed (maybe around a factor of 2?), so I don't think there's any smoothing going on.

[vadrig4r]

vadrig4r said:

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

entryway said:

Test build is available at:
http://prboom-plus.sourceforge.net/history.html

Mouse input was recently tweaked (and solved the deceleration issues I was experiencing) so it's probably that update you're noticing.

[Danfun64]

I'm such an idiot. My problem was related to the cap_fps variable. Somehow it reset itself from 30fps (which I set it to) to 60 fps. Combined with ffmpeg's "-r 30"...

The only question I have left is how it reset itself in the first place.

edit: Funny how the more serious problems were the ones that I gave too little information, and the one where I gave a lot of information turned out to be user error.

[cybermind]

This demo desyncs in newest PrBoom+ 2.5.1.5, but plays correctly in PrBoom+ 2.5.0.2 (where it was recorded)

[entryway]

cybermind said:

This demo desyncs in newest PrBoom+ 2.5.1.5, but plays correctly in PrBoom+ 2.5.0.2 (where it was recorded)

see r4379 description

[Danfun64]

I may not be cybermind, but I have to ask. How do I find descriptions of prboom-plus svn commits? The main trunk doesn't give any descriptions, and the github mirror doesn't give a clear idea of svn commit numbers.