Beta6: Stairs Bug

[Antagonist]

ATI are asses is all I can say at this point in time.

Your glewinfo suggests that your card supports OpenGL 3.0, looking it up says your card only supports OpenGL2.0, not even OpenGL2.1. I'm guessing it supports the later OpenGL API versions with driver side trickery... but... that still doesn't help with shaders that get run on the card itself. OpenGL 2.0 is pre-GLSL 1.2 even.

I am not entirely sure what the problem is. Its either the for loop it cant unroll or its reached its instruction limit. Either way, please make the following 2 modifications and try again:

Add the following like to the top of your unique_glow.frag file:

Code: Select all

#version 120

And change blursize to 5:

Code: Select all

int blursize = 5;

Hope that helps. Testing on older GPUs like this does help us to discover hidden bugs ignored by fancier GPUs, but... it also exposes a bunch of broken functionality that older GPUs have that they really shouldn't.

Anyway, thanks for the reports.

EDIT: If it doesn't work, try a blursize of 3 or even 1, but the smaller you make it the less perceptible the unique glow will be. If it STILL doesn't work try without the version line.

[f_i_r_s_t]

Nothing above helped so far.. I'm fed up with ati as well.
Let's keep on trying

[shani]

Remove shader and all references to it?

[Antagonist]

I havn't tested this one, it might fail horribly due to a missing semicolon or something, but I edited the .frag to basically WRITE OUT the for loop's equivalent of blursize 1.

Code: Select all

uniform vec2 texSize;
uniform sampler2D tex;
uniform vec4 color;
uniform float tick;

void main(void)
{
	float fTime0_1 = tick / 5000.0;
	vec2 offset = 1.0/texSize;

	// Center Pixel
	vec4 sample = vec4(0.0,0.0,0.0,0.0);
	vec4 center = texture2D(tex, vec2(gl_TexCoord[0].st));

	sample += texture2D(tex, vec2(gl_TexCoord[0].xy+vec2(-offset.x, -offset.y)));
	sample += texture2D(tex, vec2(gl_TexCoord[0].xy+vec2(-offset.x, 0)));
	sample += texture2D(tex, vec2(gl_TexCoord[0].xy+vec2(-offset.x, offset.y)));
	sample += texture2D(tex, vec2(gl_TexCoord[0].xy+vec2(0, -offset.y)));
	sample += texture2D(tex, vec2(gl_TexCoord[0].xy+vec2(0, 0)));
	sample += texture2D(tex, vec2(gl_TexCoord[0].xy+vec2(0, offset.y)));
	sample += texture2D(tex, vec2(gl_TexCoord[0].xy+vec2(offset.x, -offset.y)));
	sample += texture2D(tex, vec2(gl_TexCoord[0].xy+vec2(offset.x, 0)));
	sample += texture2D(tex, vec2(gl_TexCoord[0].xy+vec2(offset.x, offset.y)));
	
	sample /= 9.0;

	float a = 1.0-center.a;
	
	float delta = sample.a;
	gl_FragColor = mix(center,delta*color,a);
}

Lemme know if it fails with 'Fragment Shader not supported by HW' again.

[f_i_r_s_t]

With the new .frag I got to level 5! No crash so far.
Thank you, so far!

[Antagonist]

Well, I could just give you something that will disable that shader But with your help I'm closer to figuring out WHY this is happening and a way to stop it happening next beta.

Well, lemme know if it crashes again.

[mutantant]

Hello all. First post here, but I wanted to throw in an error on my system that kicks me out when going into the 5th level, just as stated above, but with a totally different shader error.

Code: Select all

[MOVE] actor moved without a starting position	The Shade of Angmar	25	48
[SHADER] making shader from	unique_glow	 into 	unique_glow[]
[SHADER] Loading from /data/gfx/shaders/unique_glow.lua
New GL Shader program 3
New GL Shader 4 of type 35632
[SHADER] created fragment shader from /data/gfx/shaders/unique_glow.frag
OPENGL ERROR: Program Validation FailureValidation failed! - Different sampler types for same sample texture unit in fragment shader

When I paste the changes into the frag file, the error DOES go away, but as you can see it is indeed a bit different of an error. Vista 64 with ATI 4850 Crossfire config.

Just to add to what has already been said above, I will definitely avoid ATI cards from now on - not due to this in particular, but the many issues that I have had due to these otherwise great cards. Issue after issue, to the point that one of their driver releases would uninstall itself after every reboot!

Great stuff BTW, very fun and interesting so far.

EDIT: Sorry my mistake - I broke the cardinal rule of message boards - read ALL the posts in a thread The previously posted zip download with the 2 new files in it fixed me up perfect, no extra attention needed. Thanks.

[Antagonist]

<rant>

Okay, as for the ATI vs Intel vs NVidia thing...

Noone cares about OpenGL. Everyone cares about DirectX. Its that simple.

ATI is NOTORIOUS for not really having good OpenGL support until recently, which is weird, cos one of the best GLSL IDE's, RenderMonkey, is an ATI product. But ya, weird errors, failures, esp with old cards. When I worked on AMPA I got weird OpenGL error reports even from 4000 series cards which are newish and should be better than that. So far I have not had any AMPA error reports with the 5000's, their new DirectX11 cards, which suggests they are getting better.

Contrast to Intel integrated cards. Simply, they are crap. But they are cheap, and should be more than powerful enough for a roguelike, so I'm basing them as my minimum spec GPU. If you have one, you should be fine for playing ToME in the future no matter how fancy we get. Shockingly tho... they also work. Everything beyond X3000 I have actually not received much error reports on AMPA about. The two cases on the forums where Intel GPUs are involved were solved by simply updating drivers.

And then NVidia. They dont care MUCH about OpenGL either, but they support it best, now and in the past. I have a friend with a 7 year old NVidia GPU who can run AMPA without errors, just... slow. But thats more my crappy code's fault than the GPU. Any newer stuff that that just works too, never had a single error report. Additionally, I've got a GTX 260 in my machine, so NVidia is what I dev my shaders on.

</rant>

Now... onto this SPECIFIC problem.

Unlike AMPA which just had the shader based codepath, T-Engine4's codepath assumes no shaders, but it can switch on and off stuff like 3D textures, FBOs, shaders, depending on whether it detects those features on the cards. The detectable features are listed in the glewinfo file, and its marked with OK or MISSING depending on whether the GPU supports it or not.

Now, I just looked at the usual suspects so far, still need to find time to go over it with a fine-toothed comb, but from what I've looked at so far, there is no extention I can see thats MISSING on the X700, which gives this error, but OK on the other GPUs where it works. In fact, the X700 is saying OK to alot of stuff its specs clearly say it cant do, like OpenGL2.1 and OpenGL3.0 support. So we have no way to test and automatically disable these kind of shaders with for loops.

So... I need to find some way to dumb down the shaders so it works for everyone but still looks good. The testing F_I_R_S_T has done has gone a long way to that, I have some more ideas on what to try now. Okay well, F_I_R_S_T is the only one so far with the for loop in shader issue, but the different sampler types error seems abit more common so I should try tackle that one first.

[darkgod]

Shaders are fun ! or not

Anyway when things are settled a bit more I'll disable the forced crash on bad shader and just ignore it