PrBoom-Plus, ver. 2.5.1.4

1 hour ago, Spectre01 said:

Is anyone familiar with the following bug? I've had it happen a few times while playing in PRBoom+, and never in GLBoom+. Just recently, I was hosing down some dudes at the end of Alien Vendetta map04 with Plasma. Then suddenly, my Plasma started passing through the monsters and both myself and the enemies were under something like a ghost monster/noclip effect and could phase through walls. I quickly made a save, reloaded, and everything went back to normal, aside from a bunch of enemies being stuck on top of each other and near walls. So what's the deal with this?

Sounds like you hit an intercepts overflow.

 

Edited by Edward850
3 people like this

Share this post


Link to post

Something similar happened to me in AV too, in maps 22 at the end room, the moment I stepped inside that room everything including myself became ghosts, not sure what exactly caused that, and also in map 26. Casually has never happened to me with any other wads. Good to know the bug's name, not sure if I fully understand it but it's fine.

Share this post


Link to post

Unless you want to research intercepts overflows, or want to play back a demo that features one, it makes sense to turn off emulation of them.

 

Options -> General -> (five screens) ->

Warn on Intercepts Overflow: No

Try to emulate it: No

 

Or in the cfg:

overrun_intercept_emulate     0

 

(Keep spechits overflow emulation enabled - this one doesn't have any bad effects, and it avoids deyncs.)

 

The upshot then is that the map won't fall apart if you get an intercepts overflow, and your demo won't get trashed - you'll end up with a demo that will play back, albeit not with the vanilla exe.

 

Edited by Grazza
1 person likes this

Share this post


Link to post

Thanks for the advice @Grazza. I'd rather not have this happen while playing saveless near the end of the map.

Share this post


Link to post

Entryway please make it possible to play prboom-plus at 320x200, I'm dying here

1 person likes this

Share this post


Link to post

@Grain of Salt @Memfis with SDL2 (v2.5.15 onwards) and the SDL_WINDOW_FULLSCREEN_DESKTOP flag it should "just work", with a 320x200 texture being scaled up to your screen resolution by your GPU. Sadly though I wasn't able to convince @entryway to use it after he did the initial port to SDL2. Can't recall why, I believe it was ironically something to do with 320x200 on his computer not working. It didn't make a lot of sense, may be some Windows driver issue he has, perhaps. But until he comes around, I can't use prboom-plus in fullscreen mode: the "old" SDL_WINDOW_FULLSCREEN method is broken (I believe its instruction to xorg to physically change the display resolution is confusing the window manager, and they end up fighting). The result is only being able to see about 25% of the top left corner of the player view: unplayable, and a regression from SDL1.2 which the window manager was able to cope with. But SDL2 just tells you to use SDL_WINDOW_FULLSCREEN_DESKTOP because the old way is deprecated. Fortunately though, thanks to rboom I almost never need to use prboom-plus at all, aside from the occasional demosync test for which I can stand to let it run in a window.

 

But you have my sympathies. :p If you are able to recompile the game, try this patch (for 2515-test), it may help you to run in 320x200 fullscreen.

diff --git a/src/SDL/i_video.c b/src/SDL/i_video.c
index f1f9bf6b..f63a04ca 100644
--- a/src/SDL/i_video.c
+++ b/src/SDL/i_video.c
@@ -1168,7 +1168,7 @@ void I_UpdateVideoMode(void)
   }
 
   if ( desired_fullscreen )
-    init_flags |= SDL_WINDOW_FULLSCREEN;
+    init_flags |= SDL_WINDOW_FULLSCREEN_DESKTOP;
 
   // In windowed mode, the window can be resized while the game is
   // running.  This feature is disabled on OS X, as it adds an ugly

 

1 person likes this

Share this post


Link to post

The method in the thread Memfis linked to seems to work for me. Hopefully Entryway will come round, but this is fine for the time being. Thanks both of you.

Share this post


Link to post

does anyone else have problems with the demo playback 'seek' function (for lack of a better term)

i used to be able to press 'Insert' on the keyboard once, let the demo seek quickly through, and then press 'Insert' again to stop seeking and resume normal playback.

now it just seems to run away and seek all the way to the end, as if ive pressed 'End' but it skips the stats screen as well and ends the demo, putting me back on the title pic. is this because im trying to play back demos with saves & loads in them?

i just noticed in the usage.txt for prboom there's actually no mention of 'Insert' in the demo playback section that i can see :s

Edited by rehelekretep

Share this post


Link to post

Is it possible for the next update to have OPL3 emulator available, from Choco/Crispy? I've been told it just needs to be updated because it uses the old code from Choco. 

Share this post


Link to post

Can anyone provide an idiot's guide to getting prboom-plus to work on recent OS X versions? I briefly got it running under El Capitan somehow (though most times I would just get a crash/empty window), though after a certain point it seemed to stop working entirely. After upgrading to High Sierra no set of options seems to get anything to happen. I've been looking through DW off and on today for ideas on what else to do, but the most relevant posts seem fairly old and/or go way over my dumb head. 

 

Further details:

Spoiler

 

Software mode does nothing on launch except freezing the application, requiring force quit.

OpenGL mode ends on an actual error message: 


M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - 
R_LoadTrigTables: Endianness...ok.
R_InitData: Textures Flats Sprites 
R_Init: R_InitPlanes R_InitLightTables R_InitSkyMap R_InitTranslationsTables R_InitPatches 
P_Init: Init Playloop state.
I_Init: Setting up machine state.
I_InitSound: couldn't open audio with desired format (Failed to start CoreAudio: AudioUnitSetProperty (kAudioUnitProperty_SetInputCallback)))
S_Init: Setting up sound.
HU_Init: Setting up heads up display.
I_InitGraphics: 640x400
I_SignalHandler: Exiting on signal: Segmentation fault

Basically get the same thing if I run OpenGL with all sound disabled, just without the I_InitSound error message.

 

 

Edited by Big Ol Billy

Share this post


Link to post

I just tried running pr+ on High Sierra and got the same thing. The actual executable in the installer is almost 6 years old so I guess it's not terribly surprising. It would be nice if someone could compile a new updated Mac binary that we could manually overwrite the one in the application package with, if nothing else.

1 person likes this

Share this post


Link to post

[ Moving to pr+ thread by admin request, with apologies for derailing other thread ]

 

1 hour ago, tourniquet said:

You're wrong, you can enable vertical aiming since 2.5.1.4.

 

v_aim.png.92f3e842ed12e19a566f86119c974f4b.png

Fair enough, I did not know this. But it is not, I have just verified, available when recording a -cl9 demo. So, panic over.

 

1 hour ago, Linguica said:

The actual executable in the installer is almost 6 years old so I guess it's not terribly surprising.

Yeah that's pretty much how long the former mac port maintainer has been missing :). Unfortunately the most desirable candidate to maintain the mac port of a traditional / oldschool doom engine hates pr+ so much that to avoid ever having to use it again he became an EE dev ;). (No disrespect intended, I fully understand your reasoning.)

Share this post


Link to post

Regarding vertical aiming, is there anyway to disable auto-aim as well?

 

I know you cannot through the options, but is there any command line, or even a way I can edit the source to do this?

1 person likes this

Share this post


Link to post
1 hour ago, RjY said:

Fair enough, I did not know this. But it is not, I have just verified, available when recording a -cl9 demo. So, panic over.

I kinda conflated several issues there, I admit. You don't get a change in physics when recording with cl9, so yeah, shots don't aim vertically without autoaim kicking in (although being able to verify you're actually aiming at a monster does help), but the "purely visual" mouselook info does get recorded as extended tics into the demo with a Boom header. Doesn't that break backwards compat with the old Boom exe anyway?

bla1.zip

1 person likes this

Share this post


Link to post
1 hour ago, dew said:

I kinda conflated several issues there, I admit. You don't get a change in physics when recording with cl9, so yeah, shots don't aim vertically without autoaim kicking in (although being able to verify you're actually aiming at a monster does help), but the "purely visual" mouselook info does get recorded as extended tics into the demo with a Boom header.

Right great we are on the same page. As I thought (hoped) I was making a fuss over nothing. Unfortunately the terminology itself conflates the issue, does freelook mean being able to look up and down, or does it mean being able to override autoaim and aim up and down? It is, of course, usually used to mean both :).

 

1 hour ago, dew said:

Doesn't that break backwards compat with the old Boom exe anyway?

bla1.zip

In this case it is already broken: boom.exe can't read zdbsp xnod nodes and can't load the map at all :). In general, it shouldn't; if boom.exe can load the map it should be able to play the demo. The extended footer will be harmlessly ignored by engines that aren't aware of it / don't support it. But I don't mess with dos ports and dosbox so I can't answer definitively. I'm more thinking of the other prboom branches I'm interested in, or any other random developers out there making engines based on boom/mbf. Portisms in demos must be avoided. For any boom compatible map and v202 demo, provided the engine can load the map (i.e. it's had appropriate limits extended/removed), it should be able to play the demo.

 

Happily if I play your bla1.lmp with another engine -- or even pr+ with the demo_extendedformat option set to zero, as I tend to leave it -- all that happens is the demo plays without visible pitch changes. That is, I don't see you looking up and down. All the mouselook data is, as you say, stored in the extended footer, which is ignored by non-supporting engines (and pr+ too if you switch off the option). Nevertheless bullet puffs and blood splats appear in the same places and monsters behave identically, as expected. The player's aim is the same regardless of whether the rendered view is sheared/pitched or remaining centred. This is all fine, and expected.
 

All right, thanks again for helping me clear up my misunderstanding.

 

___

 

@OldManRage I don't think there's a way to do it without code changes but it probably wouldn't be too hard to code, you'd need to modify P_BulletSlope and P_SpawnPlayerMissile to skip the aim tests as appropriate.

1 person likes this

Share this post


Link to post

Thanks @RjY. I'll have a look into it. I may have to open another source port to see what values they changed, but I appreciate you giving me some direction... I'd have no idea where to start otherwise.

 

Edited by OldManRage

Share this post


Link to post
5 hours ago, OldManRage said:

Thanks @RjY. I'll have a look into it. I may have to open another source port to see what values they changed, but I appreciate you giving me some direction... I'd have no idea where to start otherwise.

comperr_freeaim_disables_autoaim.patch

I gave it a try. Please test if you are able.

Mb4w3QY.png

1 person likes this

Share this post


Link to post
15 hours ago, Linguica said:

I just tried running pr+ on High Sierra and got the same thing. The actual executable in the installer is almost 6 years old so I guess it's not terribly surprising. It would be nice if someone could compile a new updated Mac binary that we could manually overwrite the one in the application package with, if nothing else.

 

I'll have a go.

 

Edit: I had to build without OpenGL support (haven't figured out how to fix prboom+ to find the libraries in the right place). When I tried replacing the binaries in the App, once I opened it and pressed "Launch", the console output window says "

PrBoom-Plus.wad not found. Can't continue.". I had updated the prboom-plus.wad within the App's Contents/Resources to no avail.  I wonder if there's a special build flag to add search paths to the executable.

Edited by Jon

Share this post


Link to post
20 hours ago, RjY said:

comperr_freeaim_disables_autoaim.patch

I gave it a try. Please test if you are able.

Mb4w3QY.png

 

Awesome! I'll try it out tomorrow (sorry I had a long day and didn't see this post until now). I'll let you know. Thanks!

 

Edited by OldManRage

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