PrBoom-Plus, ver. 2.5.1.4

[wildweasel]

Weird thing, the sound issues seem to go away completely if I run the game with -nomusic. Honestly it's not that imperative that I have music since I can just run Foobar in the background, but oh well.

[Shadow Hog]

I think I've had the exact same issue, actually. Rather frustrating.

Had the same issue with Sonic Robo Blast 2, which uses FMOD. if I was using BASSMIDI as my MIDI driver, the audio would get all choppy, even if a MIDI wasn't being played. Took the time to find the revision that caused it to start occurring and found the cause: the stuttering happened when the "cpuaffinity" variable was set to "1" instead of "-1" (I'm assuming the latter being "don't care"). Setting it to "1" fixes the issue, even with BASSMIDI.

PrBoom+ doesn't seem to use FMOD, I have no idea if it sets its CPU Affinity to only one core or not, and I don't know if you use BASSMIDI as well... but maybe it's relevant?

[entryway]

I'll remove process_affinity_mask variable from cfg and will force one core only if music player is "sdl"

[Shadow Hog]

Oh, is there a variable to set CPU affinity in the CFG? I should futz with that a bit before jumping to any conclusions :)

EDIT: Okay, I've had time to futz with it now. Yep, setting "process_affinity_mask" to -1 fixes the audio up plenty nice. Works for me.

[Ribbiks]

here's a strange thing I noticed today:

just finished compiling the latest source on os x 10.8, and everything worked flawlessly, midi/GL/demos/etc, except that for some reason I couldn't get the advanced HUD to appear (regardless of how I messed with 'zoom out' 'hud' keys, or 'hud_num' in prboom.cfg). Long story short the issue was prboom-plus.wad, I swapped it out with a version from a previous release (2.5.1.2) and it works perfectly again.

I didn't peak around the wads with slade or anything to see what the differences were, and it's probably doubtful anyone else will have the same issue, but I figured it wouldn't hurt to post about it. here's a link to the 2 specific wads I was using.

[printz]

How to make the OS X version of PrBoom work on 10.7 and up on full-screen:

• Download the latest disk images of SDL from here, SDL_mixer from here, SDL_net from here and SDL_image from here
  
• Open each downloaded .dmg in Finder
  
• Inside each DMG you should find a .framework folder. Keep the Finder windows open.
  
• Go to where you copied PrBoom-Plus when you got it (such as in /Applications).
  
• Right (control) click PrBoom-Plus and select "Show Package Contents"
  
• Browse down into Contents, then Frameworks
  
• Copy each of SDL.framework, SDL_mixer.framework and SDL_net.framework from the downloaded disk images into the Frameworks folder within PrBoom-Plus. Replace all that's needed (caution: make sure you are copying them into PrBoom-Plus.app/Contents/Frameworks, not in another Frameworks folder.)
  

Whether it's Retina-ready or not, that may or may not be fixable. On big 15" laptops, you may have to disable GPU auto-switching. Also if you want to go high-res, you may want to activate hardware acceleration in PrBoom+, otherwise it's too slow. The GUI launcher won't be able to show you the maximum resolution available, so you might get less resolution than maximum possible (unless you manually change inside the game each time).

All this applies until the developer of the Mac port builds the package with the latest SDL versions and allows more values in the Resolution drop-down box.

[Mechadon]

Hey entryway, I've got a couple requests and maybe bug reports. I made some threads in the editing forum, but was directed to this thread so you'd see them.

Odd palette problem in PrBoom+

From what andrewj told me in that thread, this isn't necessarily a bug but just how the code is written. In short, I've got a new palette for a project I'm working on and there's a new color we're using which is set in palette index #255. PrBoom+ uses that index for a sort of transparency, I'm guessing, so it messes up textures which use a color in that index (check the screenshots in that thread).

So this is a feature request. Is there a chance that behavior could be changed around so this doesn't happen?

PrBoom+ sky issue

I'm not sure if this sky issue, described in the thread I linked to above, is a bug, just intended behavior, or something I screwed up. I'm using tall skies (they are actually 240px tall, not 256px as I mistakenly said in that thread) to prevent them from tiling or being stretched in ports that support mouselook. PrBoom+ seems to draw skies differently than other ports. The sky works as intended in the other ports I'm aiming for, including MBF. There are some screenshots in that thread that you can compare. Note that this sky issue only seems to manifest in PrBoom+, but not in GlBoom+.

Lastly, I have one other feature request I'd like to make. Since there is support for MBF features now, will you add support for the OPTIONS lump at some point? In my particular case, I'm using it to disable some of the MBF beta features because I'm making use of the frames for dehacked.

Thanks!

*edit*

Whoops, forgot one!

Something else we're hoping to do is make use of multiple sky textures in single maps. Specifically we want the player to be able to view multiple sky textures from any given position on certain maps. We're using the MBF sky transfer specials.

This works just fine in PrBoom+ and all of the other compatible ports, but GlBoom+ has trouble displaying more than one sky texture at once.

Here are some screenshots:

Multiple skies in PrBoom+
Multiple skies in GlBoom+

And here is a test map.

I'm not sure if this is a bug or a limitation, but I just wanted to bring it to you attention. I know it would be great if the effect could work in GlBoom+ like it does in the software renderer.

[entryway]

Mechadon said:

PrBoom+ sky issue

test map?

[Mechadon]

Sure thing: http://mekworx.the-powerhouse.net/mekastuff/wads/supppub/prboomtallskytest.wad

I used some crappy tall sky texture I made really quick. I also tested the MBF sky transfers against the normal sky rendering method (replacing SKY1 and SKY2). There's a test map for MAP01 and MAP12 to test both sky textures.

[entryway]

..

[entryway]

Where the problem is precisely is? Because I have tested normal sky (1024x240) and it looks differently in prboom, Eternity and MBF

http://prboom-plus.sf.net/c.wad.zip

MBF:
http://prboom-plus.sf.net/clip/2013-02-17_13.55.22.png

Eternity:
http://prboom-plus.sf.net/clip/2013-02-17_13.56.26.png

PrBoom-Plus
http://prboom-plus.sf.net/clip/2013-02-17_13.57.14.png

In PrBoom/+ it was broken many years ago in r1971

[entryway]

entryway said:

In PrBoom/+ it was broken many years ago in r1971

http://prboom-plus.sf.net/c4.wad.zip

Sky texture:
http://prboom-plus.sf.net/clip/2013-02-17_17.30.43.png

In-game!
http://prboom-plus.sf.net/clip/2013-02-17_17.32.37.png

Looks like it is related to this
http://www.doomworld.com/vb/showthread.php?s=&postid=1144951#post1144951

[Alpha3kv]

I have a couple of minor suggestions for the new HUD. First, I think it should be just one step above the largest setting with the original status bar, instead of having no HUD at all between them. That can be slightly confusing. Second, I'd kind of like it if the face could be used as the health icon.

[Platinum Shell]

Those messed up sky screenshots remind me a lot of those 90's backdrops for dad and son pictures.

[Mechadon]

entryway said:

Where the problem is precisely is? Because I have tested normal sky (1024x240) and it looks differently in prboom, Eternity and MBF

Actually it didn't occur to me that it may have been fixed or changed in WinMBF. I didn't test it in the original MBF engine. I don't know for sure, but the screenshot in doomworld.com/vb/doom-editing/63168-prboom-sky-issue/]this thread is from WinMBF.

So from your screenshots, am I to assume that's the way MBF rendered tall sky textures? Would that be a bug?

The palette index #255 bug happened with just about every type of graphic - textures, sprites, and other graphics. I made some new yellow skullkey sprites which were completely mangled because they made use of a new yellow color in that index. So I had to work around it at the time.

[Springy]

Not too sure if this is a bug or maybe a mapping error in Boom format but upon trying to get the mega armour secret in the first map of Stomper the secret level message doesn't appear, along with, the secret not being counted but it does in ZDoom.

I have tried to trigger the secret from every single angle but it doesn't work, attached is the ZDoom and PrBoom plus 2.5.1.3 demos, if you want I could probably create a test wad as I'm pretty certain that mega armour is in a separate sector in that sector. It makes it impossible for me to get a UV Max on that map. Then again, it could be user error but I haven't messed with anything.

EDIT: I forgot that I cannot attach demos in this part of the forum, I'll send you the files these will explain what I mean.

[Doom_user]

GLBoom Plus freezes instantly if I try to run certain maps using the "shaders" sector light mode. Examples of this include PCCP.wad Maps 01 and 03 as well as cchest4.wad Map 04.

[MrrCaliber]

Is it possible to do anything with my music being too quiet? I'm using fluidsynth, and the music volume slider seemingly ceases to increase volume when it's being set past around 70%, and at this setting the music volume is audibly lower than sfx's while the latter is set at the same level.

[Ribbiks]

assuming you're using 2.5.1.4:

[+] Added "mus_fluidsynth_gain" and "mus_opl_gain cfg" config variables to fine tune output of fluidsynth and opl2 midi. Values allowed are 0 to 1000. 50 (default) exactly matches old behavior.

[entryway]

Doom_user said:

GLBoom Plus freezes instantly if I try to run certain maps using the "shaders" sector light mode. Examples of this include PCCP.wad Maps 01 and 03 as well as cchest4.wad Map 04.

Can't reproduce. glboom-plus cchest4.wad -warp 4 works fine for me with "shaders" sector light mode.

[Doom_user]

entryway said:

Can't reproduce. glboom-plus cchest4.wad -warp 4 works fine for me with "shaders" sector light mode.

Perhaps it's my crappy computer?

Windows Vista Ultimate 32-bit with Service Pack 2
AMD Turion 64 X2 TL-50 1.60 GHz Processor
2.00 GB RAM
ATI Radeon Xpress Series Integrated Graphics

It's odd because every other map I've tested using the "shaders" sector light mode worked and these 3 maps work if I use the "fog based" sector light mode.

[entryway]

Does prboom freeze with default cfg + shaders mode? Do you use the latest test build?

[Doom_user]

entryway said:

Does prboom freeze with default cfg + shaders mode? Do you use the latest test build?

I'm using the latest test build from 2013-Feb-20 01:48.
GLBoom Plus freezes with the default cfg as well.

[Doom_user]

I tested several dozen more maps and found 3 more that are affected by this.

SCYTHE.wad Map 13
SCYTHE.wad Map 17
crudream.wad Map 26

In addition, whatever the cause of this is, can apparently happen mid level as well.

Using "shaders" sector light mode, GLBoom Plus freezes about 45% of the way through the first demo in FreeDoom. It freezes when the player shoots a switch a 2nd time. The same demo plays through to the end when sector light mode is set to "fog based".

[entryway]

Doom_user, check PM

[Doom_user]

entryway said:

Doom_user, check PM

The prboom-plus.wad you sent me fixes the freezing issue, but it also causes all sectors to be displayed at full brightness. All light levels appear exactly the same, like when a player has the light amplification visor powerup.

[ReFracture]

Hey entryway, have you been updating the changelog everytime you update the test version of PrBoom-Plus? Latest still says it adds the health bar option for monsters, but I'm pretty sure you implemented that a while before the last update date it mentions (Feb 20).

[Grazza]

It's a list of changes since the last release (i.e. 2.5.1.3), not the previous test version.

[entryway]

Doom_user said:

The prboom-plus.wad you sent me fixes the freezing issue, but it also causes all sectors to be displayed at full brightness. All light levels appear exactly the same, like when a player has the light amplification visor powerup.

In test prboom-plus.wad I simplified fragment shader (GLFP lump):

Full shader

uniform sampler2D tex;
uniform float lightlevel;

#define DOOMLIGHTFACTOR 232.0

void main()
{
  vec4 color = gl_Color;

  float L = 63.0 * lightlevel;
  float min_L = clamp(36.0 - L, 0.0, 31.0);
  float index = 59.0 + DOOMLIGHTFACTOR - L - DOOMLIGHTFACTOR / gl_FragCoord.z;
  color.rgb *= (1.0 - clamp(index, min_L, 31.0) / 31.0);

  gl_FragColor = color * texture2D(tex, gl_TexCoord[0].st);
}

was replaced with just

uniform sampler2D tex;
uniform float lightlevel;

void main()
{
  gl_FragColor = gl_Color * texture2D(tex, gl_TexCoord[0].st);
}

[ReFracture]

Nvidia surround sure is interesting.

http://s16.postimage.org/tp0qs01bp/surround.jpg