PrBoom+ 2.6.66 (Jun 20, 2023)

12 minutes ago, Rathori said:

Super Ultimate PrBoom++ Turbo 2020 DX Ultra! Redux HD: Re-emergence - Definitive Edition

 

  Hide contents

Although on a more serious note I would just go for PrBoom+ 3.0.

 

But that name can also impliy it's a mere continuation of Andrey's port, which it isn't.

5 hours ago, drfrag said:

If Proff agrees just PrBoom.

I like it, simple but classic. I think no one would care if this name used to be predecessor's.

Although I expect the name bike-shedding thread was split off from this thread for a reason and should probably be used if we're bike-shedding again, given Graf's push for re-implementing some things in C++, PrBoom++ makes sense to me.

UBoom++.

Prune Doom.

Which of course stands for PrBoom UMAPINFO New Engine Doom.

And because of the runs.

I am in the camp ProBoom or UBoom Plus.

A more humorous take would be ZahlonBoom/ZahlunBoom. Read that as either Salon Boom, Zahl on Boom or Sylvester Zahllone.

8 minutes ago, Redneckerz said:

ZahlonBoom/ZahlunBoom.

Sounds like a made-up martial arts technique :p .

23 minutes ago, seed said:

 

Sounds like a made-up martial arts technique :p .

Quille from Street Fighter, maybe? Sonic Boom! :P

UBoom is classy enough, and not pretentious. I like it. Aside from the fact that everything involving the word "boom" is silly almost by definition, unless you're used to it to the same degree as people in this community.

4 hours ago, Redneckerz said:

Sonic Boom

Actually not a bad idea if the audio code is overhauled...

Had some thought about it, but if it is a continuation of PrBoom+ it will also have a GL renderer. As far as i could dig in, that supports OpenGL 2.0 (with shaders), OpenGL 1.3 and OpenGL 1.1 as a compat flag.

Does GLUBoom sound good to you? I mean, you kinda do *stick* to it.. GLProBoom actually sounds better in this variant.

I see little reason to keep GL as a separate executable, TBH.

4 minutes ago, Da Werecat said:

I see little reason to keep GL as a separate executable, TBH.

You mean the other way around - the prboom.exe. GlBoom does not support transparent projectiles, and the prboom executable does not have the textured automap.

If all these issues get rectified then sure, I don't think there's any point in keeping the OG prboom executable.

13 minutes ago, Redneckerz said:

Does GLUBoom sound good to you? I mean, you kinda do *stick* to it.. GLProBoom actually sounds better in this variant.

GLUBoom doesn't sound too bad tbh.

8 minutes ago, Da Werecat said:

I see little reason to keep GL as a separate executable, TBH.

If that's the case then starting from UBoom it should be treated as a seperate source port with a seperate tree.

Despite GLBoom's existence, there is surprisingly little to find about all its possibilities - and i believe its primarly because it co-exists in the PrBoom archives.

If Graf wants to continue ZahlonBoom (I am keeping it!), this is something that could be considered. Might aswell be a more true-to-vanilla experience to co-exist with GZDoom and for lower end hardware.

That way Graf also checkmates the current criticism about GZDoom about that.

1 minute ago, seed said:

 

You mean the other way around - the prboom.exe. GlBoom does not support transparent projectiles, and the prboom executable does not have the textured automap.

 

If all these issues get rectified then sure, I don't think there's any point in keeping the OG prboom executable.

 

 

GLUBoom doesn't sound too bad tbh.

I get references to GLU Mobile which is a major mobile game publisher. That is just me though.

But lets have @Graf Zahl here and hear what he has to say on this matter.

What I meant is having one executable supporting different renderers. I think they were separated for compatibility with truly ancient systems, but I don't know if it's relevant to anyone today.

9 minutes ago, Da Werecat said:

What I meant is having one executable supporting different renderers. I think they were separated for compatibility with truly ancient systems, but I don't know if it's relevant to anyone today.

Ah, fair enough, this sounds like a good idea to me too.

I also recall it was split for the same reasons.

8 hours ago, Da Werecat said:

What I meant is having one executable supporting different renderers. I think they were separated for compatibility with truly ancient systems, but I don't know if it's relevant to anyone today.

It may be relevant in the future again when Apple finally decides to ditch OpenGL for good. But long term it is probably inevitable to swap out the GL renderer entirely, because the current one is targeting really ancient tech and going to be obsolete rather sooner than later. And for a replacement there's not many options to choose from. GZDoom is the only one that has a Vulkan implementation that's future proof.

I actually wonder how it might work with a so much less demanding game engine driving it.

2 minutes ago, Graf Zahl said:

when Apple finally decides to ditch OpenGL for good.

On a fun related note, with each new Apple OS two unfortunate things seem to happen: 1) they stuff GL libraries into deeper and darker places, making compiling gl applications annoying, and 2) the performance gets worse and worse.

For instance, I'd been running glb+ on everything from 10.6 to 10.12, and it always outperformed prb+ on big elaborate maps by a healthy margin. But as of 10.14, GL runs very poorly, worse fps than software regardless of map. I'm unsure if this is a result of Apple no longer caring about GL performance (i.e. not optimizing anything in its favor under the hood), or if it's something that could be remedied in the renderer code. Apparently Apple wants developers to switch over to some proprietary thing called Metal, but from a developer standpoint that sounds like a whoooooole lotta work to accommodate a virtually nonexistent userbase (besides myself I only know of like 2-3 people running prb+ on os x, and I vastly prefer the look of software gfx anyways :p).

18 minutes ago, Ribbiks said:

 But as of 10.14, GL runs very poorly, worse fps than software regardless of map.

I cannot say this surprises me. 10.14 was when they deprecated OpenGL.

At my workplace there's lots of Macs but most developers have become utterly wary of upgrading the OS, because every time it causes problems, from critical software no longer working to various kinds of stability issues to pretty much every other thing Windows has been lambasted for.

I'm not really sure where this will end but the current management seems to be intent on turning the Mac into an iPad with keyboard to peddle to their less discriminating customers.

How much do we know about the GL renderer for GLBoom+? Would it be worthwhile to, at some point in the future, trying to port it to Vulkan and then using MoltenVK to build it for macOS?

57 minutes ago, Graf Zahl said:

I actually wonder how it might work with a so much less demanding game engine driving it.

It's gonna be able to reach 5000fps and be capable of flying to the moon with Vulkan .

4 minutes ago, Altazimuth said:

How much do we know about the GL renderer for GLBoom+? Would it be worthwhile to, at some point in the future, trying to port it to Vulkan and then using MoltenVK to build it for macOS?

The renderer is really, really outdated, it uses features that have no meaning anymore on modern hardware, it just happens to still work because the drivers today come with the necessary features to support OpenGL 1.x. You'd have to do a complete rewrite from the ground up to make it work with the newfangled APIs, Vulkan requires a totally different approach to submit render jobs. Ultimately it would be a lot easier to take GZDoom's renderer, which has already implemented all these things, and strip out the unneeded parts (i.e. slopes, 3D floors and most of the portal code) rather than trying to rewrite the current implementation.

7 hours ago, Graf Zahl said:

Ultimately it would be a lot easier to take GZDoom's renderer, which has already implemented all these things, and strip out the unneeded parts (i.e. slopes, 3D floors and most of the portal code) rather than trying to rewrite the current implementation.

Portals would be nice to see as a new feature.

2 minutes ago, Archi said:

Portals would be nice to see as a new feature.

It would require adding in software too, which would be a nightmare. Additionally you'd need the playsim stuff to work and it all becomes a very large faff. It'd probably be easier to make Eternity record complevel 9 and 11 demos.

2 minutes ago, Altazimuth said:

It would require adding in software too, which would be a nightmare. Additionally you'd need the playsim stuff to work and it all becomes a very large faff. It'd probably be easier to make Eternity record complevel 9 and 11 demos.

Having prb+ features in eternity would be awesome as well.

Though it's mostly lack of truecolor renderer and small things (like non-scalable crosshair) that push me away from using it. But I guess it's possible to say that these are a features from prb+ eternity lacks?

I know people try to go their own way with source ports, but from a player/mapper perspective it'd be better if every advanced port had mostly the same functionality.

Portals in PrBoom+ may be nice, but the code needed to handle them is extremely complex - and what's worse - totally incompatible with its demo compatibility needs. Of the 3 big things - slopes, 3D floors and portals it is by far the least likely to happen. Even 3D floors clash badly with infinitely tall actors. Slopes would be easiest - but even here it'd necessitate quite a bit of code duplicationt to handle the different physics.

Purely visual portals are a different matter, stuff like skyboxes, mirrors or stacked sector the player cannot cross. Of course the resulting engine would probably become a Frankensteinian PrZEternity++ then. :D Do you want that?

Obviously the main blocker would be the software renderer, because there is none that supports all the nice to have features. Eternity does not have 3D floors and ZDoom lacks robust portals. Writing a new one is out, good luck finding a developer willing to do it.

35 minutes ago, Graf Zahl said:

Portals in PrBoom+ may be nice, but the code needed to handle them is extremely complex - and what's worse - totally incompatible with its demo compatibility needs.

Could it not be done in a similar way to how Eternity got away with it?

Of course - but have you checked how much code that is? It's a very invasive feature going into every tiny corner of the play code. Eternity had to duplicate the entire actor movement code to allow portals because the original could not be changed enough to handle proper vertical collision detection without whacking demos. The same problem also exists for supporting 3D floors or even 3D midtextures (or ZDoom bridges.) These are features which are fundamentally at odds with demo compatibility because they require support in core functions. Sure, adding a secondary code path could be done - but then we get into the same territory which many "classic" players do not like, i.e. a fundamental alteration of gameplay physics - never mind that they are a separate code path - that code path would inevitably be closer to ZDoom than to classic Doom. That even applies to Eternity right now which uses quite a bit of ZDoom code in its z-aware movement code.

Sorry, but if we decided to add new features, even Hexen/UDMF map support would be magnitudes easier than fully 3D aware collision detection.

The new mapping features could be added in a way that the relevant code never runs when they are not present, e.g. new linedef types are a rather simple thing to do compared to new physics.

On 1/17/2020 at 11:39 AM, Da Werecat said:

What I meant is having one executable supporting different renderers. I think they were separated for compatibility with truly ancient systems, but I don't know if it's relevant to anyone today.

Whilst unifying would make sense for PrBoom, the current implementation basically does that already in a primitive way - When you download a PrBoom build, it contains GLBoom as a seperate exe, but they are unified in the same archive.

Its partially also why i believe so little information outside source code information can be found on GLBoom. It simply is just another executable, yet it does a lot of different things. This should be reflected one day somewhere.

19 hours ago, Altazimuth said:

How much do we know about the GL renderer for GLBoom+? Would it be worthwhile to, at some point in the future, trying to port it to Vulkan and then using MoltenVK to build it for macOS?

GLBoom+ has 3 rendering modes:

• OpenGL 2.0. This is also where you have Shader support.
• OpenGL 1.3. Together with the Shader mode, these are the main support levels.
• OpenGL 1.1. This is listed as a compatibility mode.

As you can see the best GLBoom offers is graphics support for cards dating back to the Radeon 9000 series from 2002. By modern comparison, it is antique, but atleast in that renderpath you can do some rudimentary shader stuff.

18 hours ago, Graf Zahl said:

 

The renderer is really, really outdated, it uses features that have no meaning anymore on modern hardware, it just happens to still work because the drivers today come with the necessary features to support OpenGL 1.x. You'd have to do a complete rewrite from the ground up to make it work with the newfangled APIs, Vulkan requires a totally different approach to submit render jobs. Ultimately it would be a lot easier to take GZDoom's renderer, which has already implemented all these things, and strip out the unneeded parts (i.e. slopes, 3D floors and most of the portal code) rather than trying to rewrite the current implementation.

GLZDoom when? ;)

But yeah, its outdated stuff, but it does ensure that GLBoom, which focuses on demo compatibility, can run on literally anything. GZDoom's feature set targets something significantly more modern (And still a decade old!) to get all the visual fidelity out ofi t.

More modern and yet not quite, even GeForce 200 series potatoes support GL 3.0.

I'm actually amazed GlBoom goes as far back as GL 1.1, holy shit that's some stone age stuff. I always lived under the assumption GlBoom's render was GL 2.1 but apparently it isn't even that, wow.