PrBoom-Plus, ver. 2.5.1.4

[entryway]

myk said:

By the way, doesn't the way the bits fields in HG's DEHACKED lump are written, with spaces between the + signs, ruin the expected behavior under Boom compatibility?

DOS Boom can't handle this wad, so it does not matter

Another current PrBoom+ bug: Cheat codes with required variables, such as IDCLEVxx, IDMUSxx and IDBEHOLDx, do not work.

Works for me. Send me your cfg

[myk]

entryway said:
DOS Boom can't handle this wad, so it does not matter

Right, though I was thinking that setting compatibility level to 9 would make PrBoom+ read BEX data as if it were Boom. I guess that's not the case, then...

Works for me. Send me your cfg

I fixed it, as far as my setup is concerned. The L and U keys, used by those cheats, were bound to raising and slowing the game speed, which truncated the cheats. Various other binds, on the other hand, like movement, work in combination with cheats.

[hawkwind]

hawkwind said:

Thank You :)

I was a bit premature. Sure mouseb_forward -1 does stop the player moving forward with the mouse, but I now cannot use the mouse to open doors, or the mouse will strafe left or right, both of which I don't want. :(

Is there a way that I can use the mouse for full mouselook, fire and use ( door open etc. ) ONLY.

[myk]

No, you can't do that. Unless you tend to hit use and turn in circles at the same time for some reason, binding strafe there shouldn't be much of a problem because it's easy to hit use quickly toward any point you're looking at, using it only during the instant where you're activating the switch or door, when you're not moving.

[ReFracture]

The controls need work still.

[Never_Again]

[myk]

Never_Again said:
I remember seeing this discussed somewhere (I'm pretty sure myk was in on it), but it wasn't in the Tracker so I added it there.

That might have been another bug that affected software mode, fixed in v2.5.0.4: Fixed an issue where walls look full-bright from close up. Added a "render_old_lightmaps" config variable for 16 (old) or 32 (new) lighting levels.

[Never_Again]

[myk]

Yeah, that's my point. I was saying I only wrote about a bug making the weapon look darker in software mode.

[entryway]

Never_Again said:

myk said:

I fixed it, as far as my setup is concerned. The L and U keys, used by those cheats, were bound to raising and slowing the game speed, which truncated the cheats. Various other binds, on the other hand, like movement, work in combination with cheats.

Binding Q to mouselook breaks IDDQD, too.

I think it is correct. No?

Ok, fixed.

[myk]

One thing you could do is have PrBoom+ give some warning message when a user tries to set any such binds to a key used by a cheat. It could allow it but say "a cheat code may be ruined by binding the command to this key" (or "the command will be activated when some cheats are used," if you've made them work together.) Granted, cheats themselves can be modified through DeHackEd, but it's rare and stupid.

[The Green Herring]

A bit of a compatibility bug: Source ports prior to Boom do not support Boom's transparent midtexture linedef action (260,) yet PrBoom+ allows this under compatibility levels lower than Boom's, including (Ultimate) Doom/Doom II compatibility. To see what I mean, run this level under Doom2+, IDCLIP to the outdoor section at the south of the level, and look north at the windows on the middle, southern side of the building (while standing in sector 208, for example.) After this, do the same with PrBoom+ 2.5.0.5 under -complevel 2.

(The level claims to be for any limit-removing port, but is in fact a Boom level, which is how I discovered this.)

[entryway]

What is better for GUI patches with gl_linear?

1.


2.


The first one is currently used. I want to disable smoothing the edges of transparent fields (from GZDoom) for small patches to avoid these small glitches (1), but patches become 'more thin' (2). 2 and 7 digits on status bar are still ugly.

[Never_Again]

[entryway]

Never_Again said:

The only good thing about GZDoom is its alternative HUD, why not have something like that (as an option, at least) in prBoom-plus?

Nooo. I like Boom HUD. Can't play with statusbar. Do not see anything there after 10 years with Boom HUD.

[Super Jamie]

entryway said:

What is better for GUI patches with gl_linear?

Number 2 looks way better. Number 1 is too thin to be legible at a glance.


Also I love the Speed, Time and Stats displays. PrBoom+ is obviously the port of choice for speedrunners and demo recorders, or even just people who do unrecorded UV Max for fun like me, these are great things to have on the main play screen.

Keys, Weapons and Ammo seem kinda redundant with the full status bar there. If you took these away and just kept Speed, Time and Stats that would be the perfect HUD!

I find the fullscreen Boom status display useless, there is too much info to quickly find something in the middle of a fight, my health gets away from me because it's not prominent and you can't even see how much ammo you have for weapons other than the current one.

[The Green Herring]

To illustrate my earlier post, here are two screenshots on Stomping Grounds (STMPGRND.WAD).

Click here to see what the gray windows in this level look like under Doom2+ (and, by extension, Doom2.exe.)
Click here to see what the gray windows look like in PrBoom+ 2.5.0.5 with -complevel 2 (doom2.exe compatibility.) As you can see, Boom's transparent midtexture linedef action works in that -complevel, which should not be possible.

[entryway]

The Green Herring said:

To illustrate my earlier post, here are two screenshots on Stomping Grounds (STMPGRND.WAD).

Click here to see what the gray windows in this level look like under Doom2+ (and, by extension, Doom2.exe.)
Click here to see what the gray windows look like in PrBoom+ 2.5.0.5 with -complevel 2 (doom2.exe compatibility.) As you can see, Boom's transparent midtexture linedef action works in that -complevel, which should not be possible.

We are faced with the dilemma. Again. MBF sky transfer should not be available with Boom complevel also. I tried to disable. It sucks! Nobody want to play with MBF complevel, because of 'random' behavior of engine (depends from compat settings). But a lot of 'Boom wads' use sky transfer. So, it's available for Boom.

[Never_Again]

[Csonicgo]

Never_Again said:

I like it as well, it is functional and useful, just doesn't score in the looks department...

I agree. EE has adopted a graphical HUD system (unfinished) to get around that thing. it's just too 'busy" for me, like the health/ammo/armor "bars". this isn't a fighting game, anyway.

[Never_Again]

[GreyGhost]

entryway said:

What is better for GUI patches with gl_linear?

1.

2.

The first one is currently used. I want to disable smoothing the edges of transparent fields (from GZDoom) for small patches to avoid these small glitches (1), but patches become 'more thin' (2). 2 and 7 digits on status bar are still ugly.

I prefer the second one - it doesn't remind me of the old, slightly out-of-focus CRT monitor I retired last year. The status bar's 2 and 7 digits have always been ugly - I can live with that.

[gravitar]

prboom+ is my port of choice, but there are two things that keep bugging me in all versions I've tried to date (OS is xp sp2):

- the music volume slider in the menus doesnt work, I have to alt-tab and use the windows sound board (sb live with basic xp drivers)

- when using idclev to warp, I have to type it three times before it works, and 'sometimes' it works only with the keypad buttons

[entryway]

gravitar said:

- the music volume slider in the menus doesnt work, I have to alt-tab and use the windows sound board (sb live with basic xp drivers

I have no issues with sound/music with prboom about 6 years. All problems are gone in day when I thrown out my SB Live to rubbish heap and 'replaced' it with Realtek

gravitar said:

- when using idclev to warp, I have to type it three times before it works, and 'sometimes' it works only with the keypad buttons

You are alone with that. Can't help.

[Jodwin]

Minor software mode bug: If you're playing a wad that has menu graphics tall enough that they go over the status bar, entering and exiting the main menu while playing makes the menu graphic be drawn over the status bar.

That probably sounds confusing, but you can test this with HR2final.wad: Start playing in software mode with status bar visible, press ESC to enter menu, leave menu and see it for yourself. Increasing screen size to hide status bar and then bringing it back again fixes it. This bug doesn't seem to happen in glboom+.

[entryway]

Jodwin said:

Minor software mode bug: If you're playing a wad that has menu graphics tall enough that they go over the status bar, entering and exiting the main menu while playing makes the menu graphic be drawn over the status bar.

Fixed.

[ReFracture]

gravitar said:

prboom+ is my port of choice, but there are two things that keep bugging me in all versions I've tried to date (OS is xp sp2):

- the music volume slider in the menus doesnt work, I have to alt-tab and use the windows sound board (sb live with basic xp drivers)

- when using idclev to warp, I have to type it three times before it works, and 'sometimes' it works only with the keypad buttons

idclev works fine for me. Must be something else going on.

As for the music slider, yes, if you are using an SB Live with Creative's own Midi sound fonts, PrBoom+ can't adjust the music. If you go to control panel>sounds and audio devices>audio tab>MIDI music playback and change it back to Microsoft GS Wavetable SW Synth, then PrBoom+ can do it.

Personally I think MS's Wavetable sounds better than creative's midi. I know MS's leaves much to be desired, but Creative's is just terrible.

entryway said:

I am not surprised. Creative is shit as well as ATI is shit. I have no issues with sound/music with prboom about 6 years. All problems are gone in day when I thrown out my SB Live to rubbish heap and 'replaced' it with Realtek

Fortunatly PrBoom+ being unable to change the music volume is the biggest of my problems with this Creative card. My onboard is a c-media that produces a lot of static, so I can't use that shit.

[entryway]

gravitar said:

- the music volume slider in the menus doesnt work, I have to alt-tab and use the windows sound board (sb live with basic xp drivers

Mike.Reiner said:

Fortunatly PrBoom+ being unable to change the music volume is the biggest of my problems with this Creative card. My onboard is a c-media that produces a lot of static, so I can't use that shit.

Does it work with Creative?

http://prboom-plus.sourceforge.net/prboom-plus-2.5.0.6.test-win32.zip

[gravitar]

Mike.Reiner said:

If you go to control panel>sounds and audio devices>audio tab>MIDI music playback and change it back to Microsoft GS Wavetable SW Synth, then PrBoom+ can do it.

That sounds indeed much better, and the music slider works again.

entryway said:

Does it work with Creative?

http://prboom-plus.sourceforge.net/prboom-plus-2.5.0.6.test-win32.zip

Yes it works, though I probably stay with Mike's suggestion anyway. Thanks to both of you.

[entryway]

gravitar said:

Yes it works

Any bad effects with this code?

#ifdef _WIN32
#include <Mmsystem.h>
#pragma comment( lib, "winmm.lib" )
void Mix_VolumeMusic_AllMIDIDevs(int volume)
{
  int calcVolume;
  MIDIOUTCAPS capabilities;
  unsigned int i;

  if (volume > 128)
    volume = 128;
  if (volume < 0)
    volume = 0;
  calcVolume = (65535 * volume / 128);

  SDL_LockAudio();

  //Device loop
  for (i = 0; i < midiOutGetNumDevs(); i++)
  {
    //Get device capabilities
    midiOutGetDevCaps(i, &capabilities, sizeof(capabilities));

    //Adjust volume on this candidate
    if ((capabilities.dwSupport & MIDICAPS_VOLUME))
      midiOutSetVolume((HMIDIOUT)i, MAKELONG(calcVolume, calcVolume));
  }

  SDL_UnlockAudio();
}
#endif

void I_SetMusicVolume(int volume)
{
#ifdef HAVE_MIXER
  Mix_VolumeMusic(volume*8);

#ifdef _WIN32
  if (Mix_GetMusicType(NULL) == MUS_MID)
    Mix_VolumeMusic_AllMIDIDevs(volume*8);
#endif

#endif
}