ZDoom

Beezle wrote:Hey Pixel Eater, normally I dislike motion blur in 1st person shooters but with the right settings, it actually works pretty well. I think you did a decent job here implementing it and the settings for it. By default its just a tad too much, but my personal settings are Samples - 5, Strength - 40 or 48, Recovery - on the default 64, and Blend - Lighten. I'd recommend these settings to anyone using this. Thanks Pixel Eater!

Pixel Eater wrote:

Remaker wrote:Yup, it goes away when it's off. However, another glitch with the new version is that normal mode makes everything look white. Unlike the black screen glitch, it doesn't intrude the status bar or the player weapon sprite, it just simply leaves the rest of my vision white, like as if the map is only a white void.

Thanks for keeping me up to date Remaker. Unfortunately it really seems like it's due to a bigger issue than the shader itself- it's defined as 'beforebloom' which means it can only affect what's behind the player sprite. If the glitch is happening in front of the status bar it's either hardware or something happening within GZDoom itself. That said, try this one and see if anything improves:

MBlur1.03x.pk3

I've marked it "x" as it's a regression because it gets the screen height within the shader itself rather than from zscript.

Pixel Eater wrote:

Beezle wrote:Hey Pixel Eater, normally I dislike motion blur in 1st person shooters but with the right settings, it actually works pretty well. I think you did a decent job here implementing it and the settings for it. By default its just a tad too much, but my personal settings are Samples - 5, Strength - 40 or 48, Recovery - on the default 64, and Blend - Lighten. I'd recommend these settings to anyone using this. Thanks Pixel Eater!

Thanks Beezle! In that case I'll make the default strength 44 for the next release

void main()
{
	vec4 C	;  // <-- no initialization, should be something like: vec4 C = vec4(.0, .0, .0, 1.);
	int i ;
	
	if( blendmode == 1 )
	{
		for( i = 0; i < samples; i++ )
		{
			C.rgb += max( C.rgb, texture( InputTexture, TexCoord + steps * i ).rgb ) * increment ;
		}
	}
	else
	{
		for( i = 0; i < samples; i++ )
		{
			C.rgb += texture( InputTexture, TexCoord + steps * i ).rgb * increment ;
		}
	}
	
	FragColor = C ;
}

OpenGL Shading Language spec wrote:Reading a variable before writing (or initializing) it is legal, however the value is undefined.

_mental_ wrote:The shader will work only if uninitialized variables are set to zeroes. If driver doesn't do this (and it shouldn't according to the spec), the result will be random.
Both branches read C.rgb without writing to it previously. Could you please fix this?