PrBoom+ 2.6.66 (Jun 20, 2023)

[Graf Zahl]

4 minutes ago, seed said:

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.

 

Even a lowly Geforce 8600 supports GL 3.0. I still got an old laptop from 2008, once I put a new hard drive in it will be able to play GZDoom again, with semi-decent performance on reasonably sized levels.

 

The GlBoom renderer is 20 years old and has only seen minimal refactoring over the years, of course it still supports the old standards.

 

12 minutes ago, Redneckerz said:

But yeah, its outdated stuff, but it does ensure that GLBoom, which focuses on demo compatibility, can run on literally anything.

 

Like I said, not for long anymore. Apple will surely ditch OpenGL in a few years and the toaster systems this can still run on are more theoretical than really existing. It's better to use the software renderer on them anyway. I can still remember how problematic OpenGL was on my first systems with hardware accelerated graphics. It's also the same stupid attitude of "we serve everybody" while forgetting that you are totally underserving more than 95% of your user base with such code. The difference between GL 2.1 and GL 3.3 is lightyears. GL 3.3 means you can write a future proof renderer. GL 2.x means you are stuck in the dark ages that cannot be upgraded to modern standards.

 

[Redneckerz]

14 minutes ago, seed said:

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.

A Geforce 210 would be heavily overkill for this haha.

 

But yeah, GL 1.1, means even GPU's from the previous century can run this thing hardware accelerated. And considering it still got updates (Well, till Entryway went MIA and Graf is now taking it over) it is one of the last, if not the last updated hardware accelerated port that technically could still run on such rigs.

 

Which for some nerdy reason i find endlessly entertaining.

 

4 minutes ago, Graf Zahl said:

 

Even a lowly Geforce 8600 supports GL 3.0. I still got an old laptop from 2008, once I put a new hard drive in it will be able to play GZDoom again, with semi-decent performance on reasonably sized levels.

 

The GlBoom renderer is 20 years old and has only seen minimal refactoring over the years, of course it still supports the old standards.

 

 

Like I said, not for long anymore. Apple will surely ditch OpenGL in a few years and the toaster systems this can still run on are more theoretical than really existing. It's better to use the software renderer on them anyway. I can still remember how problematic OpenGL was on my first systems with hardware accelerated graphics. It's also the same stupid attitude of "we serve everybody" while forgetting that you are totally underserving more than 95% of your user base with such code. The difference between GL 2.1 and GL 3.3 is lightyears. GL 3.3 means you can write a future proof renderer. GL 2.x means you are stuck in the dark ages that cannot be upgraded to modern standards.

 

So, lets say you will continue working on this, you will likely just leave the GL renderer alone.

Lets say this gets a new name, will your first releases retain that renderer or just wholly obmit it?

 

I agree with what you are saying, but id like to add - GLBoom isn't pursuing GZDoom's rendering paradigms. It is ancient, but it also means that the rest of the code base (Its PrBoom after all) is not.

 

Though i have not read much about demo authors actually using GLBoom to record their demo's. It is in a weird place, really.

[Graf Zahl]

13 minutes ago, Redneckerz said:

A Geforce 210 would be heavily overkill for this haha.

 

But yeah, GL 1.1, means even GPU's from the previous century can run this thing hardware accelerated. And considering it still got updates (Well, till Entryway went MIA and Graf is now taking it over) it is one of the last, if not the last updated hardware accelerated port that technically could still run on such rigs.

 

 

Yeah. Geforce 4. Which was barely able to render the game at 35 fps at 800x600.

But in the end, what is more important? Seeing to it that the overwhelming majority of today's users can use the thing or that we can brag to work on an engine that thoretically still compiles on hardware so old that no other software in existence works on it?

 

Consider this: GZDoom dropped Windows XP support last year. Why? The user base was 0.13% of reporters in the last survey before, in absolute numbers that translated to 42 persons. This isn't enough to warrant more work. I'm not sure how PrBoom+ fares, but since it uses SDL2 it cannot run on XP anymore, don't even mention Windows 9x. The supposed user base simply does not exist anymore. I'll grant you GL 2.0, but not 1.1 - but ultimately the only way to get some meaningful info here would be to do the same as GZDoom did: Run a survey.

 

 

13 minutes ago, Redneckerz said:

 

So, lets say you will continue working on this, you will likely just leave the GL renderer alone.

 

The GL renderer is not the highest priority, the most complaints by users who asked me to change stuff were about the sound system. So this definitely will get replaced because I see something to be gained here.

I'm not sure how this will affect some of the novelty features in there, like speaker sound, but here I also have to ask: Are people actually using this or was this just a tinkerer satisfying his own urges to get this working?

 

 

13 minutes ago, Redneckerz said:

Lets say this gets a new name, will your first releases retain that renderer or just wholly obmit it?

 

There won't be a new name. I still hope that Proff is picking it up and makes it official PrBoom. If that falls through it may be thought about.

 

 

13 minutes ago, Redneckerz said:

I agree with what you are saying, but id like to add - GLBoom isn't pursuing GZDoom's rendering paradigms. It is ancient, but it also means that the rest of the code base (Its PrBoom after all) is not.

 

The fun thing is that nothing of PrBoom's design goals would prohibit a more modern GL renderer.

Like you said, some parts here are ancient. While PrBoom has great compatibility, it also has some serious issues in the technical area because it is so old, e.g. mostly non-functional frame interpolation, the aforementioned sound problems and the ancient renderer. Modernizing this, while keeping its game core intact, is the way to proceed here.

 

 

[Da Werecat]

With some suspicious wording in this thread, I would like to make sure that no one here is talking about omitting the software renderer sometime in the future.

[Graf Zahl]

Huh???

 

The software renderer wasn't even a subject in this discussion. This can only happen in the very unlikely case that some platforms lock out their rendering hardware in such a way that an efficient data transfer of the software rendered image in real time is no longer possible.

[ReaperAA]

53 minutes ago, Graf Zahl said:

non-functional frame interpolation

 

Is this related to the issue of PrBoom+ feeling much less smooth when Vsync is turned on. If so, I would love to see this fixed as right now I have to turn off Vsync to get the smooth feel in PrBoom+

[LexiMax]

22 hours ago, Graf Zahl said:

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.

Are you familiar with bgfx?  I don't have any personal experience with it, but judging from the github page and how much I've heard about it in gamedev circles, it might be a viable alternative to trying to port GZ's renderer.

Edited January 18, 2020 by AlexMax

[Altazimuth]

11 minutes ago, Graf Zahl said:

This can only happen in the very unlikely case that some platforms lock out their rendering hardware in such a way that an efficient data transfer of the software rendered image in real time is no longer possible.

I seriously doubt this'll hapen, given SDL2 handles that sorta thing. I know that EE's default SDL renderer uses DirectX on Windows, and I'm certain uses appropriate stuff on Mac. Linux I dunno what it uses but it always worked fine, and even works for CSG on her Pi so I'm confident that won't be an issue.

 

As for Graf's prior comments about how much of a nightmare demo compat is for stuff like portals: I don't know quite how much EE does dupe code for stuff like 3D clipping but yeah, it's generally a real nightmare. Slopes aren't in EE for a reason (though printz has been looking to deal with that). Based on personal experience with EDF weapons, I had to copy a startling amount of code because you simply could not refactor it without breaking something. I'm not saying this stuff is not doable but it does make things drastically harder, especially in a port that maintains demo compatibility with itself (which EE doesn't worry about, even though it does play MBF demos and lower).

Edited January 18, 2020 by Altazimuth

[Graf Zahl]

31 minutes ago, AlexMax said:

Are you familiar with bgfx?  I don't have any personal experience with it, but judging from the github page and how much I've heard about it in gamedev circles, it might be a viable alternative to trying to port GZ's renderer.

 

This looks interesting. But you are looking at the wrong layer to plug it in - it couldn't replace the Doom engine renderer but merely the backend code. But the main issue with PrBoom is that there is no separation between both. It's an old engine that sits directly on the underlying API.

It might be an interesting exercise to plug this into GZDoom to test its viability.

 

30 minutes ago, Altazimuth said:

I seriously doubt this'll hapen, given SDL2 handles that sorta thing. I know that EE's default SDL renderer uses DirectX on Windows, and I'm certain uses appropriate stuff on Mac. Linux I dunno what it uses but it always worked fine, and even works for CSG on her Pi so I'm confident that won't be an issue.

 

Sure, but if the hypothetical event I laid out happened, all the SDLs in the world couldn't work around it. Ultimately the final bottleneck for a software renderer is the time in which the image can be transferred to the graphics hardware. IIRC the original iOS port of Doom had this problem so it was OpenGL only.

 

When I was porting one game to Windows Phone 7 years ago the texture upload performance was so shitty that it couldn't be done in the main thread - the phone always thought the app had become unresponsive and terminated it. You cannot run a software renderer on such a system.

 

Quote

 

Slopes aren't in EE for a reason (though printz has been looking to deal with that).

 

Slopes are mostly tedious work in most cases, though. For horizontal planes the plane equation functions would - if set up properly - always return the correct value, so there's no compatibility concern. Yes, a few places may require more extensive refactoring, but these are mostly in the code where the alternative code path already exists.

Edited January 18, 2020 by Graf Zahl

[seed]

49 minutes ago, ReaperAA said:

Is this related to the issue of PrBoom+ feeling much less smooth when Vsync is turned on. If so, I would love to see this fixed as right now I have to turn off Vsync to get the smooth feel in PrBoom+

 

Essentially yes, I think. I've recently noticed that the mouse feels stupid responsive when using capped framerate, even with VSync, whereas it changes with uncapped even when VSync is off. It might have something to do with it.

 

I'd effing love this to be fixed after the sound system swap for sure.

[Redneckerz]

EDIT: Geezus only now do i understand how people do these multiquotes. God im dumb.

 

1 hour ago, Graf Zahl said:

 

Yeah. Geforce 4. Which was barely able to render the game at 35 fps at 800x600.

But in the end, what is more important? Seeing to it that the overwhelming majority of today's users can use the thing or that we can brag to work on an engine that thoretically still compiles on hardware so old that no other software in existence works on it?

Most of the underlying works is in PrBoom anyway. But what would you propose to keep the GL renderer up in the air? I am sure a few demo recordists use the GL renderer, but i agree with you that software is the preferred way to go with this.

 

Which leaves you the GL renderer. What to do with it?

 

1 hour ago, Graf Zahl said:

Consider this: GZDoom dropped Windows XP support last year. Why? The user base was 0.13% of reporters in the last survey before, in absolute numbers that translated to 42 persons. This isn't enough to warrant more work. I'm not sure how PrBoom+ fares, but since it uses SDL2 it cannot run on XP anymore, don't even mention Windows 9x. The supposed user base simply does not exist anymore. I'll grant you GL 2.0, but not 1.1 - but ultimately the only way to get some meaningful info here would be to do the same as GZDoom did: Run a survey.

I can imagine that if the life existence of GLBoom is exhausted (Either by outdated API or the fact SDL2 has no legacy support) that GLBoom as such gets redelegated as a legacy port aswell. Because its OpenGL renderer is already in that realm, so you might aswell simply backport it to SDL1 again and call it GLBoom-Minus.

 

Halfly joking ofcourse, but if the useablity options for GLBoom have run out, than it should be discarded.

 

1 hour ago, Graf Zahl said:

There won't be a new name. I still hope that Proff is picking it up and makes it official PrBoom. If that falls through it may be thought about.

Then in return ill keep on calling this ZahlonBoom for the moment. ;)

 

1 hour ago, Graf Zahl said:

The fun thing is that nothing of PrBoom's design goals would prohibit a more modern GL renderer.

Like you said, some parts here are ancient. While PrBoom has great compatibility, it also has some serious issues in the technical area because it is so old, e.g. mostly non-functional frame interpolation, the aforementioned sound problems and the ancient renderer. Modernizing this, while keeping its game core intact, is the way to proceed here.

Agreed. Which is why i poised the question of what to do with the GL renderer. What is its usecase? Who uses it? And would it better off being a seperate democompatible port for legacy users?

 

At the same time, i'd have to ask where you would want to go with it in terms of GL compatibility. Raise the base level to GL 3.3 similar to GZDoom? Support advanced visuals?  I do not want to bet on the possibility that the PrBoom crowd likes those ideas as that's not their perjorative. They use it to record demo runs of their maps and the fact it is lauded for its vanilla compatibility.  You obviously do not need a GL renderer for any of those things, so where to go with it?

 

Perhaps a survey is indeed in order. But whether or not people will accept the telemetry request is a different discussion, i feel.

 

1 hour ago, Da Werecat said:

With some suspicious wording in this thread, I would like to make sure that no one here is talking about omitting the software renderer sometime in the future.

That seems highly unlikely. Part of this (meta) discussion was about the GL renderer. For legacy use cases its still pretty good sans the SDL2 backend.

 

Which leads me to question: Why is GLBoom with its legacy OpenGL support still a thing when its OS support through SDL2 is beyond where such OpenGL support makes sense?

 

24 minutes ago, AlexMax said:

Are you familiar with bgfx?  I don't have any personal experience with it, but judging from the github page and how much I've heard about it in gamedev circles, it might be a viable alternative to trying to port GZ's renderer.

Now that's an awesome link and it has a ton of example applications aswell. Good stuff, alex!

[LexiMax]

12 minutes ago, Graf Zahl said:

But the main issue with PrBoom is that there is no separation between both. It's an old engine that sits directly on the underlying API. 

 

Oh, yeah, that would still be an issue.  Glad you think it might be intriguing to experiment with in other contexts, though.

 

14 minutes ago, Graf Zahl said:

When I was porting one game to Windows Phone 7 years ago the texture upload performance was so shitty that it couldn't be done in the main thread - the phone always thought the app had become unresponsive and terminated it. You cannot run a software renderer on such a system. 

 

How shitty are we talking?  Was it a problem of resolution, or was it simply not a viable approach at any resolution?

[Da Werecat]

9 minutes ago, Redneckerz said:

What is its usecase? Who uses it?

I remember a couple of releases from Eternal that specifically targeted GLBoom+.

 

I also remember someone telling me a while ago that they can't record letsplays (are those still a thing?) in software mode. But this seems like a problem to address in the software exe itself, maybe.

[Graf Zahl]

 

1 minute ago, Redneckerz said:

Which leaves you the GL renderer. What to do with it?

 

For now, nothing. In the future - let's see. I always wanted to have a PrBoom with a better hardware renderer so maybe I take the time to put GZDoom's into it. But it's a big "maybe."

 

 

1 minute ago, Redneckerz said:

I can imagine that if the life existence of GLBoom is exhausted (Either by outdated API or the fact SDL2 has no legacy support) that GLBoom as such gets redelegated as a legacy port aswell. Because its OpenGL renderer is already in that realm, so you might aswell simply backport it to SDL1 again and call it GLBoom-Minus.

 

Ugh, no. What's the point? For that you can just use PrBoom+ 2.4. What's this obsession with keeping compatiblity with all that came before at all costs. It's an endless waste of work power and won't help the vast majority of users one bit. If you go that route you end up with the EDuke32 of Doom, i.e. an engine that never shed any of the old baggage and lets the baggage dictate what can and what cannot be done with it.

 

1 minute ago, Redneckerz said:

 

Halfly joking ofcourse, but if the useablity options for GLBoom have run out, than it should be discarded.

 

No. It may be old but it still works. Please don't forget: GZDoom's renderer grew out of this a long time ago so the foundation itself was quite solid, it just never received any genuine polish.

 

 

1 minute ago, Redneckerz said:

Then in return ill keep on calling this ZahlonBoom for the moment. ;)

 

Agreed. Which is why i poised the question of what to do with the GL renderer. What is its usecase? Who uses it? And would it better off being a seperate democompatible port for legacy users?

 

The use case? Well - Playing Frozen Time, of course! :P

 

1 minute ago, Redneckerz said:

 

At the same time, i'd have to ask where you would want to go with it in terms of GL compatibility. Raise the base level to GL 3.3 similar to GZDoom? Support advanced visuals?  I do not want to bet on the possibility that the PrBoom crowd likes those ideas as that's not their perjorative. They use it to record demo runs of their maps and the fact it is lauded for its vanilla compatibility.  You obviously do not need a GL renderer for any of those things, so where to go with it?

 

I think you are shortselling the users here. And you are definitely overthinking it. For now the GL renderer falls in the category of "If it ain't totally broke, don't ditch it!"

 

 

3 minutes ago, AlexMax said:

How shitty are we talking?  Was it a problem of resolution, or was it simply not a viable approach at any resolution?

 

I cannot give you any timing issues but that particular phone wasn't able to upload a fullscreen truecolor image (640x480 pixels) without the risk of the app getting shut down by the system. But then we are talking about Windows Phone here, which still counts as the worst platform I had the chance to work on. (I still wonder how Microsoft could think they were able to compete with this...)

[drfrag]

2 hours ago, Graf Zahl said:

but since it uses SDL2 it cannot run on XP anymore

SDL2 supports XP.

24 minutes ago, Redneckerz said:

so you might aswell simply backport it to SDL1 again and call it GLBoom-Minus.

That doesn't make much sense, with SDL1 you had broken multiplayer among other problems. I'm in the middle of the merge of RUDE with Choco3 and now i must mess with CMake. With SDL1 there were some serious limitations. Well i still have to compile it and see if it works, fingers crossed. :)

[seed]

54 minutes ago, Redneckerz said:

Because its OpenGL renderer is already in that realm, so you might aswell simply backport it to SDL1 again and call it GLBoom-Minus.

 

.

Edited January 18, 2020 by seed

[Redneckerz]

38 minutes ago, Da Werecat said:

I remember a couple of releases from Eternal that specifically targeted GLBoom+.

 

I also remember someone telling me a while ago that they can't record letsplays (are those still a thing?) in software mode. But this seems like a problem to address in the software exe itself, maybe.

Just looked it up on idGames, it does recommended a certain PrBoom version/GLBoom to go with it.

 

37 minutes ago, Graf Zahl said:

Ugh, no. What's the point? For that you can just use PrBoom+ 2.4. What's this obsession with keeping compatiblity with all that came before at all costs. It's an endless waste of work power and won't help the vast majority of users one bit. If you go that route you end up with the EDuke32 of Doom, i.e. an engine that never shed any of the old baggage and lets the baggage dictate what can and what cannot be done with it.

I am not assessing that you need to keep things compatible just for the sake of it. GLBoom works as is today, so if it works, it works. I was not trying to implore you to do anything with that part, and i apologise if it came off that way.

 

37 minutes ago, Graf Zahl said:

No. It may be old but it still works. Please don't forget: GZDoom's renderer grew out of this a long time ago so the foundation itself was quite solid, it just never received any genuine polish.

Ideally that port is made for my hardware because i literally match the renderer in terms of support. :P

 

37 minutes ago, Graf Zahl said:

The use case? Well - Playing Frozen Time, of course! :P

I love the idea of specific source ports that can only play one level or mapset - They are far and inbetween ;)

 

17 minutes ago, drfrag said:

SDL2 supports XP.

That doesn't make much sense, with SDL1 you had broken multiplayer among other problems. I'm in the middle of the merge of RUDE with Choco3 and now i must mess with CMake. With SDL1 there were some serious limitations. Well i still have to compile it and see if it works, fingers crossed. :)

This was said in a bit of jest ;)

[Spectre01]

2 hours ago, Graf Zahl said:

I always wanted to have a PrBoom with a better hardware renderer so maybe I take the time to put GZDoom's into it. But it's a big "maybe."

That would be pretty awesome. Currently, GZDoom in hardware can be set up to emulate the software look very closely, while maintaining higher visual fidelity with AA and AF as well as better performance. If GLBoom+ had banded lightmode and the palette tonemap, or even more atmospheric lighting in general, I would use it over PRBoom+ outside of maps relying on software tricks. 

[seed]

Yea, I would definitely love to see GZDoom s render used in PrBoom honestly, more power and more features at the same time? I am all-in for this.

[kaleb.]

as long as you can still use the software style sky on OpenGL like GLBoom normally does. i never liked skydomes..

[seed]

I have actually grown quite fond of that iconic GZDoom feature tbh.

[Da Werecat]

Sky cylinder would've been great. Except a proper one, not like vanilla did with only horizontal stretching.

 

Wouldn't work with freelook though.

[Graf Zahl]

28 minutes ago, seed said:

I have actually grown quite fond of that iconic GZDoom feature tbh.

 

That "iconic" feature was borrowed from ZDoomGL, which in turn lifted it from Doomsday, btw.

32 minutes ago, Da Werecat said:

Sky cylinder would've been great. Except a proper one, not like vanilla did with only horizontal stretching. 

 

Wouldn't work with freelook though.

 

The skydome effect is essentially a cylinder, just that it fades out to the top to provide a smooth transition.

 

[seed]

Just now, Graf Zahl said:

That "iconic" feature was borrowed from ZDoomGL, which in turn lifted it from Doomsday, btw.

 

Ah, so it seems our man seed was pranked again :v .

[Da Werecat]

29 minutes ago, Graf Zahl said:

The skydome effect is essentially a cylinder, just that it fades out to the top to provide a smooth transition.

It's enough of a dome to distort vertical lines ever so slightly.

[ReFracture]

I tried searching the thread to see if any further discussion on Linux was found with regards to binaries and didn't see anything, apologies if it's already covered.

 

For whatever it's worth on the Linux front I was able to easily build it with cmake on Slackware64. I had to install portmidi to get the one (non-fatal) error cmake was giving me to be sorted.

 

The syntax for basic building with cmake is pretty simple.

 

git clone https://github.com/coelckers/prboom-plus/tree/master/prboom2
cd prboom/prboom2/
mkdir build
cd build
cmake ..
make

 

I have no idea if the produced binaries are useful for throwing into a package for use on other distros or not but in anycase here they are if somebody wants them.

prboom2_x86_64.zip

Edited January 19, 2020 by ReFracture

[fabian]

I'll switch the Debian package to use this code base as soon as it sees a release. 

[seed]

Speaking of building, since there's a CMake build system in place now, can we expect seeing daily builds like others ports have for UBoom too?

[fabian]

23 hours ago, seed said:

can we expect seeing daily builds like others ports have for UBoom too?

 

What's Uboom?

[Redneckerz]

22 minutes ago, fabian said:

 

What's Uboom?

The thread you are in. Running alongside the main discourse there is also a seperate metadiscussion on how to name the thing (And it also had a seperate thread last year).

 

UBoom has some wide recognition from Seed, but Linguica's ProBoom also has some admirers. However, Graf wants no name change because he is hoping Proff picks this up. If not, then a name change can be considered.

 

(Seed has kept referring to this as UBoom as a way to plant an idea in our heads similar to the movie Inception. For my own stubbornness ill keep referring it as ZahlonBoom because i like the nonsensical cleverness of the name.) ;)