[2.9pre-1532] Sloped floor rendering glitch

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: [2.9pre-1532] Sloped floor rendering glitch

Re: [2.9pre-1532] Sloped floor rendering glitch

by Graf Zahl » Wed Dec 07, 2016 11:46 am

Since this was a problem with the assembly code, it's no longer relevant.

Re: [2.9pre-1532] Sloped floor rendering glitch

by Graf Zahl » Sun Dec 04, 2016 8:48 am

That pixelated mess was something completely different, it just got a texture scaling factor wrong. The current glitch is an assembly drawer not doing what it should, while the C version of the same drawer is fine.

Re: [2.9pre-1532] Sloped floor rendering glitch

by simc » Sun Dec 04, 2016 7:56 am

Eruanna wrote:After some investigation, it appears this only affects the old x86-ASM renderer. Meaning, this problem does not occur in 64-bit builds.
When the slope rendering problems started they did occure both in 32 and 64-bit versions. But there were two different types of the error. Both 32 and 64-bit version showed some slopes just as a pixelated mess:
64-bit:
Image
Spoiler:
However in the same wad and the same ZDoom version the 32-bit version showed all the other slopes with the same "flooding" error what was described here earlier. 64-bit version rendered those slopes without errors.
Spoiler:
32-bit zdoom-2.9pre-415-g346fae8 (March 12th 2016) had no problems with slopes.

32-bit zdoom-2.9pre-506-g1648a71 (March 30th 2016) had no problems rendering slopes - but atleast KZDoom7.wad crashes at startup.
32-bit zdoom-2.9pre-854-g1722902 (April 25th 2016) KZDoom7.wad and my own wads crash at start up. (Both have slopes)

32-bit zdoom-2.9pre-928-g841a579 (May 8th 2016) has two type of slope errors: pixeled and flooding.
64-bit zdoom-x64-2.9pre-1021-gde0301a (June 16 2016) has pixeled slopes
64-bit zdoom-x64-2.9pre-1117-g5c182c7 (July 14 2016) has pixeled slopes

32-bit zdoom-2.9pre-1148-g4345623 (July 24 2016) has only the "flooding" type of slope error described in this topic earlier. Evey sloped floor and ceiling.

Re: [2.9pre-1532] Sloped floor rendering glitch

by Graf Zahl » Tue Nov 29, 2016 3:10 am

Rendering per-linedef is faster, because the amount of draw calls is reduced, even when adding the intermediate vertices. Otherwise each seg would have to run through the entire processing code which is all CPU time. And when pushing to the GPU, doing it as one polygon is simply less work than rendering each seg separately.

A similar approach may be usable for subsectors belonging to the same sector, the main reason this isn't done is that it'd increase the overhead for dynamic lights quite a bit because everything visible in a sector, as opposed to a subsector would have to be processed. It may be faster ultimately but I never went through with that part yet. NVidia drivers are capable to internally batching this stuff so that it won't cause slowdowns, but on AMD/Intel it might bring some improvements.

Re: [2.9pre-1532] Sloped floor rendering glitch

by dpJudas » Tue Nov 29, 2016 2:36 am

Ah, so because I render by subsector lines, while you render by linedefs, you need to compensate for that. My walls strictly speaking bends a little bit then. :) Makes me wonder which approach is faster, unless there's a specific reason why it has to be by linedef ofc.

Re: [2.9pre-1532] Sloped floor rendering glitch

by Graf Zahl » Tue Nov 29, 2016 2:28 am

Those are math imprecisions. I render linedefs as one polygon, but if a line gets split into multiple segs you get two subsectors or more whose edges border this linedef, i.e. the polygons on both side are not a perfect match. And sometimes that leads to single pixels not being drawn.
The only solution for this is to add intermediate vertices at the splitting location when rendering the wall. Of course this costs a bit of processing time.

Re: [2.9pre-1532] Sloped floor rendering glitch

by dpJudas » Mon Nov 28, 2016 6:44 pm

What are those sparkles about? It sounds like drawing the subsector lines like I'm doing in the poly renderer won't work in some situations?

Re: [2.9pre-1532] Sloped floor rendering glitch

by Graf Zahl » Mon Nov 28, 2016 6:06 pm

If it were that easy. :( The thing is, there's a few things adding up here: First, in order to avoid sparkles, every side of the wall needs to be split at any intersecting plane - which needs to be checked to see if the wall has to be recalculated. Due to that the size of the buffered data can also change, making it even more complicated. Finally, the vast majority of linedef has precisely 4 vertices and just pushing those to the GPU dynamically is nearly cost-neutral. The batches are simply too small for this to matter. Now, if the entire construction of the wall data could be skipped along, then we'd be talking business. But I don't expect this to be efficiently doable with all the restrictions and crustiness of OpenGL. With a modern API like Vulkan it'd be a LOT easier.

Re: [2.9pre-1532] Sloped floor rendering glitch

by dpJudas » Mon Nov 28, 2016 4:29 pm

Graf Zahl wrote:The sector vertices are already on the GPU. That part is easy. For walls it is different, because the necessary validation takes longer than just copying the vertices.
I meant for walls in the subsector as well. Mainly for skipping all the validation if the subsector is known to be identical to last frame, and to batch up draw calls. But alas, I should really study what its already doing exactly before commenting further on this.

Re: [2.9pre-1532] Sloped floor rendering glitch

by Graf Zahl » Mon Nov 28, 2016 4:27 pm

How about testing something realistic on that thing, like E1M6's opening cave of Phobos:Anomaly Reborn. It's clear that this computer is too slow for a modern killer map, but it'd be far more interesting to see how large the difference on something actually playable would be.

Re: [2.9pre-1532] Sloped floor rendering glitch

by Rachael » Mon Nov 28, 2016 3:26 pm

So I managed to find the oldest CPU I had that was still on a functional computer. An old HP Pavillion laptop from 2005.

Code: Select all

CPU speed: 1596 MHz
CPU Vendor ID: GenuineIntel
  Name: Intel(R) Pentium(R) M processor 1.60GHz
  Family 6, Model 13, Stepping 8
  Features: MMX SSE SSE2
Results were: With ASM, 915ms per frame, Without ASM, 985ms per frame.

Either way, it was a crapshoot, the map was literally unplayable, but a very interesting test none the less. :twisted: Oh - and I managed to overheat the CPU so badly that it had to throw the clock down really low for the later part of the ASM test (the framerate spiked up to 2000-3000 ms per frame at that point :mrgreen:)

Poor little laptop.... may you sleep peacefully and not have to be disturbed by such tests again.

This was an 8% difference.

Re: [2.9pre-1532] Sloped floor rendering glitch

by Graf Zahl » Mon Nov 28, 2016 12:19 pm

The sector vertices are already on the GPU. That part is easy. For walls it is different, because the necessary validation takes longer than just copying the vertices.

Re: [2.9pre-1532] Sloped floor rendering glitch

by dpJudas » Mon Nov 28, 2016 12:09 pm

My knowledge of how GZDoom draws the scene is still somewhat limited, but one of the things I've been thinking about while toying with the poly renderer is whether it would make sense to cache the vertices and draw lists needed to draw a subsector, or maybe even clusters of sectors (Doom sectors have waaaaay too few vertices to get their own draw calls). Since most sectors are static, with only a few changing based on events, it could use a system where it renders static sectors by firing off pre-compiled draw commands with vertices already on the GPU. This of course assumes there's a way to know if a sector has changed since the last frame.

Re: [2.9pre-1532] Sloped floor rendering glitch

by Graf Zahl » Mon Nov 28, 2016 11:45 am

Makes little sense with the majority of users on older systems and many struggling even with GZDoom 2.2's renderer.
I also don't have a Vulkan compatible graphics card yet, this is something for a few years in the future. Unlike GL 2.x/3.x, Vulkan will require some much deeper refactoring to gain from it.

Re: [2.9pre-1532] Sloped floor rendering glitch

by Major Cooke » Mon Nov 28, 2016 11:31 am

...which I somehow feel won't be coming to GZDoom with the way things are now, I take it?

Top