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

PrBoom-Plus, ver. 2.5.1.4

Recommended Posts

PrBoom Plus saved my widescreen laptop! Playing PrBoom I could only play in a window because otherwise the display would look all stratched and crappy. However, PrBoom Plus supports widescreen resolutions perfectly! Way to go! :D

Share this post


Link to post

Is there a way I can disable mouse acceleration just within PrBoom-plus or do I have to rig up some sort of system-wide fix? (I'm setting up some Doom stuff on my parents' computer, and cannot stand mouse acceleration in games.)

Share this post


Link to post
Creaphis said:

Is there a way I can disable mouse acceleration just within PrBoom-plus or do I have to rig up some sort of system-wide fix? (I'm setting up some Doom stuff on my parents' computer, and cannot stand mouse acceleration in games.)

I do not understand how people live with acceleration at all, even in Windows

Control Panel \ Mouse \ Pointer Options \ [ ] Enhance pointer precision

And/Or (do not remember)
http://prboom-plus.sourceforge.net/mouse_accel_fix.zip

Share this post


Link to post

For some reason I cannot compile right now under Linux. I'm missing a sound file dssecret and the makefile halts immediately.

Share this post


Link to post
HackNeyed said:

That fixed playback in 8bit thanks!

But 32bit still crashes

Fixed

Csonicgo said:

For some reason I cannot compile right now under Linux. I'm missing a sound file dssecret and the makefile halts immediately.

Fixed

Share this post


Link to post

I thought I would post this here incase anyone else was having this problem or could reproduce it.

Here is the Arch-Vile flame problem I mentioned earlier. I ran a Compet-N demo (included in the zip) with and without capped frame rate using the IDRATE cheat and recorded it via webcam to illustrate the problem I am having. Screen capture does not catch it. In fact, when I screen capture at 60fps with uncapped frame rate enabled the IDRATE cheat displays 35...

I recorded the video with my ACER laptop (AMD Athlon Dual-Core 1.9 GHz running 60 Mhz refresh rate) since it was powerful enough for the recording and encoding.

I ran the demo on my ASUS netbook (Intel Atom Single-Core HT 1.6 GHz running 60 Mhz refresh rate which wikipedia says "The performance of a single core Atom is about half that of a Celeron of the same clock rate.")

prb-cap-on-then-off.zip

So even though the uncapped frame rate is as low as 87 in the video it still looks the same when the demo is ran on my ACER laptop and the IDRATE cheat says the frame rate is 213 or 225 or 275 or 286 when the problem occurs. Chocolate Doom as well as Eternity with and without Wait for Retrace enabled both behave as PrBoom-Plus with the capped frame rate.

I also checked in Heroes' Tales map05 with ZDoom's uncapped frame rate with and without vsync and it displays correctly whereas PrBoom-Plus with uncapped frame rate does not display correctly most of the time.

Back when I discovered the problem while demo recording on map05 I found that bumping the resolution up until my frame rate dropped to the 60-70 range nearly made the problem go away.

Is there a good way to make the Arch-Vile flames less glitchy?

Share this post


Link to post

Use sdl_videodriver "directx" and use_doublebuffer 1

I have checked it. FPS = refresh rate. It's always 100 for me at 1024x768.

Vsync is not implemented in SDL for software windib mode

Share this post


Link to post
entryway said:

Use sdl_videodriver "directx" and use_doublebuffer 1

I have checked it. FPS = refresh rate. It's always 100 for me at 1024x768.

Vsync is not implemented in SDL for software windib mode


ASUS netbook = Fixed!

ACER laptop = Still broken...

Kinda glass half full/half empty for me. Both machines are running XP though the ACER also has(had) a Vista install I would like to test this in but Vista stopped booting a few hours ago. ugh.

entryway said:

$50


I'd chip in if it came with a free bonus extra also included ability to bind 'use' to the right and middle mouse buttons! If that also got wheel support I would be happily surprised.

Share this post


Link to post
HackNeyed said:

I'd chip in if it came with a free bonus extra also included ability to bind 'use' to the right and middle mouse buttons! If that also got wheel support I would be happily surprised.


- in your mouse driver ui, you could reassign those buttons to keystrokes and bind those keys to the desired actions ingame

- AutoHotKey is a program to do the same, but with many additional features (macros, mousewheel binds etc.). It's free and works great.

entryway said:

$50


How much to make prboom+ look like this?

Share this post


Link to post
gravitar said:

- in your mouse driver ui, you could reassign those buttons to keystrokes and bind those keys to the desired actions ingame

- AutoHotKey is a program to do the same, but with many additional features (macros, mousewheel binds etc.). It's free and works great.

That is a good work around, but really we would like to have a proper solution.

Share this post


Link to post

Thanks gravitar but I already use and have suggested AutoHotKey to at least one or a couple people here finding the same shortcomings I am. Please note it does not have usable mouse wheel remapping. They explain that the wheel has no off action, only an on action so if you want it to start one or two somethings once and never stop them then you can use the wheel for it.

Mike.Reiner said:

That is a good work around, but really we would like to have a proper solution.


Exactly! Even Choco-Doom's SVN builds have Boom level keyboard binding plus mice bindings like single click 'use' and 'move backwards'. Sure, there isn't wheel support but I didn't even expect this much form such a purist port.

Not to just keep dragging names up but Eternity finally has full mouse and wheel support. Admittedly Eternity's goal seems to lead it somewhere between PrBoom and ZDoom while cutting it's own path in brand new self defining directions.

But where exactly is PrBoom-Plus? I know it's been said that PrBoom is simply to keep dead ports and their demos alive through compatability and the Plus is generally better demo recording/playback/TAS features. However we have Hell Ground and Deus Vult II saying they require PrBoom-Plus or (G)ZDoom. It sounds to me like PrBoom-Plus is becoming it's own port in a small way. Also, the compatibility with mapping errors just shows that there is room for playability 'fixes' even at the cost of 'compatibility' even though those settings are ignored during demo recording and playback.

I just wonder why this Advanced Boom Engine doesn't/shouldn't/can't have Choco-Doom level mouse bindings at the least or Eternity/ZDoom mouse bindings at the most.

Share this post


Link to post

The new version of PrBoom-Plus is available:
http://sourceforge.net/projects/prboom-plus/

Change Log

2.5.0.6 @ 2009 Dec 27

[+] Added the ability to smooth sprites edges ("Options\General\OpenGL Options\Smooth Sprite Edges"). Might noticeably reduce frame rate. Includes a "gl_mask_sprite_threshold" config variable for the intensity of smoothing (0-100).

[+] Ability to see kills/secrets/items/time statistics in automap mode. Available in the menu at "Options\Setup\Automap\".

[+] Added a "map_use_multisamling" config variable to apply multisampling to the automap.

[+] Added a "movement_shorttics" config variable in addition to the "-shorttics" command line switch.

[+] Added a "gl_shadows_maxdist" config variable.

[+] Added the ability to disable any OpenGL extension via the config instead of disabling all of them with "gl_compatibility" in case your drivers can't work properly with specific features. The extensions which can be disabled are: gl_arb_multitexture, gl_arb_texture_compression, gl_arb_texture_non_power_of_two, gl_ext_arb_vertex_buffer_object, gl_ext_blend_color, gl_ext_framebuffer_object, gl_ext_packed_depth_stencil, gl_ext_texture_filter_anisotropic, gl_use_stencil.

[+] Added a "-trace_givendamage" command line parameter to trace the latest and total damage inflicted by any specific monsters or players in a level. If a player is selected, its data will be tracked across multiple levels. Available with the Boom HUD only. Usage:
-trace_givendamage ThingID [ThingID] [ThingID]

[+] Added a "map_scroll_speed" cfg variable and GUI setting. "key_speed" doubles the speed.

[+] Added a "sprites_doom_order" config variable for correct sprite sorting. See sectors 99, 115, and so on in Strain.wad map13, for example. This also fixes z-fighting between overlapped sprites in GL mode.

  • Mouselook key and keys bound to game speed change commands do not break cheats being typed.

  • Midi volume is applied to all midi devices when mus_extend_volume is 1.

  • Light level 0 will now be truly lightless with GZDoom lighting mode.

  • Automap grid can now rotate with map (from ZDoom).

  • Now DSSECRET is used when a secret area is found, instead of DSITMBK. The new sound lump is part of prboom-plus.wad and can be replaced through PWADs.

    [-] Fixed a crash in software mode at some resolutions when using 'Doom Format' or 'Fit to Width' for 'Status Bar and Menu Appearance'.

    [-] Now applies fake contrast when using "Fog Based" sector light mode.

    [-] Fixed Player's weapon lighting, that was too dark in GL mode.

    [-] Fixed small glitches on Boom HUD graphics in GL mode.

    [-] Mouse button now moves camera forward if you have it assigned to move forward.

    [-] Fixed software mode bug: if you played a wad with menu graphics big enough to go over the status bar, entering and exiting the menu left a trace of the menu graphic over the status bar. See HR2final.wad, for example.

    [-] Flat bleeding on walls won't incorrectly bleed through walls and floors when motion blur is in effect anymore. This fix requires support of the "GL_EXT_packed_depth_stencil" extension.

    [-] Simple shadows and transparent textures don't sometimes flicker anymore when fog-based lighting is used.

    [-] Shadows don't disappear in some situations anymore.

    [-] "-trace_thingshealth 0" now works.

    [-] Fixed screen shots at resolutions where width is not a multiple of 4.

    [-] Fixed slowdowns on Pentium 4 at 1024x768 (introduced in 2.5.0.3).


    Full Change Log

  • Share this post


    Link to post
    HackNeyed said:

    I already use and have suggested AutoHotKey to at least one or a couple people here finding the same shortcomings I am. Please note it does not have usable mouse wheel remapping.


    The example below works for me.

    *WheelDown::SendInput, {PgDn}
    *WheelUp::SendInput, {PgUp}
    return

    entryway said:

    [+] Ability to see kills/secrets/items/time statistics in automap mode. Available in the menu at "Options\Setup\Automap\".


    Great feature.

    Share this post


    Link to post
    gravitar said:

    The example below works for me.

    *WheelDown::SendInput, {PgDn}
    *WheelUp::SendInput, {PgUp}
    return


    Does it work for you in PrBoom-Plus? It doesn't really for me. As a test I was able to use the mouse wheel to bind PageUp to Fire but it would not fire in game. Thank you very much for the workaround though because it does work in windows and web browsers so I can use it there.

    The quotes below say that normal remapping won't and perhaps why it repeats the command indefinitely when I tried it. I don't know why your code doesn't work. Maybe there is a raw send method that would work? I don't know but using a third party program like this just feels like Novert and Doom Mouse Spinner all over again all these years later.


    AutoHotkey information on Remapping Keys and Buttons said:

    The syntax for the built-in remapping feature is OriginKey::DestinationKey. For example, a script consisting only of the following line would make the "a" key behave like the "b" key:

    a::b

    ...


    The following keys are not supported by the built-in remapping method:
    * The mouse wheel (WheelUp/Down/Left/Right).

    AutoHotkey information on Mouse Wheel Hotkeys said:

    Finally, since mouse wheel hotkeys generate only down-events (never up-events), they cannot be used as key-up hotkeys.

    Share this post


    Link to post

    So I just tried PrBoom+ 2.5.0.6 on my laptop using Vista, and I'm running into the same issue as Doom Marine, namely :

    Issue(s): When the Music Slider in Volume is adjusted, the audible SFX volume (not the one on the slider) is adjusted as well. Example: Sliding the Music Volume to 0 will cause the SFX volume to mute as well.


    I've read the following answers, but haven't found/understood what was the solution to this specific problem.

    I'm also getting a half-second freeze everytime the MIDI is over (and goes back to replaying at the beginning).

    Share this post


    Link to post
    Phml said:

    So I just tried PrBoom+ 2.5.0.6 on my laptop using Vista, and I'm running into the same issue as Doom Marine, namely :



    I've read the following answers, but haven't found/understood what was the solution to this specific problem.

    [/B]

    Have you tried using -nomusic instead? -nomusic used to mute everything on Vista/Win7, but that's fixed now. I would have thought the same fix would fix your issue, but you said you updated. I would make sure you have the latest stuff.

    Phml said:

    I'm also getting a half-second freeze everytime the MIDI is over (and goes back to replaying at the beginning).


    This is an SDL bug that affects Vista and Win7. If you have a multi-core CPU try setting the process affinity mask (in the config) to a different cpu. Setting it to 0 instead of 1 seems to help for me (hanging not as bad), though you will risk a crash. But it doesn't crash very often.

    Share this post


    Link to post

    Setting any value for the process affinity mask still gives me the same level of hanging.

    However, playing with -nomusic fixes both problems for me. SFX slider works and there isn't any freeze. Thanks a lot, emailking. :)

    Share this post


    Link to post

    Ran into a new issue with PrBoom+ 2.5.0.6 and nuts.wad ; sometimes, I get a huge FPS hit and the player starts noclipping through things. It doesn't happen in PrBoom+ 2.5.0.5, and I've made sure all my settings were the same in both versions. I was using -complevel 2 in both cases.

    Demo : http://www.toofiles.com/en/oip/documents/zip/weirdnuts.html

    Edit : Nevermind, it just happened in PrBoom+ 2.5.0.5 too now...

    Share this post


    Link to post
    Phml said:

    sometimes, I get a huge FPS hit and the player starts noclipping through things.

    http://www.doomworld.com/vb/doom-speed-demos/35214-spechits-reject-and-intercepts-overflow-lists/

    If you want to know what's happened:
    overrun_intercept_warn 1

    If you do not want to have it at all:
    overrun_intercept_emulate 0

    Both settings are available via GUI.

    For correct playback, demo footer contains information about overflow. You can see it with any HEX editor

    Share this post


    Link to post

    Good read, thanks for the information. Not sure if this is the right place to ask this but for demo recording purposes would I be better off leaving all that stuff the way it is set up (everything emulated except for donut overflow) or turning it off ?

    Share this post


    Link to post

    I do not know. Probably allowing emulation only for demo playback (and warnings during recording) would be a better idea.

    Share this post


    Link to post

    Phml said:
    Not sure if this is the right place to ask this but for demo recording purposes would I be better off leaving all that stuff the way it is set up (everything emulated except for donut overflow) or turning it off ?

    My suggestion is to leave them on, or you'll make your demos incompatible with Doom or PrBoom+ with the emulations turned on. Only intercepts can be troublesome, because it's a bit harder to emulate, and, because it depends on things that are moving around, is somewhat more unpredictable to the player. Other emulations are quite safe in PrBoom-plus. You can turn intercepts off in any map where huge numbers of monsters amass.

    For example, extreme horde levels, like Nuts, To fight, and Das Labor are best played without intercepts emulation (unless you want to abuse the all-ghosts effect for a speed run in Nuts, heh.) But even sets like Deus Vult (1-4) or HR, which have many monsters haven't produced many severe intercepts issues that I can recall. Most vanilla level sets, or limit removing ones with more standard monster counts, are fine with emulation turned on, but a few, like Punisher 2, are borderline because they can consistently produce all-ghosts in some areas unless one takes certain (max route) measures.

    So if you want to touch any of the emulation, only mess with intercepts. The only complication is that you have to change the CFG. (I find editing overrun_intercept_emulate in the CFG quicker than going into the menu, for this.) That is, even if you play mostly huge slaughterfests and want to generally keep intercepts emulation off, you'll still need to enable it to watch most Doom v1.9 (-complevel 2-4) demos.

    Share this post


    Link to post

    Got a problem with prboom+ 2.5.0.5. In this demo for this wad I get a mancubus shooting through a wall at 1:25. It looks almost like the fireball hit the vertex in the other side. This happened to me once before in the room before the 'crypt park'. It could just be unclosed sectors with DB2 somehow, but I don't think that's it ...

    EDIT: oops, wrong version of the wad, must've been some weird intermediary. Still happened tho -.-

    Share this post


    Link to post

    Mancubus fireballs can pass through walls even with Lee Killough's fix from MBF simply because their radius is too small versus their speed, which is an essential flaw in DOOM's collision detection algorithm.

    Any object which steps more than its radius in units per tic may escape collision detection with a linedef.

    Example:

      [ A ]  |  [ B ]    
    
    If the fireball starts at position A and moves to position B in the span of one tic, its move is not blocked by an intervening linedef (the pipe character). It has outstepped its own radius and therefore can miss clipping against any object in the intervening space.

    ZDoom is, to my knowledge, the only port that fixes this, and it does it by stepping such objects through the movement code repeatedly for submoves which are guaranteed to clip against intervening objects. This may sound simple in practice, but in execution it creates complications, as certain side effects of the movement process must not be executed multiple times but only once.

    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
    ×