Upcoming release

[Graf Zahl]

I think the one issue that's most important right now is to get the Stereo3D processing fixed.
Another one I believe, that needs to be addressed is to change the rendering of wall and flat sprites without any alpha to be done in the solid pass, so that they can emit proper depth buffer information. That should take care of the worst issues with this.
Last but not least, the DONTFLIP implementation needs to be fully corrected. The PR sitting in the Bugs forum again seems to only patch the most egregious effects of this, but not provide a proper fix.

Is there anything else that needs to be taken care of?

[dpJudas]

I guess I could take a look at the Stereo3D processing, unless biospud is already looking into this. For the DONTFLIP thing, I'm not sure I really have a good enough understanding of all the various rotational modes a sprite can be in to fix this.

[Rachael]

Maybe for release, disable the flat sprites for now, release with that, and then put them back in the next development cycle so the feature can properly mature?

That way, you only have to worry about the solid walls and sprites and the 3D stereo stuff, which seems to be a lot less work than the flat sprites which, to be honest, may just need a complete code refactoring to make work?

Also - still have not been able to get the statistics code working. Can't figure out for the life of me what is wrong with it.

[Graf Zahl]

I think the flat sprites need one day of thinking. But it may be a week or two until I find the time to do that.
What certainly does not help is some external contributors continuously nagging that their features are given priority. If I can't work it out in the next two weeks I declare the feature experimental and just leave it as it is for now. It's not broken enough to disable it, but it's definitely incomplete enough to declare it unfinished.

[Major Cooke]

I think the flat sprites need one day of thinking. But it may be a week or two until I find the time to do that.

I admit, my attempts to maintain this after Nash stopped have been... well, crappy.

It's not broken enough to disable it, but it's definitely incomplete enough to declare it unfinished.

I silently wish fgsfds/marrub had continued doing this from the start instead of me since they were the one laying the foundations of flat/roll sprites, and they had a much better idea of how to run it than I. But then again, when they first made it, it was still done under the Draw function.

[Gez]

Hey, can we get a slight change in the fuzz shaders? Something that has long annoyed me was that the "size" of the "pixels" is hardcoded to 128, with code like this:

Code: Select all

	texCoord.x = float( int(texCoord.x * 128.0) ) / 128.0;
	texCoord.y = float( int(texCoord.y * 128.0) ) / 128.0;

However if we replace it with:

Code: Select all

	ivec2 texSize = textureSize(tex, 0);
	texCoord.x = float( int(texCoord.x * texSize.x) ) / texSize.x;
	texCoord.y = float( int(texCoord.y * texSize.y) ) / texSize.y;

Then the pixels correspond to the actual texels of the sprite, which makes the effect consistent in appearance regardless of the size of the sprite. I think it looks much better.

This concerns both fuzz_noise and fuzz_standard.

[Graf Zahl]

So, the Stereo3D stuff looks fine to me. Is there anything left to do?

I also decided to remove the completely misguided and broken approach to flat sprites. Before I address this for real I think the sprite processing code needs some major refactoring and cleanup. In its current state it will probably only cause more problems to do something.
I fixed the placement of wall sprites so that they go into the 'solid' render list if there's no actual translucency, so they get properly depth sorted.

[dpJudas]

Looks good to me.

[_mental_]

I added a comment to this commit as it crashes for me. I guess these lines

Code: Select all

if ((actor->renderflags & RF_SPRITETYPEMASK) == RF_FLATSPRITE)
{
}
else

should be replaced with something like

Code: Select all

if (nullptr == actor || (actor->renderflags & RF_SPRITETYPEMASK) != RF_FLATSPRITE)

but I'm not familiar with this part of code honestly.

[Major Cooke]

By translucency, you mean "Alpha 1.0"?

[Graf Zahl]

@mental: Yes, that's correct. I missed that while testing it.

[Gez]

If I may repeat myself...

Hey, can we get a slight change in the fuzz shaders? Something that has long annoyed me was that the "size" of the "pixels" is hardcoded to 128, with code like this:

Code: Select all

	texCoord.x = float( int(texCoord.x * 128.0) ) / 128.0;
	texCoord.y = float( int(texCoord.y * 128.0) ) / 128.0;

However if we replace it with:

Code: Select all

	ivec2 texSize = textureSize(tex, 0);
	texCoord.x = float( int(texCoord.x * texSize.x) ) / texSize.x;
	texCoord.y = float( int(texCoord.y * texSize.y) ) / texSize.y;

Then the pixels correspond to the actual texels of the sprite, which makes the effect consistent in appearance regardless of the size of the sprite. I think it looks much better.

This concerns both fuzz_noise and fuzz_standard.

I could do it but I'm not sure I could do it via pull request because of github limitations.

[Rachael]

I can make a PR for you.

Done: https://github.com/coelckers/gzdoom/pull/102

[dpJudas]

Isn't that PR missing the "ivec2 texSize = textureSize(tex, 0);" part? (just looked at the diff)

[Rachael]

Updated - and tested, this time.

Edit: Wow, I have no idea how I COMPLETELY missed that line in Gez's post. Sorry about that. >_<