PrBoom+ 2.6.66 (Jun 20, 2023)

[omx32x]

2 hours ago, P41R47 said:

easily, it let you customize things that weren't customizable on vanilla limit removing and boom.

For example, if you played vanilla doom 2, you know you are restricted to only 3 different skies. Well with mapinfo you can have a different sky for every map you have.

Another good thing is it let you freely use the boss actions as you already said, but thats apply to the actions of the bosses of UDoom also, so you can have a fight with a cyberdemon and then doors open somewhere.

It also let you have secret maps wherever you want, contrary to vanilla to boom that you were restricted to have secret exits only on e1m3, e2m5, e3m6, e4m2 and map15 and map31.

Also, mapinfo is easily codeable and its not subject to limitation like vanilla dehacked that had a set number of character usable to write the intermission screens.

 

Simply put, it adds customization outside of the box.

For example, with MBF transfer lines you could have maps with different skies, but you needed to apply the proper linedef while making the map, with mapinfo is as easy as to write it.

 

It offer a good set of quality of life improvement to customization easily understandable to newcomer and veterans alike.

 

And for certain, escaping at last from the confines of the vanilla limitation of having just 2 secret maps for doom 2/final doom, make the mapinfo very useful.

i remenber hearing somewhere that the unity ports have its own version of it is that true? if so what are the differeces?

[BunnyWithBeans]

1 hour ago, JadingTsunami said:

Typing "idclev" will show the current and next map.

 

Doesn't seem to work for me. When I type idclev (with or without the automap open) it shows me a message saying "all marks cleared" and nothing else after I hit C.

 

What I meant was showing the map number permanently without cheats. For example, this is what I see when I open the automap in GZDOOM and look at the level title:

And here's what I see when I open the automap in PrBoom+ and look at the level title:

 

 

 

 

[JadingTsunami]

3 minutes ago, BunnyWithBeans said:

Doesn't seem to work for me. When I type idclev (with or without the automap open) it shows me a message saying "all marks cleared" and nothing else after I hit C.

 

You will need a recent development build. After that you will be able to type "idclev" to show the map number.

 

The decision was made to show map numbers this way rather than modify the automap string. You can see the discussion and background here.

[BunnyWithBeans]

1 hour ago, JadingTsunami said:

 

You will need a recent development build. After that you will be able to type "idclev" to show the map number.

 

The decision was made to show map numbers this way rather than modify the automap string. You can see the discussion and background here.

 

Ah, I see. Thank you!

[Gez]

42 minutes ago, omalefico32x said:

i remenber hearing somewhere that the unity ports have its own version of it is that true? if so what are the differeces?

Yes, and the differences are just some technical details. The features, by and large, are identical.

[Valboom]

18 hours ago, JadingTsunami said:

 

I'm not able to reproduce this behavior in the latest build across various rendering options.

 

If you are able to reliably reproduce the issue, can you post an issue on GitHub along with your config and a screenshot or video capture of the issue happening? This will help debug.

Here is the screenshot (1920x1080 software 8-bit,exclusive fullscreen).I will post on GitHub

Edited May 7, 2021 by Valboom

[Da Werecat]

This is a pronounced issue when sprite filtering is enabled (whichever setting affects first-person weapon sprites). First time I'm seeing it on an unfiltered sprite though.

[maxmanium]

I can confirm that I've seen these issues too with unfiltered sprites.

[Shepardus]

I've seen that line appearing on the SSG too, with unfiltered sprites. It appears for me sometimes during the reload firing animation, but I don't know how to reliably reproduce it. I think I started seeing it after the fix for garbage lines at the top of weapon sprites went in, but any connection to that is purely speculative at the moment.

 

In case it's relevant, I use the "8bit" renderer with 960x600 resolution on a 1920x1200 monitor.

Edited May 8, 2021 by Shepardus

[Spectre01]

I can also confirm that the red line appears while reloading the SSG in 8bit rendering.

[EnrichedUranium]

I might be missing something obvious, but is there a way to get the SC-55 pack for TNT & Plutonia's working? I guess it's a bit less important (at least for me) for Plutonia since the community midi pack and it just being tracks from other games. Would it just be separate config files with the doom2 tracks being replaced with the final doom counterparts?

[nobleflame]

Stupid question from a n00b, but with WADs like Eviternity my skyboxes aren’t showing properly. On map1, for instance, the skybox cuts to black just above the moon and then starts again much higher up. 
 

Any idea what’s going on or if one of my settings is incorrect? Thank you :)

Edited May 9, 2021 by nobleflame

[omx32x]

2 minutes ago, nobleflame said:

Stupid question from a n00b, but with WADs like Eviternity my skyboxes aren’t showing properly. On map1, for instance, the skybox cuts to black just above the moon and then starts again much higher up. 
 

Any idea what’s going on or if one of my settings is incorrect? Thank you :)

if you are playing on prboom you have to enable the dome skybox to show for some fucked up reason it is set to off when playing without mouse look i can give you a tutorial if you want

[nobleflame]

12 minutes ago, omalefico32x said:

if you are playing on prboom you have to enable the dome skybox to show for some fucked up reason it is set to off when playing without mouse look i can give you a tutorial if you want

That’d be amazing. I’m new to this version of PrBoom (old DOOM head from the 90s), so any help would be much appreciated! Thank you :)

Edited May 9, 2021 by nobleflame

[omx32x]

11 minutes ago, nobleflame said:

That’d be amazing. I’m new to this version of PrBoom (old DOOM head from the 90s), so any help would be much appreciated! Thank you :)

go inside the glboom + config file (glboom-plus.cfg) and search for gl_skymode and change it to 3 it will fix it (well at least it worked on my end)

[JadingTsunami]

2 hours ago, nobleflame said:

Stupid question from a n00b, but with WADs like Eviternity my skyboxes aren’t showing properly. On map1, for instance, the skybox cuts to black just above the moon and then starts again much higher up. 
 

Any idea what’s going on or if one of my settings is incorrect? Thank you :)

 

If you're using the OpenGL renderer, it should be fixed in the latest development builds.

 

Note that if you look "up", you will see the sky cut off above the moon (that's just how the texture looks). But if you have freelook disabled it should be corrected.

[maxmanium]

@Never_Again, do you have any builds for May?

[nobleflame]

7 hours ago, omalefico32x said:

go inside the glboom + config file (glboom-plus.cfg) and search for gl_skymode and change it to 3 it will fix it (well at least it worked on my end)

Thanks again. I’ll try this later on today after work. One other thing - in the latest build I downloaded the only .exe was PrBoom. Is the gl bit the setting that switches rendering mode from 32bit to gl? 
 

I remember in old versions of PrBoom that a glboom.exe was also included. 

[fabian]

On 5/8/2021 at 1:18 AM, Shepardus said:

In case it's relevant, I use the "8bit" renderer with 960x600 resolution on a 1920x1200 monitor.

 

Ah, that fricking factor 3! You know, in order to scale the weapon sprite from the original 200 px vertical resolution up to 600 px you need to draw each pixel 3 times - this is trivial. However, the Doom engine decides to iterate through screen coordinates and increases the patch coordinate by the *inverse* scaling factor - in this case FRACUNIT/3. Unfortunately, it is impossible to properly do this with fixed point math, i.e. 3*(FRACUNIT/3) != FRACUNIT! That's why it wraps around to the top of the sprite for one pixel after it has reached the sprite's bottom.

Edited May 10, 2021 by fabian

[omx32x]

7 hours ago, nobleflame said:

Thanks again. I’ll try this later on today after work. One other thing - in the latest build I downloaded the only .exe was PrBoom. Is the gl bit the setting that switches rendering mode from 32bit to gl? 
 

I remember in old versions of PrBoom that a glboom.exe was also included. 

oh weird my version is a bit outdated now so i cant tell for sure but i belive when using the prboom launcher the opengl renderer option just makes the renderer go back to the 8 bit render but im not sure about that on newer versions

[fabian]

From v2.6um on, there is only one single binary which features both the software and the OpenGL renderer if the build-time system supports it. The run-time system is exected to support OpenGL then, though.

[maxmanium]

6 hours ago, fabian said:

3*(FRACUNIT/3) != FRACUNIT

 

Even when it's written like that?

 

Edit: I'd also like to ask: is there any reason (other than how extensive and therefore time consuming I'm assuming it would be to implement) that source ports like these are still using fixed-point math? It's not like it's catering to a 486 without an FPU or anything.

Edited May 10, 2021 by maxmanium

[omx32x]

5 minutes ago, fabian said:

From v2.6um on, there is only one single binary which features both the software and the OpenGL renderer if the build-time system supports it. The run-time system is exected to support OpenGL then, though.

oh so that's it my version is 2.5... i really need to update it but i am too lazy to do it

[Shadow Hog]

3 hours ago, maxmanium said:

I'd also like to ask: is there any reason (other than how extensive and therefore time consuming I'm assuming it would be to implement) that source ports like these are still using fixed-point math? It's not like it's catering to a 486 without an FPU or anything.

Just a guess, but demo compatibility is probably a big factor for it. Fixed points and floating points have very different quirks, so just blindly tossing floats in where fixed_ts are used to be will almost certainly alter some functionality that directly affects demo playback.

 

Maybe a moot point for the renderer at this point, since that shouldn't be tied to gamelogic, but IDK.

Edited May 10, 2021 by Shadow Hog

[maxmanium]

6 minutes ago, Shadow Hog said:

Just a guess, but demo compatibility is probably a big factor for it. Fixed points and floating points have very different quirks, so just blindly tossing floats in where fixed_ts are used to be will almost certainly alter some functionality that directly affects demo playback.

 

Maybe a moot point for the renderer at this point, since that shouldn't be tied to gamelogic, but IDK.

 

That makes sense, I was mostly thinking about the renderer so I didn't think about game logic. But I assume it must be a pain to do for a game that's entirely written in fixed-point since most source ports don't seem to rewrite the renderer (Only Eternity's Cardboard and whatever ZDoom does, I guess).

[Gez]

3 hours ago, maxmanium said:

Even when it's written like that?

Yes.

 

FRACUNIT == 65536. Okay?

 

So when you look at "3*(FRACUNIT/3)", notice the parentheses. The priority is on the division, so that's the first thing to evaluate. FRACUNIT/3 = 21845. You lose the "decimal point" of 0.333333... since it's actually an integer.

Second step, you multiply 3 by 21845. The result is 65535. Just one short of the original value. Which makes sense since you rounded down 1/3.

 

 

If, on the other hand, you had "(3*FRACUNIT)/3", then you'd multiply first to get 196608, then divide it back to get 65536, no problem. Conclusion: when possible, try to multiply before dividing.

[maxmanium]

1 minute ago, Gez said:

Yes.

 

FRACUNIT == 65536. Okay?

 

So when you look at "3*(FRACUNIT/3)", notice the parentheses. The priority is on the division, so that's the first thing to evaluate. FRACUNIT/3 = 21845. You lose the "decimal point" of 0.333333... since it's actually an integer.

Second step, you multiply 3 by 21845. The result is 65535. Just one short of the original value. Which makes sense since you rounded down 1/3.

 

 

If, on the other hand, you had "(3*FRACUNIT)/3", then you'd multiply first to get 196608, then divide it back to get 65536, no problem. Conclusion: when possible, try to multiply before dividing.

 

This is kind of what I figured. I know computers don't understand algebra in the sense that humans do, but I wasn't certain. I wonder what the significance of that number is to be FRACUNIT...

[Gez]

10 minutes ago, maxmanium said:

I wonder what the significance of that number is to be FRACUNIT...

Oh, it's pretty simple: it's 2¹⁶. This is how fixed point arithmetic work.

 

The root of the problem is real numbers. You've got a limited number of bits and you have to represent an infinite continuum of values? That's just not possible. Just like if you only have two decimal digits, you can only write a hundred different values (from 00 to 99), with computers you can only represent a finite amount of values. For integers, with 8-bit it's 256 values (from 0 to 255), with 16-bit is 65 536 (0 to 65535), with 32-bit it's 4 294 967 296 values, etc.

 

Now what if you want to be able to represent values smaller than 1? Well you need a way to map these bits to an approximation of real numbers. Either you use floating point values -- but in the nineties, computers were really slow at doing floating point math, so that was a no-go for the Doom engine -- or you just cheat by multiplying all values by a large number and then pretend your integer unit is that large number. Then you can just use integer math (which are as fast as the computers can get). The best choice for your large value? Well, if you use 32-bit numbers, then you could split it in half, to have 16-bit for the integral part and 16-bit for the fractional part. Then this way, to represent the value 1.0, you'd multiply it by 65536 so that you have "1" in the upper 16-bits.

 

Speed-wise, it was the best choice. If you need the integral part in a hurry, you can just read the upper two bytes as a 16-bit number without needing to do any calculation.

[Spectre01]

Would it be possible to implement something similar to GZDoom's palette tonemap for OpenGL? That way there is an option to have GL look close enough to software while retaining its performance and other benefits.

[nobleflame]

23 hours ago, omalefico32x said:

go inside the glboom + config file (glboom-plus.cfg) and search for gl_skymode and change it to 3 it will fix it (well at least it worked on my end)

Another quick question from me: do you know how to increase the res of skyboxes? I’m at 1080p and the skyboxes look like their at 800x600.