This is Woof! 15.0.0 (Nov 23, 2024)

I'm a codelet, what is SDL?

3 hours ago, ChopBlock223 said:

I'm a codelet, what is SDL?

https://www.libsdl.org

https://github.com/libsdl-org/SDL

https://discourse.libsdl.org

https://discord.com/invite/BwpFGBWsv8

https://netsplit.de/channels/?chat=sdl

Google is NOT your friend, but I can be for the right amount, name your price.

I read SDL 3 will support Vulkan too, damn nice, can't wait.

So do I just politely ask these guys if they they're willing to add support for my pet peripheral?

Yes, we can only support in our engine what SDL2 already supports, because we use it as a hardware abstraction layer. 

Could you please file an issue at

https://github.com/libsdl-org/SDL/issues

requesting for your controller to get supported and provide a much information as possible about it. That'd be appreciated. 

(I think they even have a gamepad test utility, but I'm not so sure at the moment.)

Sometimes getting weird pixel artifacting with some sprites with Woof 14.2.0, both custom sprites and actors, and with vanilla ones.
 

Is this something that's up with my settings, or is anyone else getting this?

32 minutes ago, ChopBlock223 said:

Is this something that's up with my settings

Pretty sure it's the dynamic resolution (dynamic_resolution in the .cfg).

2 minutes ago, CacoKnight said:

Pretty sure it's the dynamic resolution (dynamic_resolution in the .cfg).

I edited the config to turn it off, and it actually got more frequent.

I can't get a screenshot because it seems to happen quickly.

39 minutes ago, ChopBlock223 said:

Sometimes getting weird pixel artifacting with some sprites with Woof 14.2.0, both custom sprites and actors, and with vanilla ones.

Hmm, not sure what is happening. What is this PWAD/MAP? Can you record a demo?

Just now, rfomin said:

Hmm, not sure what is happening. What is this PWAD/MAP? Can you record a demo?

A work in progress. How would a demo help? Wouldn't it render fine on your end if you don't have this problem? I get the feeling that I can PROBABLY reproduce this with the stock game, I'll try that in a bit.
I managed to catch a screenshot of it, it seems that it's more likely to happen at further distance away from the player, and that this goes for both original and new things. The Mancubus fireballs do this too.

If I were to take an uneducated shot in the dark, I would suggest that it has something to do with translucency, maybe lighting and color too.

When I look at items and static objects which are NOT translucent, they don't get all the white crap pixels around them, but what they do tend to get (at least temporarily), is little odd streaks underneath the sprites, and the color looks like that one shade of pale reddish-purple which iD used for transparency.

I did not experience this in 14.0.0 or earlier.

Alright, here you have it happening with unmodified doom2.wad

The screenshot has been taken with 900p resolution. If you switch to 800p, I guess you'll never see this again. Could you confirm?

3 hours ago, fabian said:

The screenshot has been taken with 900p resolution.

Hi Fabian. Is this a typo? Chopblocks screenshot looks to me as it has a 600p resolution when i am looking at the black lines at the TEKGREN textures and the ceiling.

I'm talking about the latest one they posted. The picture is 1080 pixels high, divided by 1.2 gives 900p.

I'm asking, because 900p is 4.5 times Doom's original resolution. This means that each sprite need to be scaled up by factor 4.5. However, when transforming from screen to sprite coordinates you have to skip to the next pixel each 200/900 pixel, which is a ratio that you simply cannot represent precisely using FRACUNITs. 

PS: Same stuff happens at 600p, where 200/600 = 1/3 does not have an exact representation in FRACUNITs. 

On 3/11/2024 at 10:07 PM, fabian said:

I'm talking about the latest one they posted. The picture is 1080 pixels high, divided by 1.2 gives 900p.

 

Me too. I know about DOOMs 20% stretch in height and that was what confused me, because my 900p picture on a 1080p monitor/screenshot is way sharper and had no garbage pixels.

You can see it here:

I could reproduce Chopblocks problem. And now it gets criminal.

The garbage pixels showed at a resolution slider range from 100% to 225%.

400p should be a good scalable one as far as i understand. So it is not good that 400p is in the range with garbage pixels.

And 200p is DOOMs original resolution.

I had recreated the same scene with the same explosion-sprite like Chopblock had and paused it via esc to get in the menu and use the resolution slider. So i had a live picture when the garbage pixels happen.

They came only in a range from 100% to 225%.

When i set the slider to 250% and up, the garbage pixels went away.

Dynamic res was set to off to ensure that the resolution is exactly what i had tested.

Test pictures here:

Quick, but stupid question: Does Woof support MP3 files as music tracks?

40 minutes ago, Ar_e_en said:

Quick, but stupid question: Does Woof support MP3 files as music tracks?

Yes, through libsndfile.

2 hours ago, Meerschweinmann said:

The garbage pixels showed at a resolution slider range from 100% to 225%.

Interesting, but I still can't reproduce it. Please try downloading and unzipping Woof 14.2.0 into a new folder (to make sure there is nothing in autoload folders, etc) and try to reproduce this with a new config.

4 hours ago, rfomin said:

 

Interesting, but I still can't reproduce it. Please try downloading and unzipping Woof 14.2.0 into a new folder (to make sure there is nothing in autoload folders, etc) and try to reproduce this with a new config.

Hi Roman, the only things i had in autoload folder was the idkfa Soundtrack and Voxel-doom. But as you can see at my first Screenshot without menu, i had removed them before testing.

Used Version was the last official release, No development version.

In about an hour i make a new copy of Woof and test again. If the garbage Pixels go away i will test which option triggers it.

Eventually it has something to do with aspect ratio, because on my 16:10 1600p notebook screen i had never seen this. I will have a look If i can reproduce it with my Notebook too.

@rfomin, you wont believe.

I went through my old config and the new fresh Woof copy config with KDiff 3 and changed every video related option. Nothing.

Then i enabled the mouselook. And it was there.

It is the changed y axis and the angle you shoot at this corner in Map01. When mouselook is turned on and i move with keyboard only to shoot in this dark corner in Map01, there are no garbage pixels.

When i touch the mouse slightly to look a bit up those pixels appear more or less. 

Because i can't believe i did that test more than once.

PS: I did a countercheck and turned mouselook in my old Woof copy off. Now the garbage pixels are gone there too and i can activate them when turning mouselook on and using the y axis.

8 hours ago, Meerschweinmann said:

Me too. I know about DOOMs 20% stretch in height and that was what confused me, because my 900p picture on a 1080p monitor/screenshot is way sharper and had no garbage pixels.

Oh, I was naively assuming native resolution, because that would fit better to the explanation I was trying to give. ;)

But now that we talk about it, my thesis would only explain garbage *screen pixels* (such as the ones reported here https://github.com/fabiangreffrath/woof/issues/1392 ), whereas the issue at hand seems to trigger garbage *sprite pixels*. That's a different root cause then. 

Edit: And I'm glad you found it while I was writing this. ;)

On 3/12/2024 at 8:40 AM, fabian said:

And I'm glad you found it while I was writing this. ;)

You all are giving me so much fun with Woof, so i'm glad i could help you a bit :) 

One thing i had tested now. The aspect ratio and screen resolution make no difference.

Here is a screenshot from my 16:10 1600p notebook display. When using the y axis of mouselook i can trigger it here too behind the FOV slider.

The thing is, you have to use resolutions lower 250%, use mouselook and get the right angle to view the sprite.

So it is not surprising that there are not hundrets of people who noticing this.

57 minutes ago, Meerschweinmann said:

Then i enabled the mouselook. And it was there.

Thanks for testing! I was able to reproduce it. It seems to be related to an "improvement" I recently made to the mouse look calculations.

20 minutes ago, fabian said:

But now that we talk about it, my thesis would only explain garbage *screen pixels* (such as the ones reported here https://github.com/fabiangreffrath/woof/issues/1392 ), whereas the issue at hand seems to trigger garbage *sprite pixels*. That's a different root cause then. 

I think it's an unrelated problem.

23 hours ago, fabian said:

The screenshot has been taken with 900p resolution. If you switch to 800p, I guess you'll never see this again. Could you confirm?

I don't know how to calculate that value off hand, and that isn't a parameter or value described in the options.

I switched to a 400% resolution scale, and that seems to fix it for me (I also told NVidia to actually use my dedicated GPU for rendering Woof, but that did nothing by itself).

Still worth looking into what causes this though, and again, it seems to relate to translucency at distance (for the white pixel noise anyway). The little pale purple pixel lines on non-translucent graphics almost seem like they behave slightly differently, but it's harder to gauge. They are on the zombiemen corpses in the Doom 2 screenshot.

Maybe this is an inherent issue with uneven resolution scaling, hence it shows at 300% but not at 400%. Like it wants to be power of two.

17 hours ago, Meerschweinmann said:

I could reproduce Chopblocks problem. And now it gets criminal.

 

The garbage pixels showed at a resolution slider range from 100% to 225%.

 

400p should be a good scalable one as far as i understand. So it is not good that 400p is in the range with garbage pixels.

And 200p is DOOMs original resolution.

 

I had recreated the same scene with the same explosion-sprite like Chopblock had and paused it via esc to get in the menu and use the resolution slider. So i had a live picture when the garbage pixels happen.

 

They came only in a range from 100% to 225%.

When i set the slider to 250% and up, the garbage pixels went away.

This is interesting, I was on 300% when it happened, and then it stopped at 400%. I'm glad that someone can reproduce this, and that I'm not crazy or having a hardware problem.

I guess I'll try and see what I get with different scaling when I get back to my computer, will I get them on the same values?

9 hours ago, Meerschweinmann said:

Then i enabled the mouselook.

Oh, that is VERY interesting. I had actually been using the vertical mouselook in Woof just now, not for aiming but for visually inspecting levels in software mode.

40 minutes ago, ChopBlock223 said:

This is interesting, I was on 300% when it happened, and then it stopped at 400%....

The higher i was going with resolution, the fewer garbage pixels i had and the harder it is to get them was my impression.

With 250% they went away in this test-scenario for me.

But even i saw none at 300%, that does not mean that there could be none with an other y axis mouselook angle.

What me made wondering was that it happened with 100% and 200%.

Roman seems to know what produces these garbage pixels, so there is hope for a garbage pixel free Woof :)

40 minutes ago, ChopBlock223 said:

Oh, that is VERY interesting. I had actually been using the vertical mouselook in Woof just now, not for aiming but for visually inspecting levels in software mode.

Yeah, with mouselook off everything is fine with my two PCs i had tested. Btw, i have been doing sightseeing too with mouselook in great and beautyful WADs :) 

2 minutes ago, Meerschweinmann said:

Roman seems to know what produces these garbage pixels, so there is hope for a garbage pixel free Woof :)

 

Should be fixed in these artifacts: https://github.com/fabiangreffrath/woof/actions/runs/8245362214?pr=1584

7 minutes ago, rfomin said:

Should be fixed in these artifacts: https://github.com/fabiangreffrath/woof/actions/runs/8245362214?pr=1584

Hooray, that was a fast fix.

I've shoot the hell out of this dark corner in Map01 with 100, 200 and 300% resolution and could not notice those garbage pixels anymore with different y axis angles.

Thank you!

Glad I could draw attention to and get a problem fixed. Looking forward to further developments of Woof, like always.

Eternal Doom drag&drop works perfectly now without removing the NULL.WAD from inside the .zip, thank you.

Playing 2022 A Doom Odyssey with new Woof version. I sometimes got this vertical lines. I`m playing with wrong port or this is a wad\port bug?

Looks like slime trails. Do they vanish if you play with the `-bsp` parameter?