Pr/GLBoom+ 2.5.0.7 released

[Gez]

After ZDoom and Risen 3D, it is PrBoom+'s turn to get a new official version. The changelog shows a lot of compatibility and improvements, many bug fixes, and several new features, including suppport for DeePBSP and uncompressed ZDBSP nodes, dynamic music changing through the new MUSINFO lump (also supported by the aforementioned ports), and improved music playback through a custom version of the SDL_Mixer library. On the GLBoom+ front, there is in addition support for GZDoom skyboxes, custom detail texture definitions, and blending of animated flats and wall textures.

[Phml]

Lots of good stuff. Sky being drawn normally while in invul with complevel 9 I'm not fond of, though. The negative sky is something that doesn't affect gameplay and makes the game look better, much like higher resolution, GL rendering (imho, obv.). To have it as an option would have been nicer.

[Graf Zahl]

Agreed. That one's clearly more a user preference than a compatibility issue.

[entryway]

It should be a single option for all such cases I think (oh faces, negative sky, etc).

PrBoom already has comp_sound - "Retain quirks in Doom's sound code". So it can be similar: "Retain quirks in Doom's graphics code"

[CODOR]

That figures, I installed 2.5.0.6 to my laptop last night...

[Solarn]

Yay, Sunder should now run fully in GLBoom+!

[myk]

Phml said:
The negative sky is something that doesn't affect gameplay and makes the game look better, much like higher resolution, GL rendering (imho, obv.)

I find everything turned negative ugly because it's more monotonous, but it does affect playability a little, as with the normal sky flying or overhead things (and grounded or low things, when the sky is on the floor) become easier to see while invulnerable. A "negative" cacodemon will stick out like a sore thumb against a red sky, for example. Taste here is probably a matter of habit, more than anything.

While I'm not too much of a fan personally because, like I say above, these things can have some marginal effect on play, I suppose PrBoom+ could have an additional, general "cosmetic bugs" option like Andrey suggests, but the defaults should stay close to what it's emulating, especially in a case like this; the effect appears glaringly in more than one DEMO sequence in the released DOOM versions (at least v1.2 and v1.666, the most widely distributed ones during the "supported game" era) which means the developers probably saw it and liked it enough to keep it till the end. I bet the Boom devs thought about that. Only later did Killough incorporate comp_skymap to MBF, which will be applied as selected regardless of the demo version being played (Doom, Boom or MBF-specific). PrBoom changed things from MBF in hard-coding the sky during different compatibility levels, inaccurately in the case of Boom, but MBF could optionally play even MBF demos (or just play the game) with the vanilla or Boom sky behavior, if the player wanted.

The only "problem" with the normal sky under invulnerability is that it may seem "illogical" but that's debatable even under such an irrelevant aspect, as the negative effect can be seen as an emanation that can be easily caught only on things that are nearer to the invulnerable observer. The sky is always much farther away than anything drawn in the level, so the character doesn't perceive from it the force or quality that becomes evident when he's invulnerable.

Generally speaking, some bugs (HOMs, tutti frutti, Medusa, double door sound, critical errors, crashes) are rather indisputable and can be fixed for all compatibilities, while others are more debatable (sky, ouch face, falling sound) and, I think, should be left as quirks of the engine being emulated, during emulation. This leaves out any even minor play changes as expected from a port suitable for competitive play, while providing a cleaner and more stable play experience as expected from a modern-styled port.

[Mechadon]

Gez said:

...DeePBSP and uncompressed ZDBSP nodes...

Definitely my favorite new feature for this release. Thanks to everyone who made that possible :D.

[Ralphis]

entryway, does this release have the sdl mouse fixes in gdi discussed on these forums a few months ago? If so, could you please indicate where in the revisions these may have occured? Thanks in advance!

[entryway]

Ralphis said:

entryway, does this release have the sdl mouse fixes in gdi discussed on these forums a few months ago? If so, could you please indicate where in the revisions these may have occured? Thanks in advance!

Do you mean this topic?
http://www.doomworld.com/vb/showthread.php?postid=885046#post885046

I did not commit changes and I even forgot to save them. Pastebin also forgot changes heh.

[printz]

Gez said:

After ZDoom and Risen 3D, it is PrBoom+'s turn

I believe Eternity is going to jump the bandwagon soon (see how the later SVNs are named).

I also agree with myk. If the id guys could have changed the sky, they would have made it.

[entryway]

printz said:

I also agree with myk. If the id guys could have changed the sky, they would have made it.

Yeah, such things are funny a little. I remember how port authors tried to 'fix' 'ooh face' behaviour. Lol, but each port had its own version of the 'fix' when I checked. Eternity, ZDoom and PrBoom had three different algorithms.

[Manc]

entryway said:

Do you mean this topic?
http://www.doomworld.com/vb/showthread.php?postid=885046#post885046

I did not commit changes and I even forgot to save them. Pastebin also forgot changes heh.

I would also be very interested in knowing what you did there, considering the pastebin expired.

[entryway]

Mancubus II said:

I would also be very interested in knowing what you did there, considering the pastebin expired.

But link in the quoted post explains it, doesn't?

For uncapped framerate I accumulates dx\dy in each frame instead of getting it only once per tic. For capped framerate I do it periodically in waiting loop. Something like:

while (!runtics)
{
  SDL_GetRelativeMouseState(&x, &y)
  tic_dx += x;
  tic_dy += y;
  CenterMouse()

[Mr. T]

printz said:

I believe Eternity is going to jump the bandwagon soon (see how the later SVNs are named).

I also agree with myk. If the id guys could have changed the sky, they would have made it.

http://img535.imageshack.us/img535/5558/photobw.png

[entryway]

Mr. T said:

http://img535.imageshack.us/img535/5558/photobw.png

That's glboom's 'invert image' technique for invul effect instead of real black and white or using of colormap. So it is not ID's code. It is proff_fs's code :)

GLBoom uses an inverting for invul just because proff_fs was lazy to support colormaps for OpenGL. And it is impossible in terms of GLBoom's abilities (no shaders, no stencil, no rendering to texture) to make something inverted and something not, because effect is applied for resulting whole picture in gld_EndDrawScene()

[Revved]

I don't know if it's me, but for some reason, Prboom+ 2.5.0.7 for Mac seemed to be avant-garde, due to the only texture being various shades of black and white.

http://img687.imageshack.us/img687/9448/prboomscreensnapz001.jpg

[entryway]

Revved said:

I don't know if it's me, but for some reason, Prboom+ 2.5.0.7 for Mac seemed to be avant-garde, due to the only texture being various shades of black and white.

Does "gl_compatibility 1" in cfg fix the problem? Attach your cfg. Will be better if you will replay in this topic.