PrBoom+ 2.6.66 (Jun 20, 2023)

[Da Werecat]

Doesn't sound too different from the current approach, just clunkier. I was thinking more in line with how ZDoom handles compatibility options. Specific mechanics with UMAPINFO would be a matter of toggling a bunch of options (or using a preset) rather than switching between emulated engines. All of this would be available from the current -1 onwards.

 

This could offer additional flexibility, at the expense of being bothersome to implement - I imagine there's a lot of places in the code with branching related to complevels, although not every instance really deserves being converted into a toggleable option.

 

But I'm actually really pleased that this is happening. I thought all I'd be able to see is a really nice bike shed.

[Archi]

I'd like to suggest adding compatibility info lump, which would define everything if the player is not using specific complevel. If player specifies complevel it could be possible to just ignore both compatibility info lump and umapinfo. That would also give a lot more freedom, specifically, it would make it possible to disable some gameplay changes boom and mbf added to original game, pretty questionable ones.

 

Complevels being emulation of outdated engines means these engines could not load and use umapinfo anyway, so there's no need to load it anyway.

[Demion]

Hi there! I've found a kind of bug when playing Doom.wad or any Ultimate Doom pwad. When i finish the first level of any episode, E1M2 starts, not E2M2, E3M2 or E4E2. It always happens. I also tried with a "clean" install of the fork. With 2.5.1.4 and 2.5.1.5 it doesn't happen. I hope you can fix it, as I really like this version.

[seed]

1 minute ago, Demion said:

Hi there! I've found a kind of bug when playing Doom.wad or any Ultimate Doom pwad. When i finish the first level of any episode, E1M2 starts, not E2M2, E3M2 or E4E2. It always happens. I also tried with a "clean" install of the fork. With 2.5.1.4 and 2.5.1.5 it doesn't happen. I hope you can fix it, as I really like this version.

 

It was already fixed, it's going to be included in a future release.

[Demion]

Just now, seed said:

 

It was already fixed, it's going to be included in a future release.

Oh, great! Thanks!

[RonnieJamesDiner]

I'm just curious (and sorry if I missed this somewhere), but are there any equivalents to the Reset Health and Reset Inventory properties for UMAPINFO?

[Shadow Hog]

On 12/6/2019 at 3:19 PM, RonnieJamesDiner said:

I'm just curious (and sorry if I missed this somewhere), but are there any equivalents to the Reset Health and Reset Inventory properties for UMAPINFO?

Late answer, but I don't believe there's anything at present. Given the target for this is largely Boom-compatible, you could probably force it with a death exit in the prior map, I guess?

[RonnieJamesDiner]

1 hour ago, Shadow Hog said:

Late answer, but I don't believe there's anything at present. Given the target for this is largely Boom-compatible, you could probably force it with a death exit in the prior map, I guess?

 

Thanks for the response. I had my suspicions, but I just wanted to be sure. I was tinkering with a Boom-compat mapset where I wanted each map to be pistol start, and the idea of ending literally every level with a death exit started to feel ridiculous. I suppose a simple explanation in the .txt file that the maps are designed to be pistol start will suffice.

 

I wonder if these Reset properties may be considered for UMAPINFO? They seem like fairly modest features that would really just serve a quality-of-life purpose, in my mind, saving authors from having to use death exits for Boom compatibility. Though, I understand this is a slippery slope when you start adding things for "this" or "that" reason.

[Graf Zahl]

A lot could be considered if someone with more spare time for this project could be found. I am already spread too thin with my job, GZDoom and other non-Doom related projects - there's simply not enough time to maintain this as well.

[Spectre01]

45 minutes ago, RonnieJamesDiner said:

I was tinkering with a Boom-compat mapset where I wanted each map to be pistol start, and the idea of ending literally every level with a death exit started to feel ridiculous. I suppose a simple explanation in the .txt file that the maps are designed to be pistol start will suffice.

Plutonium Winds did exactly that by ending each map with a death exit, so that's the option if you want to be really strict about enforcing pistol starts. Although I think "designed/recommended to be played from a pistol start" in the text file is sufficient. The more enthusiastic Doomer is likely to pistol start a modern wad anyway or check the text file, and you don't run the risk of alienating players who just prefer continuous.

[Da Werecat]

I think such options are needed, if you're already doing a demo-breaking feature like MAPINFO.

[RonnieJamesDiner]

13 hours ago, Graf Zahl said:

A lot could be considered if someone with more spare time for this project could be found. I am already spread too thin with my job, GZDoom and other non-Doom related projects - there's simply not enough time to maintain this as well.

 

That's more than understandable. I was just throwing it out there, that's all.

 

13 hours ago, Spectre01 said:

Although I think "designed/recommended to be played from a pistol start" in the text file is sufficient. The more enthusiastic Doomer is likely to pistol start a modern wad anyway or check the text file, and you don't run the risk of alienating players who just prefer continuous.

 

Yeah, this is a fair point. I think it's probably the way to go.

[seed]

I've been thinking about something (what I'm doing instead of sleeping I guess 🤣).

 

In the original (as in, 2.5.1.5) glboom_plus.exe translucency doesn't affect projectiles, they're still rendered as in vanilla, regarless of whether you're using GL rendering or not. However, translucency works fine for projectiles in the prboom executable.

 

Do you know if this was a conscious decision on Andrey's part, or a bug? I was thinking that maybe you could fix this in your fork if it was a bug that never got fixed for some reason.

[Spectre01]

@seed There is a workaround currently in the form of a dehacked file that I've been autoloading for years: trans_on.zip

This enables translucent projectiles in any complevel of PR/GLBoom+, both software and hardware. The only side effect is that translucent projectiles in OpenGL are invisible behind translucent walls. Although very few maps actually have this as a noticeable problem. But yes, a legitimate option in the port would be nice.

[seed]

5 hours ago, Spectre01 said:

@seed The only side effect is that translucent projectiles in OpenGL are invisible behind translucent walls.

 

Sounds like a bug that needs fixing.

[andrewj]

Translucent sprites in OpenGL was probably on the TODO, but just never got done.  I doubt it was a case of just needing a few extra lines of code, translucent stuff can be very tricky to get right and it can require a whole lot of extra code.

Edited December 27, 2019 by andrewj
clarified post

[Graf Zahl]

OpenGL, not software rendering.

 

The reason why these can cause problems is that PrBoom uses a rather naive depth sorting algorithm. It was one of the first things I rewrote some 18 years ago when I started working with the renderer to what eventually became GZDoom. (The map that made me do it was P:AR's E1M3, btw.)

 

 

[seed]

32 minutes ago, Graf Zahl said:

OpenGL, not software rendering.

 

The reason why these can cause problems is that PrBoom uses a rather naive depth sorting algorithm. It was one of the first things I rewrote some 18 years ago when I started working with the renderer to what eventually became GZDoom. (The map that made me do it was P:AR's E1M3, btw.)

 

Can you fix this in your fork too boss?

[Graf Zahl]

It's not that easy. GZDoom's code depends heavily on its render list management and cannot be trivially ported. There's also that little issue that I haven't done any serious development in plain C for over 20 years and I simply do not feel comfortable anymore working with that language.

 

 

[andrewj]

4 hours ago, Graf Zahl said:

OpenGL, not software rendering.

Yes of course, OpenGL was the topic of conversation.  Sheesh.

[Graf Zahl]

I just tried out the new CMake project that got added. With 32 bit Windows everything works fine - but the 64 bit build refuses to start, claiming that the prpgram is invalid. Has anyone managed to get PrBoom+ compiled for Windows 64 bit in the past?

Since the error I get is very uninformative I cannot even say if there's something wrong with the compile setup or one of the DLLs.

 

The good thing is that with a proper project I may feel motivated to invest a bit of work again - this removes a major part of the unease with the existing projects.

There's just one thing - the C/C++ question. No matter what may be improved here - all relevant code that could be taken is written in C++, and backporting this is clearly not an option because it'd be far too time consuming and error prone. So I have to ask: Would it be a problem for anyone depending on PrBoom if it migrated to C++ - with that I do not mean full-blown OOP, but merely renaming the source files and addressing the syntax differences between both languages? If the code base was C++ it'd be magnitudes easier to borrow code from GZDoom, Eternity or other ports because not everything would have to be downconverted to C again.

 

Good examples here would be an UDMF parser or the needed features to make Hexen format maps work as intended - something for which Fabian has already posted a submission allowing to load the basic map structure.

 

 

 

[seed]

If that means UBoom+ getting resurrected and actually moving into the modern age, I'd say it definitely sounds like it's worth the investment.

 

..except that I'm not a programmer so I probably can't really have an opinion here :( .

Edited December 30, 2019 by seed

[Graf Zahl]

What I was talking about is projects depending on it. Some are targeted at systems with limited compiler support and it's often a guessing game if they support a somewhat modern language standard. On the other hand it's no fun not being to use already existing code that solves a problem adequately if there's this language barrier.

 

[Danfun64]

2 hours ago, Graf Zahl said:

I just tried out the new CMake project that got added. With 32 bit Windows everything works fine - but the 64 bit build refuses to start, claiming that the prpgram is invalid. Has anyone managed to get PrBoom+ compiled for Windows 64 bit in the past?

I've compiled it for 64-bit Windows in MSYS2 quite a few times. Having updated to the latest trunk build, the only big difference was that I needed another dll placed in my prboom-plus directory. Otherwise it's running just as well as it always did. Of course, I never figured out how to get MSYS2 to produce static binaries, so having to symlink (I use Link Shell Extension) 39 dlls is F U N.

On a side note, why isn't the prboom2 folder the top directory? It would be a lot more convenient to clone.

[Graf Zahl]

Don't ask me - it has always been this way. I didn't want to change it because renames only make things harder for a fork of another project.

 

[Danfun64]

What I'm saying is, with the original project I could just clone the prboom2 folder in svn by itself, and can even clone it as a different directory name. With your git fork, I have to clone the prboom2 folder as is, alone with the stuff surrounding it.

I can understand why it has to be done this way (makes merging from upstream easier probably). It just annoys me a little, that's all.

Edited December 30, 2019 by Danfun64

[Graf Zahl]

Well, sorry, but Git clones entire repos. I would have had to rename every single file in the entire repo to change it and that's simply not the brightest idea.

 

[Danfun64]

Rename every single file?

[Graf Zahl]

For git, yes. If I move the entire directory tree in the repo, every single file will get a different name. And that causes problems with some tools.

 

[Danfun64]

Ah, I see. Thanks for explaining.