[fixed][0.9.17] Dots Appear When Using The Main Menu

Post by **Graf Zahl** » Sat Jan 07, 2006 23:06

It's the same card as the one of Deathlike. I find it strange that such a modern card is having such severe problems with it. With NVidia cards I haven't seen these issues since the Geforce 3...

entryway · Post by **entryway** » Sat Jan 07, 2006 23:53

I did not face this problem never and anywhere except for Doom Legacy and GZDoom. I think there is a sense to change algorithm to more loyal. Like in glboom for example. It works fine, quick and without any bugs on any videocards. Isn't it?

Post by **Graf Zahl** » Sun Jan 08, 2006 0:30

The funny thing is that my renderer evolved out of GLBoom. The only major difference is that I don't use the tesselator. I always use GL nodes. If you set gl_render_segs to true the geometry should be exactly the same as GLBoom forced to use GL nodes (and as any other port using GL nodes.)

If gl_render_segs is set to false though, I am rendering complete linedefs as opposed to single segs. That reduces the amount of polygons quite noticably and increases speed. But it may create small gaps.

Another thing to consider is view pitch. Without it (like PrBoom) the chance of rendering gaps is significantly smaller because these gaps don't happen on perfectly vertical lines.

entryway · Post by **entryway** » Sun Jan 08, 2006 0:53

This mistake is very strongly appreciable (in 100 times more than at usual levels) on acs_demos.zip\map06
How much I have understood - a problem that you draw the sky at first on all area of the screen and then everything else.

Post by **Graf Zahl** » Sun Jan 08, 2006 1:21

Ouch. That doesn't look good at all and can not be explained by the way I am rendering things.

The only thing I can suggest is to verify all settings in your graphics driver. Maybe some are set to some fast settings instead of quality. This looks like the driver is throwing away a good portion of the coordinates' precision.

BTW, how is JDoom behaving on your system?

chopkinsca · Post by **chopkinsca** » Sun Jan 08, 2006 2:46

I had this problem, the dots at seams would appear almost everywhere. Turning up AA seems to fix most of it though (edit: maybe not). I have an ATI 9600xt.

I have all the settings set to quality, and gl_render_segs 1. On one map, the AA made the dots go away, but as in the screenshot, they came back. edit: hold on, didn't see that the attachment failed because of size.

Post by **Graf Zahl** » Sun Jan 08, 2006 10:42

Seeing stuff like that makes me wonder how ATI can still sell cards. Apparently their hardware is geared to render modern games properly but they don't give a damn about older stuff. Not even my old Geforce 2 had such obvious rendering precision issues than the screenshots here. But these are issues any Doom source port in existence should have because they all are rendering walls in the same manner.

All this convinces me even more to stick to NVidia but I'll see that I add an option that doesn't clear the entire screen with the sky's contents. Hopefully that helps hiding the problem a little. If the pixels remain at the value of the previous frame the gaps will be far less noticable.

entryway · Post by **entryway** » Sun Jan 08, 2006 10:43

Graf Zahl wrote:Another thing to consider is view pitch. Without it (like PrBoom) the chance of rendering gaps is significantly smaller because these gaps don't happen on perfectly vertical lines.

I don't use classical PRBoom. PRBoom-Plus allows to view up and down.

Graf Zahl wrote:BTW, how is JDoom behaving on your system?

Works fine. Without any dots.

Remember. Points are visible only with a bright texture of the sky.

The screenshot from chopkinsca is very similar to mine. Points not strongly noticeably in a static position, but they are very appreciable at movements. It reminds me of a New Year tree.

Post by **Graf Zahl** » Sun Jan 08, 2006 12:12

I'll compile a new version today that adds a new option to draw sky only where it is needed. I hope that reduces the problem to a point where it isn't that noticable anymore.

entryway · Post by **entryway** » Sun Jan 08, 2006 12:16

I hope too :)

chopkinsca · Post by **chopkinsca** » Sun Jan 08, 2006 13:25

I don't know what it means, but maybe this post on an ATi forum means something: Here

entryway wrote:
Graf Zahl wrote:BTW, how is JDoom behaving on your system?
Works fine. Without any dots.

Same with me, no dots in jdoom.

Post by **Graf Zahl** » Sun Jan 08, 2006 14:08

chopkinsca wrote:I don't know what it means, but maybe this post on an ATi forum means something: Here

No. I'm not using that extension. But it's just one more reason not to buy ATI - ever!

entryway wrote:
Graf Zahl wrote:BTW, how is JDoom behaving on your system?
Works fine. Without any dots.
Same with me, no dots in jdoom.

I just checked the Doomsday source. It looks that it is doing some subdivisions of wall polygons to reduce the seams. A long time ago I tried the same thing but it became unnecessary when I upgraded my video card so I never finished it. I hope I can find that code and re-integrate it into the renderer.

Still, why does NVidia manage to handle this without problems but ATI fails miserably? Their rendering pipeline must be significantly less accurate for such big holes...

entryway · Post by **entryway** » Sun Jan 08, 2006 14:49

In jDoom it is made better than somewhere. In PrBoom a points still appears sometimes (If behind a seam there is a light texture. Vertexs 137, 149 @ ndcp.wad\map04 for exaple. It appears in DoomBuilder also), but in jDoom - never.

entryway · Post by **entryway** » Mon Jan 09, 2006 14:13

entryway wrote:acs_demos.zip\map06

I think that vertexes don't have identical coordinates in adjoining polygons there

Post by **Graf Zahl** » Mon Jan 09, 2006 14:19

No, they don't. If you look carefully the seams are all on the vertical edge of a window or crate. I am going to add some code to split such polygons which hopefully gets rid of this effect. I'll make it optional though because on modern NVidia cards it only wastes processing power.