PrBoom-Plus, ver. 2.5.1.4

[Memfis]

Well, I sure would be glad to see a longtics hack for -complevel 9!

[dew]

Not sure if I've brought this issue up already, but I got reminded of it in a loosely related conversation...

The increased FOV in widescreen resolutions leaves dead zones at the sides of the screen where the BFG cone doesn't extend to. Classic HUD naturally marks the ends of the cone, but nowadays with Boom HUDs and no HUDs and extended HUDs, I thought perhaps some sort of toggleable indents at the top and the bottom of the screen could help players keep the targets in the killzone.

I brought this issue up with Zdaemon and Odamex devs some time ago, but I'm not sure it was a top priority for them... :(

[entryway]

can't understand. screenshots?

[ReFracture]

He's talking about the kill radius when a BFG Ball explodes in the player's field of vision. It of course also will damage enemies the player can see at the same time. The classic status bar's ends serve as a marker for us to ensure that an enemy is inside the 'kill zone' when playing in widescreen. I think he just wants a line or something to exist where the edges of the classic status bar would be when using say.. the boom hud.

[entryway]

Thanks for explanation.

[dew]

Oh crap, I forgot I posted here, sorry. Mike explained it correctly, but it doesn't have to be a line drawn over the entire screen, it can be just a small marker at the bottom/top of the screen.

[Linguica]

PrBoom-Plus's software renderer blows up at extreme resolutions.

It works at 4228x3171, but fails at 4232x3174:



You'll notice even in the one that "works", the sprites are all missing. That happens at an even lower resolution:

4020x3015 vs. 4024x3018:



You might say this is ridiculous, no one is ever playing Doom at those resolutions, who cares, and... sure, I guess, but at the same time, Dell IS coming out with a 5K (!) monitor: http://arstechnica.com/gadgets/2014/09/dell-kicks-your-puny-4k-monitor-to-the-curb-debuts-27-5k-panel/, and the game won't work correctly in what is soon to be an actual resolution a person could potentially be playing at.

[RjY]

Linguica posted:
You might say this is ridiculous, no one is ever playing Doom at those resolutions, who cares, and... sure, I guess, but at the same time, Dell IS coming out with a 5K (!) monitor, [...] and the game won't work correctly in what is soon to be an actual resolution a person could potentially be playing at.

It does seem faintly ridiculous. But at the same time it is a stupid and arbitrary limit which exists for no good reason.

This bug has all the hallmarks of a sign overflow in some calculation somewhere and it turns out to be projectiony in R_SetViewSize, which overflows when SCREENWIDTH increases from 4228 to 4232.

[ We have (cheight * centerx * 320) which at 4:3 resolution with no view border is (SCREENHEIGHT * SCREENWIDTH/2 * 320). For overflow, H*W/2*320 > INT_MAX==2^31. That is, H*W > 2^32/320. At 4:3 aspect, H=3W/4 so 3W^2/4 > 2^32/320, or W^2 > 2^34/960. Thus W > 2^17/sqrt(960) ~ 4230.33. So that checks out. ]

Anyway projectiony being negative causes R_ScaleFromGlobalAngle to return nonsense (projectiony < 0 means num < 0, so it returns 256 as a fixed_t, i.e. 1/256 in fixed point) and all the walls disappear.

If I calculate projectiony using floating point, to avoid the overflow, a brief test at 4800x3600 displayed correctly.

diff --git a/src/r_main.c b/src/r_main.c
index c08f92d..42ced6d 100644
--- a/src/r_main.c
+++ b/src/r_main.c
@@ -833,7 +833,11 @@ void R_ExecuteSetViewSize (void)
   projection = wide_centerx<<FRACBITS;
 
 // proff 11/06/98: Added for high-res
-  projectiony = ((cheight * centerx * 320) / 200) / SCREENWIDTH * FRACUNIT;
+  // calculate projectiony as float to avoid overflow when SCREENWIDTH>4228
+  projectiony = (fixed_t)
+    (((double) cheight * (double) centerx * 320.0)
+     / 200.0 / (double) SCREENWIDTH * (double) FRACUNIT);
+
   // e6y: this is a precalculated value for more precise flats drawing (see R_MapPlane)
   viewfocratio = (1.6f * centerx / wide_centerx) / ((float)SCREENWIDTH / (float)cheight);
 

Thanks for writing those posts about R_ScaleFromGlobalAngle by the way, this probably would have taken a lot longer to figure out if I hadn't read them.

[fabian]

RjY said:

If I calculate projectiony using floating point, to avoid the overflow, a brief test at 4800x3600 displayed correctly.

Since this is still integer math, wouldn't casting the values to int64_t instead of float/double have the same effect?

[kb1]

You know, just a thought: These higher and higher resolution monitors are going to slow down Doom software rendering considerably, without much real benefit.

Sure, you be able to see all the pixels of that imp that's 2 miles away, but, is it useful? At 1920x1080x4 bpp, that's almost 8.3 Mb. But, at 4800x3600x4 bpp, that's 69 Mb! 8x throughput, for that clear 2 mile-away imp. Doom maps can only be so long in length...

[Linguica]

You could say that about any FPS, really.

And I agree, I think effort is better spent making the GL renderer perfectly imitate the software "look" and then rely on that much better code for high resolutions. But there's still something cool to making more or less the "original" engine do ludicrous things.

[Grazza]

The distance across the doomspace (from corner to corner) is the equivalent of about 2 miles.

[entryway]

Few days ago I fixed crash at 1x1 resolution. Now you say it fails at 4232x3174.

I've replaced calculation of projectiony with int64 math

[RjY]

fabian said:

Since this is still integer math, wouldn't casting the values to int64_t instead of float/double have the same effect?

Well yes, but since R_SetViewSize was already using floating point for other calculations, I figured, what the hell...

kb1 said:

You know, just a thought: These higher and higher resolution monitors are going to slow down Doom software rendering considerably, without much real benefit.

Indeed, which is why I find it better to let software mode render the game at 640x480 and let my monitor take care of scaling/pillarboxing it to 1920x1200.

entryway said:

Few days ago I fixed crash at 1x1 resolution. Now you say it fails at 4232x3174.

I've replaced calculation of projectiony with int64 math

Cool, now we can go up to 277238946x207929210 before it will break again ;)

[fabian]

entryway said:

Few days ago I fixed crash at 1x1 resolution. Now you say it fails at 4232x3174.

Well, at least anything in between worked. ;)

[entryway]

I tried to apply 'wiggle fix' from this thread per wall, instead of per level, as kb1 suggested.

win32 binary:
http://prboom-plus.sourceforge.net/history.html

Any issues?

I tested it on this level:
https://dl.dropboxusercontent.com/u/235592644/files/wiggle_test.wad.zip

[skillsaw]

There seems to be some kind of issue with 3 key doors in complevel 11. Try loading up this test wad:

http://www.mediafire.com/download/tuyqhbk0cp9164n

If you grab all three keycards, the door can be opened. If you grab all three skull keys, the door will not open upon use. From what I could tell, you can have either the card or the skull for red and blue, but you need the yellow card.

This only happens in complevel 11 as far as I can tell. I tested with both 2.5.1.3 and the 9/20/2014 2.5.1.4 test build.

[plums]

Original MBF had this bug, so this is probably intentional behaviour in PrBoom+.

http://doomwiki.org/wiki/MBF#Bugs

[Rez]

plums said:

Original MBF had this bug, so this is probably intentional behaviour in PrBoom+.

http://doomwiki.org/wiki/MBF#Bugs

BOOM had it too (as I discovered in the first demo I tried to do with BOOM), tho details may have changed since then. I vaguely recall that whether it manifests depends also on the order the keys are picked up. When I run into it now, I just IDK and pretend the key worked. ;)

[fabian]

entryway said:

I tried to apply 'wiggle fix' from this thread per wall, instead of per level, as kb1 suggested.

Any issues?

Sorry, I cannot checkout SVN right now (I am on the train).

Have you experienced any performance regressions? I can imagine that recalculating *per wall each tic* will have quite some impact on performance.

Maybe you should make it switchable with a config flag. Or you could at least bind it to the "Rendering Quality/Speed" flag?

[entryway]

fabian said:

Have you experienced any performance regressions? I can imagine that recalculating *per wall each tic* will have quite some impact on performance.

Currently I use cascade with IF statements in R_StoreWallRange

  height = (worldtop - worldbottom) >> 16;
  if (height < 256) {
    max_rwscale = 2048; HEIGHTBITS = 12;
  } else if (height < 512) {
    max_rwscale = 2048; HEIGHTBITS = 11;
  } else if (height < 1024) {

You can use bsr instruction (_BitScanReverse/__builtin_clz) to avoid branches:

  static int values[][] = {
    {2048, 12},
    {2048, 11},
    // ...
  };

  worldtop = frontsector->ceilingheight - viewz;
  worldbottom = frontsector->floorheight - viewz;

  _BitScanReverse(&index, (worldtop - worldbottom) >> 16);
  max_rwscale = values[index][0] << FRACBITS;
  HEIGHTBITS = values[index][1];
  HEIGHTUNIT = 1 << HEIGHTBITS;
  invhgtbits = 16 - HEIGHTBITS;

Or just use precalculated lookup 256 bytes table:

  worldtop = frontsector->ceilingheight - viewz;
  worldbottom = frontsector->floorheight - viewz;

  index = MSB[(worldtop - worldbottom) >> 24];
  max_rwscale = values[index][0] << FRACBITS;
  HEIGHTBITS = values[index][1];
  HEIGHTUNIT = 1 << HEIGHTBITS;
  invhgtbits = 16 - HEIGHTBITS;

Or probably some hacks from:
https://chessprogramming.wikispaces.com/BitScan

This, for example.

[kb1]

Andrey and I are working on a new version that does per-wall calcs. The extra time spent calculating each wall is tiny - in most all scenes, there's only a handful of walls to look at anyway. What's cool is that, this new fix handles moving sectors, and maintains texture drawing accuracy, on all but the most extreme tall walls.

And, it can handle full 32767-unit sector heights.

Andrey is coming up with some rather clever ways to speed it up even more, but it's plenty fast. We should have it perfected by tomorrow.

[fabian]

kb1 said:

We should have it perfected by tomorrow.

There has been some refactoring in SVN today. Will you tell us when the code is ready for general consumption?

[kb1]

fabian said:

There has been some refactoring in SVN today. Will you tell us when the code is ready for general consumption?

Yes, absolutely. It is taking a bit longer than I first expected. We are fine-tuning and optimizing it now. The calculations are very critical, and difficult to get exactly right.

Please don't expect a miracle. The code basically adjusts the renderer to reduce unwanted issues, but it does not eliminate all the issues. In levels without tall ledges and deep pits, the wiggle effect is practically eliminated. But, in taller rooms, the effect is simply reduced. Once it is properly adjusted, I will post an "upgrade kit" that will explain everything needed to add the WiggleFix to a source port.

Hopefully, we'll be done by Monday. But, if we come up with a better way to do it, it may take a bit longer.

[plums]

Just reporting that using the Sept. 24th build I get good results and no errors on a few maps that have large height differences. (AV MAP29, Invasion E1M3) Looking forward to the final patch!

[bradharding]

plums said:

Just reporting that using the Sept. 24th build I get good results and no errors on a few maps that have large height differences. (AV MAP29, Invasion E1M3) Looking forward to the final patch!

Same here. I've been a bit premature and committed it to Doom Retro. It appears to work beautifully!

[kb1]

Yeah, we're real close. Please do apply the final code that, hopefully, I'll post tomorrow at about this time. It will have some final optimizations and adjustments, complete with comments and credits, and it would be nice if everyone's code matches!

It's been a long road, but I think it's going to be as good as it gets, without radical renderer changes.

[Doom_user]

There's severe visual corruption in GLBoom+ when the player enters sectors with deep water and/or colormaps. It affects the status bar, the player's weapon, on-screen messages, and menu graphics. It starts when you first go below a deep water surface. After that, some things will be corrupted when you're above the deep water surface and other things will be corrupted when you're below it.

Tested with BOOMEDIT.WAD

[plums]

Doom_user said:

There's severe visual corruption in GLBoom+ when the player enters sectors with deep water and/or colormaps. It affects the status bar, the player's weapon, on-screen messages, and menu graphics. It starts when you first go below a deep water surface. After that, some things will be corrupted when you're above the deep water surface and other things will be corrupted when you're below it.

Not getting that with the latest 2.5.1.4.test version, and commercial doom2.wad. What version are you using? What FreeDoom iwad is that?

[Doom_user]

plums said:

Not getting that with the latest 2.5.1.4.test version, and commercial doom2.wad. What version are you using? What FreeDoom iwad is that?

I'm using Freedoom Doom 2 iwad (date modified 5/12/2012 11:10am).
I tested this with GLBoom+ 2.5.1.4.test (date modified 9/20/2014 3:31pm) and GLBoom+ 2.5.1.4.test (date modified 9/24/2014 7:26pm).