PrBoom-Plus, ver. 2.5.1.4

On 03.04.2017 at 11:19 AM, entryway said:

Instead of switching to software and back to OpenGL you can try to press <Enter> twice on "sector lighting mode: shaders" for reinit. Magically fixed in 2.5.1.5.test.

Setting gamma ramp twice also fixed the problem in 2514

Index: src/gl_gamma.c
===================================================================
--- src/gl_gamma.c    (revision 4459)
+++ src/gl_gamma.c    (working copy)
@@ -191,6 +191,7 @@
 
     CalculateGammaRamp(g, gammatable);
 
+    SDL_SetGammaRamp(gammatable, gammatable, gammatable);
     succeeded = (SDL_SetGammaRamp(gammatable, gammatable, gammatable) != -1);
     if (!succeeded)
     {

2515 already does it twice. Forgot about this.

Strange code instead of

SDL_CalculateGammaRamp(g, gammatable);

SDL_SetWindowGammaRamp(sdl_window, gammatable, gammatable, gammatable);

    if (first && desired_fullscreen)
    {
      // From GZDoom:
      //
      // Fix for Radeon 9000, possibly other R200s: When the device is
      // reset, it resets the gamma ramp, but the driver apparently keeps a
      // cached copy of the ramp that it doesn't update, so when
      // SetGammaRamp is called later to handle the NeedGammaUpdate flag,
      // it doesn't do anything, because the gamma ramp is the same as the
      // one passed in the last call, even though the visible gamma ramp 
      // actually has changed.
      //
      // So here we force the gamma ramp to something absolutely horrible and
      // trust that we will be able to properly set the gamma later
      first = false;
      memset(gammatable, 0, sizeof(gammatable));
      SDL_SetWindowGammaRamp(sdl_window, NULL, NULL, gammatable);
    }

    SDL_CalculateGammaRamp(g, gammatable);

    // has no effect sometimes on Intel Graphics
    // do it twice!
    SDL_SetWindowGammaRamp(sdl_window, gammatable, gammatable, gammatable);
    succeeded = (SDL_SetWindowGammaRamp(sdl_window, gammatable, gammatable, gammatable) != -1);
    if (!succeeded)
    {
      lprintf(LO_WARN, "gld_SetGammaRamp: hardware gamma adjustment is not supported\n");
      gl_lightmode = gl_lightmode_glboom;
    }

Sorry if I'm repeating myself, but I want to get in contact for whoever developed the Mac version for PrBoom Plus.

Both me and 4shockblast can confirm that sound doesn't work under Sierra, and the most recent dmg file for it dates back to 2011.

1 hour ago, Revved said:

I want to get in contact for whoever developed the Mac version for PrBoom Plus.

I think that would be @Neil, but he hasn't been around for years unfortunately.

On 29.03.2017 at 6:48 PM, VGA said:

If you load it in ZDoom or Eternity you can see some errors in the console. Unknown patches in 6 of the textures.

 

 

I can't find unknown patches in console :c

On 29.03.2017 at 6:29 PM, DOOMGABR[RU] said:

Here you go http://www.mediafire.com/file/i8pzbfz7itolfz8/egregor_build29032017.wad

I still need help with fixing of 6 texture errors for normal start my wad in PrBoom+

10 hours ago, DOOMGABR[RU] said:

I still need help with fixing of 6 texture errors for normal start my wad in PrBoom+

R_InitTextures: ATEST1: missing patch ATEST1
R_InitTextures: CEIL3_7: missing patch CEIL3_7
R_InitTextures: CEIL3_8: missing patch CEIL3_8
R_InitTextures: CEIL3_9: missing patch CEIL3_9
R_InitTextures: FLAT20BR: missing patch FLAT20BR
R_InitTextures: FLAT20GN: missing patch FLAT20GN

Your wad's texture definitions specify these six textures, each one composed from a single patch that has the same name as the texture. However the corresponding patch lumps are not found in your wad. Either delete the texture definitions, or add the six missing patch lumps.

2 hours ago, RjY said:

R_InitTextures: ATEST1: missing patch ATEST1
R_InitTextures: CEIL3_7: missing patch CEIL3_7
R_InitTextures: CEIL3_8: missing patch CEIL3_8
R_InitTextures: CEIL3_9: missing patch CEIL3_9
R_InitTextures: FLAT20BR: missing patch FLAT20BR
R_InitTextures: FLAT20GN: missing patch FLAT20GN

Your wad's texture definitions specify these six textures, each one composed from a single patch that has the same name as the texture. However the corresponding patch lumps are not found in your wad. Either delete the texture definitions, or add the six missing patch lumps.

Thank you, my friend! SUCCESSFUL LAUNCH!

Maybe it is just me but for me the sound in 2.5.1.5-test is kinda muffled. I compared it several times with 2.5.1.4 - the sound quality in 2.5.1.5-test isn't that good...

18 minutes ago, xAn said:

Maybe it is just me but for me the sound in 2.5.1.5-test is kinda muffled. I compared it several times with 2.5.1.4 - the sound quality in 2.5.1.5-test isn't that good...

Do your configs for 2.5.1.4 and 2.5.1.5 have different values for the samplerate parameter? It's either that or some difference between SDL1 and SDL2 (IIRC SDL2 switch was after 2.5.1.4 release) but that seems unlikely since AIUI SDL2 didn't change the sound code very much (it was certainly the part that required the fewest changes when I ported my engine from SDL1 to SDL2)

I checked both values - they both has 22050. Maybe i should increase this value a bit. What's the max on that (48k or something?)?

#edit#

Ah, i found it: 

Quote

Useful values are 11025, 22050, 44100 and 48000.

I'll give it a try.

I wonder,if it's possible to get mouse only rotate in prboom+ without triggering movements or mouselook?I can't find it that function which defines it. 

Set vertical sensitivity all the way to the left.

7 hours ago, MysteriousHaruko said:

I wonder,if it's possible to get mouse only rotate in prboom+ without triggering movements or mouselook?I can't find it that function which defines it. 

If you set it to mouse look and then reduce the the max vertical angle to 0 you will never vertical look. It's what I use for PrBoom+ to keep it a more true Doom experience when I want one. 

Sounds complicated. And you can't switch mouse look on and off (easily) this way.

On 10/2/2016 at 4:42 PM, Ribbiks said:

also here's another thing I just noticed after updating to 2.5.1.5test:

when using the -warp option the mouse gets initialized to a weird position:

 

I can reproduce this on OS X.

5 hours ago, Da Werecat said:

Sounds complicated. And you can't switch mouse look on and off (easily) this way.

It's not complicated at all. It's one option in the settings, you just set it to 0. Yeah you can't switch easily but I don't use vertical look in PrBoom at all so for me I don't need to switch. I play GZDoom when I want freelook.

Reporting an issue recently discovered by rdwpa:

If you use the setting to overwrite existing demos and you launch 2 (or more, I assume) PrBoom+ windows with prboom-plus -record demo_name (where demo_name is the same for all windows) all of the processes can write to the same demo.

This can happen by accident if you just forget you already launched one window and open another one, as it did to rdwpa.

Depending on some specifics (I didn't test thoroughly but the outcome varies) it can result in 2 (or more) demos written into a single file. In that case there is a footer for each demo in the file (but seems like only one header - at the beginning of the file). Only the demo placed first in the file is played back and there's no desync.

In the other case closing one of the windows results in the already saved demo to be overwritten. This can be particularly undesirable if your successful demo is overwritten by closing the forgotten window.

Here is a .lmp where you can see 2 demos recorded into a single file. There are 2 footers:
https://www.doomworld.com/forum/topic/66419-official-thread-to-post-demos-to-link-to-from-other-forums/?page=31#comment-1728826

On 03/04/2017 at 9:19 AM, entryway said:

I have similar issue with 2514 on Intel HD Graphics. Something is not initialized correctly. Instead of switching to software and back to OpenGL you can try to press <Enter> twice on "sector lighting mode: shaders" for reinit. Magically fixed in 2.5.1.5.test.

Thank you.

Some time ago I sent a pull request to add an option to change the armour colour based on quality (blue/green) not quantity, and to fix some rounding errors in my earlier patch. Can I ask, please, that you consider it?

This happens in fullscreen mode on Windows 10 Creator's Update.  I'm not sure why. (2.5.1.4)

It's probably because of SDL1. Crispy-Doom has the same issue. You should get the latest 2.5.1.5 test build from here, which uses SDL2.

On 17.4.2017 at 3:06 PM, xAn said:

I checked both values - they both has 22050. Maybe i should increase this value a bit. What's the max on that (48k or something?)?

 

#edit#

 

Ah, i found it: 

 

 

I'll give it a try.

Setting the value to 48khz solved the issue btw.

my PC monitor is 1680x1050 (16:10), and my TV that i can use as a second screen is 1920x1080 (16:9).

is there a simple way to get glboom+ to output in the correct res to that 2nd screen?

i tried changing the res in the 'General' menu, but its obviously detecting my monitor res as the highest possible (1680x1050).

thanks!

why does demo playback put files such as this:

prboom-plus-demoex-a06492

in my Local/Temp folder?

The opening shot from map22 of 10secto2.wad using the Boom engine:

The same shot using PrBoom-Plus (EDIT: 2.5.1.4 just to be clear):

It's noticeable in more than just the opening shot, but I figure it's a good reference point.

Did you -complevel 9? Are you using the software renderer?

Interesting.

https://www.dropbox.com/s/p24l4lqvvx4vtq8/test230.wad.zip?dl=1

prboom's software mode behavior is similar to doom2.exe there, not boom

Funny, sometimes your first guess turns out to be accurate. The Boom.exe behaviour can be restored by reverting this patch:

------------------------------------------------------------------------
r2419 | proff_fs | 2007-01-30 09:13:48 +0000 (Tue, 30 Jan 2007) | 3 lines

Added missing clipping. Very noticeable in Doom2 Demo3 in Map 26 in the
elevators when you remove the call to R_DrawPlanes.
Thanks to SoM for this!


diff --git a/src/r_segs.c b/src/r_segs.c
index 67e5e8b7..cb30b75b 100644
--- a/src/r_segs.c
+++ b/src/r_segs.c
@@ -298,6 +298,8 @@ static void R_RenderSegLoop (void)
               ceilingplane->top[rw_x] = top;
               ceilingplane->bottom[rw_x] = bottom;
             }
+          // SoM: this should be set here
+          ceilingclip[rw_x] = bottom;
         }

 //      yh = bottomfrac>>HEIGHTBITS;
@@ -316,6 +318,8 @@ static void R_RenderSegLoop (void)
               floorplane->top[rw_x] = top;
               floorplane->bottom[rw_x] = bottom;
             }
+          // SoM: This should be set here to prevent overdraw
+          floorclip[rw_x] = top;
         }

       // texturecolumn and lighting are independent of wall tiers
------------------------------------------------------------------------

On the other hand, is reverting it the right thing to do? Was this change a mistake? Honestly I have no idea.

Maybe it should depend on the complevel used?

If I remove those lines from my port it makes no difference - it still does not render correctly.

I guess that this means that I haven't copied the relevant parts of the Boom code into mine.

Does anyone have any clues where I should be looking?

3 hours ago, jeff-d said:

If I remove those lines from my port it makes no difference - it still does not render correctly.

I guess that this means that I haven't copied the relevant parts of the Boom code into mine.

Does anyone have any clues where I should be looking?

I've seen this before, but I can't for the life of me remember what's going on. It's strange, because the 2S fence appears to me marking columns around it as already drawn (or not drawn), which 2S walls aren't supposed to do. PrBoom had an optimization added that detects if 2S walls have any holes, and if not, they are treated as 1S lines for drawing purposes. Maybe that has something to do with it?