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

PrBoom-Plus, ver. 2.5.1.4

Recommended Posts

That's how vanilla worked and prboom-plus inherits this behavior.

It's not really such a bad thing. In some cases it is even desired (glides, for example, are a lot easier to set up this way).

For some complevels you can add the -longtics parameter to get around it.

Share this post


Link to post

It is possible to move the mouse all the way across your mouse pad with out the character turning at all. If you try the same thing in Chocolate or Crispy Doom you should be able to see what I am getting at - they still have the coarse quantisation, but without the loss of precision between "steps".

So I did a bit more informal testing between PrBoom+, Chocolate Doom and the original DOOM2.EXE in Dosbox. It seems that PrBoom+ (when, as you said, recording a demo on lower complevels such as 2) behaves very similarly if not identically to the original .exe in Dosbox. Mouse counts (or data in-between 'steps' if you like) seem to be discarded between the visible 'jumps' when the player's view angle updates. Chocolate Doom seems to keep track of the mouse counts/movement between view angle updates and thus sees more frequent 'jumps', particularly at lower mouse velocities.

So, for example, moving your mouse very slowly at a low DPI and mouse sensitivity it is possible in PrBoom+ and DOOM2.EXE in Dosbox for the player view angle to not update at all; in Chocolate Doom the same behaviour will see regular (albeit infrequent) view angle updates.

I don't know to what extent SDL is muddying the waters here, as all systems use it: SDL2 for PrBoom+ and SDL 1.x for Chocolate Doom and Dosbox. As kuchitsu said it seems to be that PrBoom+ replicates Vanilla behaviour. If anyone remembers exactly or has access to an actual DOS-capable system without having to use Dosbox it would be interesting to see if Dosbox's behaviour is identical to the original.

This is really getting into the minutiae of things I know, it's more out of curiosity than suggesting something is wrong. All testing was done with the latest git/svn builds of the respective software (and DOOM2.EXE v1.9).

Share this post


Link to post

Thanks for doing that vadrig4r, I should have thought to try dosbox but it didn't occur to me. Seems like prboom is doing it's job admirably. Still, having extra precision wouldn't do any harm.

kuchitsu said:

That's how vanilla worked and prboom-plus inherits this behavior.

It's not really such a bad thing. In some cases it is even desired (glides, for example, are a lot easier to set up this way).

For some complevels you can add the -longtics parameter to get around it.

It was hard to explain, but it wasn't the low turning resolution itself I was talking about (which goes away entirely with longtics), but the way the mouse movement was interpreted.

However, I wasn't aware of -longtics (which is awesome) until you mentioned it, so I'll use that. It's way better than increased precision on shorttics.

Share this post


Link to post

In chex quest, if playing with advanced hud, on map 3, while recording and playing back demos, prboom+ crashes randomly, with error code 11 or just silent exit. It doesn't happen with normal hud. Shock had a problem with desyncs on map 3 as well while using advanced hud. It doesn't happen if I'm not recording/playing back demos, even with advanced hud on.

Example: prboom-plus.exe -iwad chex.wad -deh chex.deh -complevel 3 -skill 4 -warp 1 3 -record c1q3 -maxdemo 2048 -levelstat -nomusic

With this command, it crashes consistently as I open the door to the right at the start of the level (but only with advanced hud on). This is in 2.5.1.4, stable.

Also, levelstat does not work on the final map of chex quest (no intermission screen)

Share this post


Link to post
kraflab said:

In chex quest, if playing with advanced hud, on map 3, while recording and playing back demos, prboom+ crashes randomly, with error code 11 or just silent exit. It doesn't happen with normal hud. Shock had a problem with desyncs on map 3 as well while using advanced hud. It doesn't happen if I'm not recording/playing back demos, even with advanced hud on.

Example: prboom-plus.exe -iwad chex.wad -deh chex.deh -complevel 3 -skill 4 -warp 1 3 -record c1q3 -maxdemo 2048 -levelstat -nomusic

With this command, it crashes consistently as I open the door to the right at the start of the level (but only with advanced hud on). This is in 2.5.1.4, stable.

Also, levelstat does not work on the final map of chex quest (no intermission screen)

Chex quest has a really wide player face - maybe it's being drawn off-screen?

Share this post


Link to post

IIRC there is a Medusa right there? Is it possible PrBoom+ chokes on it in demo compatibility mode?

Share this post


Link to post

It's possible to record demos with saves on some old complevels but not others -- for example, -cl 9, which starts your demo at the latest save point when you quit and record a demo with the same file name. With -cl 2 it just overwrites the file, however. Any reason for the difference in behavior?

Share this post


Link to post
BrainMuncher said:

Yeah it reminds me of the feeling of an old ball mouse when the ball would stick, so your hand would move but the cursor would not.


Right, and only while recording a demo, and only at lower -complevels. There's no issue at -complevel 17, presumably because it's not even trying to do the low-res turning thing when compatibility isn't a factor (same goes for zdoom).

At first I thought my mouse was dying or had some fluff in it or something, I didn't assume it was prboom because people seem to recommend it for demo recording.


ive noticed this today also. i too thought my mouse was on the blink or that i was going mad for a second!

edit:

found a page on the Doom Wiki about it: http://doom.wikia.com/wiki/Turning_resolution_is_lowered_when_recording_demos

Share this post


Link to post

Can we get a new boom derivative compatibility that behaves the exact same as -cl 9 with a single exception, that it doesn't push monsters over the edge of the sector?

Would be greatly appreciated.

Share this post


Link to post

Why do you want that? If that isn't something you can either configure in Boom or is available on a patched version of boom, I don't think that's gonna happen.

Share this post


Link to post

To put it simply, because that setting is absolute rubbish. It impairs gameplay by randomly getting monsters stuck mid-air unless you put monster blocklines on every surrounding sector available, which just creates additional hassle for the mapper. There's not a single benefit from it except an occasional headache and nobody would miss that option if it were suddenly gone.

Making a new different -cl which fixes just this (and maybe other boom bugs) would make boom mapping a tiny bit less annoying and maybe sometime even replace -cl9 altogether as a recommended complevel for boom oriented maps.

Share this post


Link to post

It also won't have demo compatibility with anything but PrBoom-Plus, and deliberately testing with altered behavior doesn't seem right...

Share this post


Link to post

@j4rio: But some wads rely on dropping keycards (or barrels, monsters, voodoo dolls, other critically important things etc.) off ledges via conveyor belts (or via explosions that push but don't kill the object).

Share this post


Link to post

I'm fairly certain that isn't so much of a problem to go around, not that I know a tint about coding.

Anyway, I'm sure a sort of boom bugfixing "add-on", whether compatible only with prb+ latest versions, would be appreciated.

Share this post


Link to post

Yes, I would always use it. Shittiest Boom "feature" by far.
Also sky transfers for cl2 would be niiice. :D

Share this post


Link to post

I wonder if this sort of thing could be done with a combination of cl17 or -1, and manually setting comp_dropoff in the config file? It was never clear to me how those complevels behaved wrt user-specified config options (i.e. do custom settings get saved somehow in the .lmp to ensure it plays back the same, or does cl-1/17/etc have its own set of hard-coded options?).

Share this post


Link to post

I recorded a couple coop demos in MBF 2.04, and they both crash in PrBoom-Plus, whether I am using -complevel 11, -complevel 11 -force_correct_code_for_3_keys_doors_in_mbf, -complevel 17, or no complevel at all. Just a generic segmentation fault error. Both players are me.

https://www.doomworld.com/vb/post/1583969

What makes this more annoying is that for whatever reason, MBF 2.04 coop is smoother in Dosbox compared to Boom coop.

Edit: Oh, and before damerell yells at me again, one computer was running Xubuntu Linux 15.10 x86_64 using Dosbox Daum 20140127_32bit (newer versions don't work on 64-bit platforms) and the other computer was running Windows 7 Home Premium (latest service pack and patches) 32-bit using Dosbox Daum 20150125_32bit

Both were able to connect to each other, but both were fairly slow, and as mentioned earlier, Boom was even worse. Maybe speed would go faster if both platforms were using the same version of Dosbox Daum?

edit 2: If you want, I'll try again with both computers using the latest stable version of Dosbox.

I am now using Dosbox 0.74 on both platforms. On a hunch, I decided to switch from Allegro's digimidi driver to the opl3 driver (on boom at least). Not using software synthesis emulated inside DosBox speed Boom up dramatically. Upon testing with MBF 2.04 with OPL3 music, it was also much fast than it was with Allegro's digimidi. Still get a segmentation fault though. So I have eliminated the emulator as a factor. I am reporting this bug to the MBF 2.04 dev.

edit 3: Demos recorded from MBF 2.03 (MBF_Fixes) don't crash. Go figure.

Share this post


Link to post

MBF 2.04?

PrBoom doesn't know anything about MBF 2.04 and 204 (0xCC) demo format.

You can try to add:

  case 204:
    compatibility_level = mbf_compatibility; // (???)
    demo_p++;
    break;
between case 203 and case 210 to prevent crash at start

Share this post


Link to post

MBF 2.04 compatibility might be a problem, because there are multiple versions of the post-lee MBF release labelled "2.04", I don't know if anyone has been able to track how many, or what changed in each, and what impact that would have on demo playback.

Share this post


Link to post

MBF 2.04 has a changelog. Note that it's based off the latest mbf-with-fixes (precompiled mbf-with-fixes exe here)

Spoiler

-- DOOM 'MBF' VERSION HISTORY --

Major Credits:

1) Doom is a 1993 science fiction horror-themed first-person shooter (FPS) video game by id Software.
Engine Programming was done mainly by John Carmack.
The Doom source code was released December 23, 1997
(Linux port, without DMX sound library and original Mode-X planar graphics routines).

2) Boom is a source port created by TeamTNT. The design goals of the Boom project were to create
a source port of professional quality, fix bugs and remove limitations of vanilla Doom, and add
extra editing features, while keeping the same "feel" and "spirit" of the original Doom engine.
The final version of Boom was released on October 22, 1998. (v2.02)

3) MBF (Marine's Best Friend) is a source port created by Lee Killough after he left the Boom team.
It is regarded by some as Boom's successor. As with Boom, MBF was limited to running under MS-DOS.
MBF was relicensed under the GNU GPL. Latest MBF source and executable release by Killough is v2.03
from 1/8/1999.

Minor Credits:

4) Simon Howard 'Fraggle' worked on the above sourcecode in 2000, and offers it as mbf-with-fixes,
albeit without a compiled executable.
It includes License change to the GPL, some bug fixes and compilation fixes under later versions of Allegro.
-bug with 3key doors! (p_spec.c)
-blur effect fix (r_draw.c)
-stereo fix for allegro v3.12 (i_sound.c)
-bugfixes from lxdoom (z_zone.c) (VM block size bug/Memory wastage/...)
-fix asm (m_fixed.h / r_things.c) (GB 2014: now overwritten with julian's fixes)


5) Gerwin ("GB") worked on mbf-with-fixes
http://members.quicknet.nl/lm.broers/

2013:
- Version changed to 2.04.
- Integrated Julian's compiler fix from Eternity Engine v3.33.02, as described on 06/12/01,
  including a new local allegro.h. (not yet including the inline ASM fixes)
- use param -ssg to enable supershotgun from doom2 in doom1, Requires ssg.wad resources.
- game automatically looks in the \iwad subfolder, when no iwad found in base directory. (d_main.c)
- The game+setup is compiled with a modded Allegro 3.00 Sound Blaster 2.0/Pro driver.
  Consisting of a sample rate fix for Sound Blaster Pro Compatible Sound Cards, such as the Crystal CS4232,
  which does not accept a DSP request for over 43478Hz in SB Pro emulation mode.
  At startup it also flushes DMA transfers that may still be pending.

2014:
- startup console now resembles the original look, with colored title bar (d_main.c).
- startup console lists wads and sound devices in more bright text (w_wad.c) (i_sound.c)
- compiler check in i_sound.c for allegro version: either 3.00 or later. (still no proper game exit with 3.12...)
- display sound and music device in startup console (i_sound.c)
- Changed Mode-X to flip between 2 pages instead of rotating between 4 pages. for next point:
- Added Dirty/Clean check to only transfer the full Statusbar to the video memory when necessary. Small FPS gain. (i_video.c)
- Added doomu.wad to iwad list (d_main.c).
- Safe mode invoked whe Windows NT OS is detected (d_main.c). See -safe parameter.
- Doom version 1.2 demo compatibility (from PrBoom+).
- Proper detection and selection of when to use VESA Banked or LFB access.
- Alternate hi-res blitting for modern ATI/AMD video cards.
- Automatic 640x480 video mode fallback when 640x400 is not avialable.
- option to show the framerate on the top right, obviously capped at 35 max. (mostly i_video.c).
  will now also show the video mode driver on the top left, whenever it is switched.

General bugfixes which have been found and documented by other people in the past:
- Poor memory scanning bugfix from PrBoom (z_zone.c)
- Format string bugfix from PrBoom (d_deh.c / i_main.c)
- Spawned monsters respawn at 0,0 bugfix (p_mobj.c)
- Demo Compatibility bugfix in T_MovePlane from PrBoom (p_floor.c), but with P_CheckSector.
- Demo Compatibility bugfix in P_CheckSight and P_CrossSubsector from PrBoom (p_sight.c)
- Demo Compatibility bugfix in P_SlideMove (p_map.c)
- Demo Compatibility bugfix in "Overlapping uses of global variables" (p_map.c)
- Demo Compatibility bugfix "MBF player bobbing rewrite causes demo sync problems" (p_user.c)
- Bugfix "DR doors corrupt other actions" (p_doors.c)
- Doom v1.2 Demo compatibility from PrBoom, all Credits to the PrBoom author(s)
  (g_game.c, p_enemy.c, p_floor.c, p_inter.c, p_map.c, pmaputl.c+.h, p_sight.c, p_spec.c)
- for upload no. 004: eternity fix; must check fileout for validity (d_deh.c)

Compiler Compatibility (GCC 4)
- Integrated Julian's fix from Eternity Engine v3.33.02, as described on 06/12/01:
  "fixes to the inline assembly in m_fixed.h and r_things.c that remove actual bugs in Killough's code,
  and also enable compilation on GCC 2.95.* and later. Unlike the lxdoom code, Julian's code does not
  seem to break wall sliding or any other game engine behaviors." (m_fixed.h / r_things.c)
- Changed wrong predefenition (p_spec.h): int EV_DoElevator ( line_t* line, elevator_e    elevtype );
- Commented out 5x useless and conflicting predefenitions (r_bsp.h)
- haleyjd: syntax fix in EV_DoGenCeiling (p_genlin.c)
- Commented out 2x useless and conflicting predefenitions (p_mobj.h)
- Found culprit of -O2 / -O3 Floating point errors: FixedDiv (m_fixed.h). Boom's FixedDiv is OK.
- Removed unused 'Secnum' from p_doors, and 'cheatstate' from am_map.c, and 'length' from g_game.c
  and 'episode' from p_spec.c and 'lh' from wi_stuff.c
- added (char *) typecast to variables in string handling routines (g_game.c)
- added (byte *) typecast to variables (d_net.c)
- added (char *) typecast to variables (d_deh.c)
- added string.h to emu8kmid.c
- Restored ability to compile without DOGS feature, m_menu.c d_main.c. Game only gets slower without options?
For upload no. 004:
- fixed compiler warning "++eventtail" undefined (d_net.c)
- fixed 4x compiler warnings, dereference pionters for sizeof (g_game.c)
- register heightmask changed to register int heightmask (r_draw.c))
- changed *src++; to ++src; (w_wad.c)
- Replaced m_fixed.h with the one from SMMU, old one tended to give 'Floating point errors' when using compiler optimizations
- Found and fixed serious bug concerning in_graphics_mode vs. disk_flash_icon. This bug surfaced when using GCC 2.9+

New startup parameters (2014):
-noasm    To use the C column+span drawing functions instead of the assembler ones: faster on some systems. (r_plane.c,r_segs.c,r_draw.h,r_draw.c,r_things.c)
-noasmx   For new C transfer routine of buffer to Mode-X planar screen. (mostly i_video.c)
-asmp6    To force use of ASM Pentium Pro transfer routine of buffer to Mode-X planar screen. (mostly i_video.c)
-nolfb    To prevent Linear frame buffer mode when using 640x400. Initially the game did not detect when to use VESA Banked or LFB. (mostly i_video.c)
-safe     Does not use nearpointer VGA access, Does not allow video mode-X (through not allowing page flipping option). Shows video mode driver on the top left, whenever it is switched.
-stdvid   Basic video settings 320x200; Mode 13h or VESA equivalent.
-bestvid  Best Quality video settings; High resolution etc.
-unlock   Unlocks the protection that prevents mods to load with a shareware Doom iwad
-nopm     Do not use Protected Mode bankswitching and pageflip in VESA video modes. Use real mode VBE 1.0 routines instead.
-lowdet   Low Detail Mode, rendering half the horizontal resolution (2015)
-noDehWad Do not load Dehacked lumps found inside WADs (2015) 

V2.04 Release History
Upload no. 002: v2.04 had broken the savegame functionality, now fixed (g_game.c)
Upload no. 003: 2014-09-27 replaced SHLDL instructions, as done in Duke3D / Doom Legacy. Gives 20% more FPS on Pentiums. (drawspan.s)
Upload no. 004: 2014-10-05 Now reliable results when using the latest DJGPP+GCC
                (This does require a more recent version of cwsdmpi.exe, and in windows 95/98 DPMI memory has to be set manually)
                Most if not all video access rewritten, added i_vgavbe.c, Video access now totally independant of Allegro
		(Display of the Disk Icon on the bottom right is currently disabled)
		Added 320x200 VESA mode support, replaces mode 13h+X when suitable
		Added: Hold Shift at startup to remain at bootup console
		Removed "number of player corpses option" as it was reported to cause network desyncs when changed
		Compiled with an allegro without hi-color mode support, also compiled without the Allegro Graphics drivers
Upload no. 005: Rewrote VESA page flipping and vsync, as Nvidia cards malfunctioned before
                Screen should shake a little when enabling page-flipping
		Vesa version now shown in mode string
Upload no. 006: Bugfix for 640x480 pageflipped which got broken, also added clearscreen beforehand.
                Fixed the pageflipping routine for NVidia cards.
                Switching into of mode-X got slightly broken, now fixed
                Made video modes + options selection and handling more resilient
		Added a message when video options are not avialable
		Removed translucency percentage option from the main screen to make room
Upload no. 007: 2014-10-13 Added Protected Mode bankswitching and pageflip routines (VBE 2.0). Frame rate increase is not impressive...
                Introduced parameter: -nopm.
		Fixed a bug where the frame rate counter messed up a variable from the the timedemo measurement.
                Intel GMA specific: LFB mode blank-screen procedure for intel graphics, as banked functions do not work in LFB mode!?
		 (note on intel GMA graphics: page flipping in windows XP will not really work, but it works fine in DOS)
		Centered the screen in 640x480 LFB mode
                Vesa modes now intialized with the LFB bit set (worked without though)
		Replaced conio.h with gppconio.h
Upload no. 008: Rewrote shift=pause at startup console
                Compiled allegro with bugfix in adlib driver (in fm_set_pitch), FM timbres now sound a lot better
		Compiled allegro with the doom 1 GB FM timbres as build-in default. Drums have not been replaced (yet)
		When using a Doom2 based iwad FM timbre file MBF_D2GM.IBK is loaded, which has a few modified  instruments
		Themed setup.exe, and allegro.cfg is now replaced with setup.cfg
Upload no. 009: 2014-10-25 Modified adlib driver again: added Doom timbres for percussion. Now uses MUSlib lookup tables.
		Improved look of setup.exe.
Upload no. 010: 2015-10-13 Added -lowdet parameter to invoke low detail graphics: rendering half the horizontal resolution.
                This should give about 10% more frames per sec.
                (The low detail drawcol and drawspan are only in C code, not in hand crafted asm)
		Now compiled with gcc493
		Renamed dprintf to dmprintf, for DJGPP 2.05 compatibility.
Upload no. 011: 2015-12-26 Added -noDehWad parameter to not load Dehacked lumps found inside WADs (d_main.c) 
                Again Rewrote shift=pause at startup console, as to disregard CapsLock.
Upload no. 012: 2016-01-04 Added 'Windows Sound System' (WSS) Digital Sound Driver: 16 bit Stereo, up to 44100 Hz.
		As the game currently does not obey setup.cfg, use the ULTRA16 environment variable to pass the details:
		For example "SET ULTRA16=530,1,7" for IO=0x530, DMA=1, IRQ=7. 
		This is digital driver number 7 in the game config. Tested with CS4232 SoundCard.
Upload no. 013: 2016-01-23 
                Removed MBF internal sound driver selection entirely. It now always loads setup.cfg settings. 
		The settings screen now displays the Sound and Music driver, with sufficent detail.
		Tweaked WSS sound driver. 
		Restyled setup.exe dialogs a little. Replaced the setup.exe font.
Upload no. 014: 2016-01-31 (C)
                Backported Allegro 3.12 ESS Audiodrive Sound Driver. Tested OK.
                Backported Allegro 3.12 Ensoniq Soundscape Sound Driver. Unable to test.
		Added Gus PnP (InterWave) Sound driver. Tested OK. Actually already worked with WSS driver.
		Note that the GUS PnP Music interface is not included.
		Changed WSS environment variable, example: SET WSS=A530 I7 D1
                GUS PnP now uses the ULTRA16 environment variable, example (6=dma/5=irq): SET ULTRA16=34C,6,5 
		Improved WSS driver.
		Reverted back to 1997 Compiler software.

Share this post


Link to post

That's good. Hypothetical question: If someone had a given mbf.exe, knew it was 2.04 but not which upload, could one reliable figure it out?

Share this post


Link to post

Hypothetical Answer (:P)

I don't think so. Only the latest version of MBF 2.04 is available from the VOGONS forum link at any given time.

Share this post


Link to post
j4rio said:

Can we get a new boom derivative compatibility that behaves the exact same as -cl 9 with a single exception, that it doesn't push monsters over the edge of the sector?

Would be greatly appreciated.

Wow, I see this request a lot. I always kinda liked when you could shoot a monster off a ledge without him dying. Easily noticable in E1M9 where you step on the invisible lift and it drops you down to the outdoor room with the 3 columns, each with an imp. Many times you can shoot one of the imps and he falls without dying. I guess it could also drop monsters into inaccessible places, which would suck.

But, why all the hatred for this setting? (Just curious).

Share this post


Link to post
Danfun64 said:

Oh, and before damerell yells at me again


I was trying to help you, you idiot. You get your bugs fixed faster - or your issues explained - when you say what's going on.

Share this post


Link to post
damerell said:

I was trying to help you, you idiot. You get your bugs fixed faster - or your issues explained - when you say what's going on.

Dude, do you have Asperger's? Legit question :D

Share this post


Link to post

I don't know anything about damerell's mental health, but I can say for sure that I have Aspergers.

Share this post


Link to post

You two are cute, kiss and make up danfun64 and damerell!

kb1 said:

Wow, I see this request a lot. I always kinda liked when you could shoot a monster off a ledge without him dying. Easily noticable in E1M9 where you step on the invisible lift and it drops you down to the outdoor room with the 3 columns, each with an imp. Many times you can shoot one of the imps and he falls without dying. I guess it could also drop monsters into inaccessible places, which would suck.

But, why all the hatred for this setting? (Just curious).


Well j4rio said above his reasoning was it being a pain for mappers having to work around monsters becoming stuck mid-air. I don't whether that's most people's reasoning or not though but I can understand it.

Share this post


Link to post
vadrig4r said:

You two are cute, kiss and make up danfun64 and damerell!

Well j4rio said above his reasoning was it being a pain for mappers having to work around monsters becoming stuck mid-air. I don't whether that's most people's reasoning or not though but I can understand it.

I wasn't aware that that setting caused monsters to get stuck in the air - the opposite, in fact. But, I suppose it's different when you also implement over/under code. Interesting.

Share this post


Link to post

"Stuck in mid-air" of course means "stuck on the edge of a ledge", or "stuck on a sufficiently steep staircase", etc. Imagine that you view the map from top-down perspective, and see the monster's collision box as a square. From all points inside this square, pick the point with the highest floor height, and then pick the point with the lowest floor height. If the height difference between them is greater than 24 units, and the monster can't move out of such a position* within a single call of A_Chase, the monster becomes stuck.

*So that in the new position, the height difference between the lowest and highest floor under the monster's collision area would be lesser or equal to 24.

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
×