PrBoom+ 2.6.66 (Jun 20, 2023)

[ReaperAA]

19 hours ago, Grain of Salt said:

Did you make some kind of faustian bargain where you have to copy every bad feature from zeedoom in exchange for worldly riches

 

Two things:

- Firstly it is not a (G)ZDoom feature at all. It's a Doom Retro originated feature.

- Secondly what did Fabian do to deserve this completely unnecessary and idiotic comment.

Edited February 9, 2021 by ReaperAA

[Shadow Hog]

I do think there are legitimate criticisms to be made about the feature if it's hardcoded like that - inflexibility with custom monsters, inflexibility with custom palettes, et cetera - given that I thought at least part of the goal of this fork was to break free of hardcodedness (admittedly the stated goal was more about episode structure than "all hardcoded bits period", but...). Not that I have better solutions off-hand, regrettably. Still, best to nitpick these things in their infancy than years later when these features are well-established and now inflexible.

 

That said, yeesh at the shitstorm that arose. Even if it's a relatively inflexible solution at the moment, I can't see how it'd warrant all that.

[Marcaek]

On 1/26/2021 at 11:02 AM, maxmanium said:

 

How had nobody thought of this yet?

 

Also, this isn't really necessary, but I thought, what about making TNTCOMP take a two-number buffer a la IDCLEV, instead of having to cycle through everything?

 

It's funny how this is such a minor thing, but TNTCOMP is borderline unusuable without it. I think it's a good idea

[GoneAway]

@fabian maybe you should make a 2.6 thread so we can start fresh :^)

[Da Werecat]

4 hours ago, Shadow Hog said:

Not that I have better solutions off-hand, regrettably.

 

I don't think that the old mods can be helped. It will remain on the player to investigate everything that looks wrong.

 

For new mods, it should be enough to externalize the colormaps (if they aren't already). It's already a thing in this port, since there's a whole bunch of color tables for recoloring fonts. If I'm wrong about the method employed, and the port recolors blood based on an RGB value, then it's a bit more complicated, since it would require a definition lump of sorts, possibly breaking new ground. But at the same time it would mean the feature is much safer with custom palettes.

 

My favorite solution would be having separate objects. This has plenty of drawbacks as far as implementation goes, lots of work and things to decide. Intriguing possibilities though.

[JadingTsunami]

As I understand it, the goal of the port at this point is to stay mostly true to the modding abilities in the baseline PrBoom-Plus with UMAPINFO. Expansions of existing abilities like DEHEXTRA, some bug fixes, and visual quality-of-play enhancements are on the table but larger overhauls or entirely new capabilities are best left to other ports.

[seed]

I still dream of the day someone steps in to move PrBoom to GL 4.x, replace the primitive sound system, and toss the current mouse handling into the deepest dumpster.

 

Speaking of which, any chance of the mouse code getting replaced at some point with that of a different port? Pretty much all the other ports have better input than PrBoom does, even without VSync it still feels less responsive than the rest.

[Archi]

What's the point of migrating to GL 4.x?

[seed]

1 minute ago, Archi said:

What's the point of migrating to GL 4.x?

 

Is there any point in running on legacy GL anymore?

 

Running on such old tech does no favors for far more relevant hardware of nowadays.

[Archi]

7 minutes ago, seed said:

Is there any point in running on legacy GL anymore?

Is there a point on rewriting? Don't get me wrong, I'm not against it, but I don't see what could it accomplish. FPS is not going to skyrocket and in the end we'll miss support for older GPUs.

[seed]

1 minute ago, Archi said:

Is there a point on rewriting? Don't get me wrong, I'm not against it, but I don't see what could it accomplish. FPS is not going to skyrocket and in the end we'll miss support for older GPUs.

 

Perhaps, but at least it won't rely on legacy support anymore, and it can open the doors to other potential enhancements too.

 

You mention "older GPUs", but you do know that essentially translates to "ancient", right? GL 2.x is 15yrs old at this point, who is even still running such hardware nowadays? I don't see how pulling the plug there would cause any harm.

[ketmar]

20 minutes ago, seed said:

I don't see how pulling the plug there would cause any harm.

new code, new bugs. it is absolutely not hard to emulate sane OpenGL API with "modern" one, if it would be necessary. rewriting perfectly working thing for the sake of rewriting is usually not the best idea for the project. ;-)

[Cacodemon345]

Upgrading PrBoom+ to GL 4.x will do nothing but bad things for it overall; many users of the source port are still stuck on shitty hardware incapable of driving anything further than DirectX 9 or OpenGL 2.0 (OpenGL 1.4 if stuck on ancient Intel GMA crap).

[Gez]

58 minutes ago, seed said:

GL 2.x is 15yrs old at this point, who is even still running such hardware nowadays?

Lots of people in poorer countries, such as in South America. That's the reason "GZDoom GEC Masters Edition" was forked from an older branch of the GZDoom codebase, for example.

[seed]

15 minutes ago, Gez said:

Lots of people in poorer countries, such as in South America. That's the reason "GZDoom GEC Masters Edition" was forked from an older branch of the GZDoom codebase, for example.

 

Fair enough, no can do.

[Spectre01]

At the very least, it would be nice if GLBoom+ had proper projectile translucency (and maybe a palette tonemap). The fact that translucency is handled on a complevel/format basis in PRBoom+ seems archaic as well; just make it a global setting.

[Dimon12321]

The only thing I don't like in GLBoom+ is it doesn't render missing textures (like here) comparing to software render which replaces them. Fortunately, it's a rare event.

Edited February 10, 2021 by Dimon12321

[LincolnPark96]

One thing that i would love to see implemented someday, is the possibility of emulate the software palette in GLboom.

[Da Werecat]

What's the common reason to use the GL renderer in this port? Speed boost?

[ketmar]

1 hour ago, LincolnPark96 said:

One thing that i would love to see implemented someday, is the possibility of emulate the software palette in GLboom.

i don't think that it is possible without using shaders (and thus bumping OpenGL version, and rewriting possibly big parts of the renderer).

[GarrettChan]

1 hour ago, Da Werecat said:

What's the common reason to use the GL renderer in this port? Speed boost?

Yes, it seems in my old computer, using software renderer will make it really slow, especially streaming or recording.

 

Though, this shouldn't be a problem on my new one but I'm stuck with it... The annoying thing about GL renderer is when something is dark, it's dark... Software, you can see something.

[seed]

1 hour ago, Da Werecat said:

What's the common reason to use the GL renderer in this port? Speed boost?

 

Kind of the sole reason since it has barely, if any other enhancements.

 

A comparison with other GL focused ports would be pointless since PrBoom is so basic it can't even support something like dynamic lights.

Edited February 10, 2021 by seed

[SiFi270]

I mainly use it because it's currently the only renderer that supports widescreen statusbars. I know I already brought that up the other day, but that post turned out to be poorly timed and lost in another debate, so I feel at least a little justified in being a broken record.

 

On a similar note, I recently noticed that the widescreen extensions still briefly disappear with OpenGL during the screen melt transition.

[wallabra]

15 hours ago, seed said:

I still dream of the day someone steps in to move PrBoom to GL 4.x,

 

Please no.

[JadingTsunami]

3 hours ago, SiFi270 said:

I know I already brought that up the other day, but that post turned out to be poorly timed and lost in another debate, so I feel at least a little justified in being a broken record.

 

I looked into it and I have it working on my machine. But it will require explicit support for widescreen statusbars, whereas the previous version is passively working with the OpenGL renderer. I suggest filing an issue on GitHub to track this as a feature request.

[seed]

1 hour ago, Gustavo6046 said:

Please no.

 

Then DirectX 12 it is, or Vulkan ( ͡° ͜ʖ ͡°) . Oh YES.

 

Rest in pepperoni potatoes.

[wallabra]

lol, vulkan is just opengl 5+ with a lower level api exposed. this is doom, the only reason you'd want modern opengl is to milk those sexy shaders, but you don't need them. it's not really what prboom+ is about either, it's about making the true experience of doom accessible, user-friendly, and, well, true. it's not very complicated, you're lucky i didn't put your username in another doomworld essay of mine. plus it's 3 am lol so sorry if i sound a bit absent minded or anything

[seed]

1 hour ago, Gustavo6046 said:

you're lucky i didn't put your username in another doomworld essay of mine

 

??

[ketmar]

7 hours ago, Gustavo6046 said:

lol, vulkan is just opengl 5+ with a lower level api exposed

...because "modern OpenGL" is not OpenGL by itself, yeah.

 

(let the war begin!)

[wallabra]

8 hours ago, seed said:

??

 

I dunno lol I was almost blacking out on the chair