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

PrBoom-Plus, ver. 2.5.1.4

Recommended Posts

Dime's new 30ev TNT movie record desyncs in map21 with the latest stable pr+ (most probably the test versions too). Use -skipsec 2180 to see it.

Kaiser divined that it might be a stairbuilding desync and indeed, stdout screams about it:

T_MovePlane: Stairs which can potentially crush may lead to desynch in compatibility mode.
 gametic: 76055, sector: 113, complevel: 4
T_MovePlane: Stairs which can potentially crush may lead to desynch in compatibility mode.
 gametic: 76055, sector: 114, complevel: 4
This is repeated for the following ten tics. The offending crushed things (103 and 104, I think) seem to be two imp corpses that Dime manufactured partially over the stairs before they get built. The guilty stair steps actually go past a lower ceiling that is probably crushing the corpses. This is how it looked when I -recordfromto'd into the scene: http://i.imgur.com/8rYQtwc.png

The demo plays back properly with chocolate and CNdoom.

<KaiserAtWork> yay legit pr+ bug
<dew> it's exciting to catch budko with his pants down
<dew> that came out wrong

Share this post


Link to post

In the ports I tested, chocolate doom and cndoom worked and prboom+ desyncs at map 21. Fails in vanilla as well though....??? hmmm

Share this post


Link to post

It's probably chocolate doom thing, cndoom is based on it. Prb+ emulates it vanillaesque way so that's why it doesn't playback in vanilla nor prb+.

Share this post


Link to post

This is really strange. When I watched the demo, it did desync in MAP21. I thought that prboom+ played it back with complevel 2 by default, added complevel 4 to the command line, and it played back correctly up to the end.

Now that I read these posts, I tried again. First just used -playback and -warp 21 parameters. Demo desynced. Added -complevel 4. It still desynced. I scratched my head trying to remember how I was able to playback it earlier, tried adding -complevel 2. It didn't even warp to MAP21. Hmmmm. Tried even -complevel 3, of course didn't warp. Then tried -complevel 4 again, and magic - it played back correctly!

After that, it played back every time I tried, both with -complevel 4 added and without any parameter given. I wanted it to revert to desyncing and even rebooted, but now it just plays back the demo correctly, and I cannot reproduce the desync! Only with forced complevel 2 it does not warp to MAP21.

Oh, and I'm using prboomp+ 2.4.3.3. Yes, THAT old! Don't know if this is important for this particular case.

Share this post


Link to post
Donce said:

Oh, and I'm using prboomp+ 2.4.3.3. Yes, THAT old! Don't know if this is important for this particular case.

It's always important. If you get bugs (in this case, demo desyncs) with an old version, always try to see if the problem still exists with the latest version (in PrBoom+'s case, that would be 2.5.1.4.test currently).

Share this post


Link to post
Donce said:

and magic - it played back correctly!

Behavior is random with old versions of prboom (EV_BuildStairs does not init crash field), that's because you have different results for different ways.

Share this post


Link to post

OK, tried a bit more.

Prboom+ 2.4.8.3 - always desyncs at the chaingunners.
Prboom+ 2.5.1.3 - always desyncs at the chaingunners.

Now, with 2.4.3.3 it's more interesting. After running 2.5.1.3, it desyncs immediately after climbing the stairs (just before chaingunners). But next time, with the same command line, it plays back correctly.

And this is reproducible. I run 2.5.1.3, desync at the chaingunners, then run 2.4.3.3, desync at the stairs, 2.4.3.3 again, all fine.

So old versions tend to desync the first time, and may do it differently, but repeated tries play back the demo fine.

Share this post


Link to post

Suppose I could always just try and get another exit and ignore those imps but i'd really rather not. Is there any other good playback methods out there that has graphical enhancements?

Usually when I would get a demo I would re-record using gl or prboom+. Can't really do that if the demo desyncs.

Share this post


Link to post

http://www.chiark.greenend.org.uk/~damerell/games/ammocount2.patch is a new version of the ammo patch linked above that tries to address fabian/myk's preferences by adding a 3-way option, "BACKPACK CHANGES THRESHOLDS" (and no, I could not think of a better name that fits on the screen) which is either "no", "full ammo only", or "yes". "no" is what fabian describes. "full ammo only" means that a backpack doesn't change red/green/yellow thresholds, but blue means full ammo. The default is "yes" because that is closest to the behaviour of prboom-plus pre-patch. It also now displays blue on the traditional HUD as appropriate (it doesn't display brown for no ammo, for reasons discussed beforehand.)

The obvious question will be "Why did you change ST_X and ST_Y in m_menu.c to SB_X and SB_Y?" Because with this patch m_menu.c wants some stuff from st_stuff.h but st.stuff.h #defines ST_X for st_stuff.c to use in another way entirely.

Share this post


Link to post
Platinum Shell said:

I was afraid of that...I haven't the faintest idea how to do that.


Just out of curiosity, what patches would you like to apply. Could you show them?

Share this post


Link to post

On my older desktop computer, I use PrBoom+ at 320x200 and it works fine. On this newer notebook, it "works" with screen multiply but doesn't stretch the pixels, so it all looks flattened out. I suppose some setting is missing on the operating system that makes it stretch.

I'm using 320x240 instead, which is good enough since I can barely tell the difference. Except that the status bar and HUD graphics look a bit worse when scaled to the "Doom format". In Odamex I can minimize this issue by using 640x480 with vertical and horizontal low detail. If PrBoom+ had this low detail feature, newer systems could easily have a good-looking low res that's hard to distinguish from the old 320x200 without having to mess with obscure system or driver settings!

Another option is using Chocolate's scaling method for 320x200 or 640x400, but I'm suggesting or requesting the above because I assume it's easier to code in or incorporate.

Share this post


Link to post

Oh, I would love to see the option for getting the vanilla 320x200 look. ZDaemon recently added it, so awesome!

Share this post


Link to post

Prboom-plus' launcher loads veeeery slowly for me, usually takes more than one minute, sometimes two. It wasn't like that a few months ago, what could be the cause? Do I just have too many wads now? (over 3000 I guess)

edit: yay, fixed by using the "rebuild the prboom-plus cache" command.

Share this post


Link to post

I think I'm using prplus v2513 (dec04/2011), and using the grid on the automap doesn't show where the blockmap actually is.

Share this post


Link to post
TimeOfDeath said:

I think I'm using prplus v2513 (dec04/2011), and using the grid on the automap doesn't show where the blockmap actually is.

what? screenshots please, what you see and what you want to see

Share this post


Link to post

I think the prplus grid always shows 128x128 blocks at X/Y coordinates that are multiples of 128, like 128/512, -896/256, etc., instead of showing the blockmap lines (the doomwiki says the automap grid shows the blockmap).

Unless I'm wrong, I think the blockmap starts at the farthest west/south point where the lines intersect in the yellow circle and 128x128 blocks are built from there.

Share this post


Link to post

That looks correct to me. The blockmap doesn't start at precisely the bottom-left-most XY coordinates of the map, there is an additional offset that expands the whole thing (8 mapunits I seem to recall) so that collision detection vs axis parallel lines on the map boundary works correctly.

Share this post


Link to post

Ok thanks, that explains why the grid in chocodoom is slightly off from the farthest west/south coordinate. The prplus grid is different from the one in chocodoom though: I don't think it uses the blockmap at all, it just places a grid on the automap using the same multiples of 128 coords every time (opening a map in doom builder with grid at 128 shows how the automap grid looks in prplus).

Share this post


Link to post

Ok thanks, 2513 also has that option. I just thought it was a bug that the prplus grid (with cellsize = 128) wasn't lined up with the blockmap. I guess when coding the grid cell size option it was easier to draw a grid using the cell size setting starting at 0x/0y, instead of keeping the grid lined up with the blockmap?

Share this post


Link to post

scifista42 found out DeHackEd mods giving weapons multiple shots fired in one click can result negative ammo in -complevel 9 (with ill effects like being stuck in an endless loop between weapons, with certain weapon loadouts). Where as in -complevel 2, as long as you have CheckReload states the weapon will correctly stop firing at 0 ammo.

I don't know if this bug can be fixed without causing problems with compatibility, or whether fixing it at all would even be a consideration, but it seemed interesting enough to mention.

Share this post


Link to post

Based on a little testing, this appears to be mimicking the behaviour of Boom 2.02 correctly, which is what you want -complevel 9 to do.

So I'd say this isn't a bug at all, unless it isn't emulating Boom 2.02 correctly in some respect (in that case, a demo of the unreplicated behaviour would be useful).

In -complevel 15 and above (including -1) the problem does not occur. There were a whole bunch of improvements in dehacked support around that time (in the 2.2.x-2.4.x range).

Share this post


Link to post

In -complevel 15 and above (including -1) the problem does not occur.


Ahh, cool. Is there a way to know what exact changes are tied to each complevel?

Edit: thanks. My main concern being whether usual -complevel 9 behavior breaks or changes significantly in those upper complevels, I could just set complevel 17 as default and play Boom maps for a while to see if something happens.

Share this post


Link to post

I don't know of any nice neat summary, especially when it comes to fine-detail stuff like this.

There's a table for how each the "comp_" settings is set for each complevel (either on, off, or user's choice), but I strongly suspect this isn't controlled by one of those, and is just a line in the code somewhere. You could find that by searching through the code, but that's not a very user-friendly process.

Share this post


Link to post

Whenever I change the lighting mode to 'Shader' and close the game, it always reverts to 'GLBOOM' is there a way to make this stick?

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
×