PrBoom-Plus, ver. 2.5.1.4

[cycloid]

WinXP SP3, launching prb+ from command window tp record a demo on UAC Ultra, if it's midi music could it be the soundcard? still seems odd to me that it will still "play" the music at all when volume is zero but there you go.

[myk]

Something must be resetting your sound volume to a value defined by the operating system. I recommend installing TiMidity, which entryway mentioned. You can get a decent set of patches here. I use these for any engine that supports them (Boom, ZDoom engines and SDL-using engines.)

[Quasar]

Is PrBoom setting the music volume explicitly every time it starts a song? Until EE started doing that, I had exactly the same problem on my XP box. The resultant behavior was that my music volume would jump to max. Extremely painful.

I think SDL_mixer doesn't properly maintain state with respect to native MIDI music volume across song changes. In MCI, the volume is changed relative to the currently opened stream. You can't even set MIDI volume at all without an opened stream.

This means that calling Mix_SetMusicVolume when no song is playing (ie at startup) is a complete waste of time. SDL_mixer will not remember that you called it and set the volume properly later. Instead it just returns immediately and the volume will remain at whatever it was before.

Evidently on some AC97 sound drivers, the action taken with an uninitialized MIDI stream volume is to reset the device volume to whatever the default is. For me this was ear-bleeding max volume.

void I_PlaySong(int handle, int looping)
{
   if(mus_init)
   {
      i_musicdriver->PlaySong(handle, looping);

      // haleyjd 10/28/05: make sure volume settings remain consistent
      I_SetMusicVolume(snd_MusicVolume);
   }
}

[entryway]

I think all is correct in prboom.

void I_PlaySong(int handle, int looping)
{
#ifdef HAVE_MIXER
  if ( music[handle] ) {
    Mix_FadeInMusic(music[handle], looping ? -1 : 0, 500);
    //Mix_PlayMusic(music[handle], looping ? -1 : 0);

    // haleyjd 10/28/05: make sure volume settings remain consistent
    I_SetMusicVolume(snd_MusicVolume);
  }
#endif
}

[Quasar]

Isn't a fade-in going to interfere with setting the volume? SDL_mixer fade-in is a callback that repeatedly sets the music volume level. This is not maintained separately from the global level for MIDI, AFAIK.

If anyone is beginning to get the feeling that native MIDI is poorly supported in SDL_mixer, they would be quite justified.

[entryway]

Quasar said:

Isn't a fade-in going to interfere with setting the volume?

Yes, it can.

Ok, I do not want to play with Mix_FadingMusic() check, so I've replaced Mix_FadeInMusic() with Mix_PlayMusic().

cycloid is able to test the latest 2.5.0.7.test build from the changelog page, but I do not think it will help

[Csonicgo]

I've noticed a small cosmetic bug with blending animations. When an animated wall or flat is in the FOV of the player, sometimes all sprites (and the HUD, including the player's weapon) pulsate in brightness. I can't really get a screencap of this, as it is something you have to see in motion. The Graphics Chip is a Intel 915/945 (yes I know "teh suck" but it is a netbook) and the OS is Windows XP.

[entryway]

Csonicgo said:

I can't really get a screencap of this, as it is something you have to see in motion

fraps/phone video could be useful, but probably i'll able to test it on similar hardware tomorrow

[entryway]

entryway said:

but probably i'll able to test it on similar hardware tomorrow

Can't reproduce with Intel 82865G with and without gl_compatibility

[Graf Zahl]

Here's a small problem I just found:

static dboolean CheckClip(seg_t * seg, sector_t * frontsector, sector_t * backsector)
{
  static sector_t tempsec;

  backsector = R_FakeFlat(backsector, &tempsec, NULL, NULL, true);
  frontsector = R_FakeFlat(frontsector, &tempsec, NULL, NULL, false);

If this has to copy both sectors it will overwrite the backsector with the frontsector. It needs two separate buffers for the fakes.

[entryway]

Do you mean I need 'static sector_t tempsec_back, tempsec_front'?

Fixed.

[entryway]

I have added support for Quake2/Unreal style skyboxes.

Definition (using GLDEFS lump) is compatible with GZDoom.
http://zdoom.org/wiki/GLDEFS#Skybox_definitions

It is still limited with single skybox/skydome in frame.

Binaries: http://prboom-plus.sourceforge.net/history.html
Test level: http://prboom-plus.sourceforge.net/skybox_test.zip (11MB)
Screenshot: http://prboom-plus.sourceforge.net/skybox.png

[myk]

Three suggestions:

• Make -complevel 9 draw the sky normally during invulnerability. This is what Boom does. It was MBF that introduced the "negative" sky option.
  
• Force the standard Doom automap colors for compatibility levels 6 or less. You could include an extra option that overrides this, but not by default.
  
• Make PrBoom+ use player colors as in all the DOS executables, from Doom to MBF. That is, get rid of the changes in this respect.

[entryway]

myk said:

Make PrBoom+ use player colors as in all the DOS executables, from Doom to MBF. That is, get rid of the changes in this respect.[/list]

What is wrong with player colors?

[myk]

It's different. Compare indigo, for example. He looks kind of silver-colored in PrBoom/+ and of a more opaque gray in the DOS engines. Either the mapping is wrong or it's done by a different method.

PrBoom+:


Doom2:

[vdgg]

I don't know what I did, but upon pressing <TAB> the automap appears on the 3d-view "battle" screen. Normally it showed up on a black screen. How can I restore it?

[entryway]

myk said:

PrBoom+:
Doom2:

Am I blind? I don't see any difference.

vdgg said:

I don't know what I did, but upon pressing <TAB> the automap appears on the 3d-view "battle" screen. Normally it showed up on a black screen. How can I restore it?

Press 'O' key in automap mode.

[myk]

Those aren't the best screen shots ever, I'll admit, but check the shoulder guard in particular. In PrBoom+ the sprite is drawn with color values that are more distinct between each other. I'm not sure if it's not using colormap translation by number (instead using RGB approximation by brightness or the like) or simply starting from the wrong color number.

vdgg said:
I don't know what I did, but upon pressing the automap appears on the 3d-view "battle" screen. Normally it showed up on a black screen. How can I restore it?

You must have hit the key bound to key_map_overlay, which must have added the value to that effect on automapmode. I'd suggest clearing the bind (0x0) and setting automapmode to 0x0 (barebones automap) or whatever value you usually use. If you don't recall what value automapmode used to have, add back any features you were using with the automap menu under options and setup.

From what I can tell the overlay feature is undocumented and not supported in the menus. It must be some secret thing the developers use :p

[Gez]

entryway said:

Am I blind? I don't see any difference.

It's very subtle. Compare the shoulder on both pictures.

The PrBoom marine has greys that go as bright as 0x9f9f9f. The Doom2 marine only goes up to 0x777777.

[Doom_user]

The version of PrBoom-plus 2.5.0.7.test released on 2010-May-25 17:52 crashes with the message

I_SignalHandler: Exiting on signal: signal 11

whenever I try to start a new game, access options, or if I wait about 10 seconds at the main menu.

[Catoptromancy]

Mine works. Try a new cfg? If new cfg fixes problem then slowly adjust settings to determine which setting is causing it to crash.

Does this happen on a plain iwad with no pwads? Maybe iwad is corrupted. Can test with this one. http://free.doomers.org/doom2.wad.zip

[entryway]

Doom_user said:

The version of PrBoom-plus 2.5.0.7.test released on 2010-May-25 17:52 crashes with the message

I_SignalHandler: Exiting on signal: signal 11

whenever I try to start a new game, access options, or if I wait about 10 seconds at the main menu.

Thanks. Fixed I think.

Catoptromancy said:

Mine works. Try a new cfg? If new cfg fixes problem then slowly adjust settings to determine which setting is causing it to crash.

That's because you are using software mode.

btw, now glboom-plus supports custom per-texture details.

Like that
http://prboom-plus.sourceforge.net/detail11.png
http://prboom-plus.sourceforge.net/detail12.png

Instead of that:
http://prboom-plus.sourceforge.net/detail01.png
http://prboom-plus.sourceforge.net/detail02.png

More info and test details pack soon.

[Doom_user]

This happens with all iwads, whether or not a pwad is loaded. It happens with a fresh cfg as well as one taken from an older version of PrBoom-plus.

Edit:I just saw Entryway's post so it looks like this issue is resolved.

[Doom_user]

How is everyone getting alternate player colors in PrBoom-plus? Whenever I do multiplayer, Player 2 is gray for a fraction of a second and then immediately turns green for the duration of the game.

[entryway]

Doom_user said:

Whenever I do multiplayer

Do not use multiplayer in prboom+. It sucks and has bugs.

[ReFracture]

Yeah, even on LAN PrBoom+ is messed up.

[Grazza]

Well I dunno, it seemed OK when Opulent and I played some LAN coop in Prague in prboom+.

[Never_Again]

[entryway]

Never_Again said:

Ouch. What do you recommend instead - Skulltag? :P

Chocolate-Doom or vanilla PrBoom? At least you will be free from idiotic maps and absolutely idiotic skins which are used on slightly more than all skulltag servers by 101% of players ;) Joke.

[myk]

The problematic mouse bug I'm aware of only affects Windows 98 or my system, other than the player color and name bugs that also affect plain PrBoom, which are more cosmetic. The net code is okay for local play (a LAN or an opponent in the same urban area) but worse than the code in Doom over IPX or a TCP/IP tunnel or in Chocolate Doom.