ARB Fragment Programs

[jitspoe]

Have these gone the way of the dinosaur? Seems kind of difficult to find resources for them anymore. I guess GLSL support is pretty solid now? I'm kind of afraid to switch as it might break things (on crappy ATI drivers) for people that were working before. I also kind of like that the ASM forces you to think about every instruction so you can write more optimal code.

[revelator]

Not used much anymore so aye most is done via glsl these days.

SikkPin still uses them though, maybe you can get some help from him atm hees looking for some help with some engine side code for screen Space ambient occlusion, he has the shader Work done but
is having some trouble with Doom3's internals. If you can help him with that i bet he would be happy to create ASM shaders for anything you might need.

You can reach him at doom3world or here.

[Spike]

the only real reason you might want to use ARB programs instead of glsl is on account of intel drivers (intel for a while provided no glsl support in windows, linux was fine though). however, intel do supposedly now provide drivers that support glsl on windows, and thus the only real reason to use arb programs over glsl has gone away with a driver upgrade, presumably.
this is true of pretty much any hardware that supports more than 4 registers, anyway...

there are still a few driver issues with certain extensions, but the core features should be robust with all vendors. one of those 'give me a test case and I'll make it pass' things, I guess.

[leileilol]

There's also the very unfortunately common case of "pro gamers on GeforceFX". GLSL really sucks on GeforceFX, and they're more likely to be found on the Free games nowadays because they can't run the Source ones or modern ones very well.

[jitspoe]

Interesting. Thanks for the responses. I'll probably just stick with ARB fragment programs unless there's a really convincing reason to move to GLSL. From what I can tell, pretty much everything that supports GLSL has solid ARB fragment program support, so that's the best way to go from a compatibility standpoint.

If anybody knows of any good resources, feel free to post them.

[Spike]

leileilol: use half floats... they'll double your performance.
glsl requires at least 24bit floats. ati has that, while gffx cards have alternative 16bit or 32bit modes - 32bit being half as fast with at least 24bit precision and thus the default mode.
that said, depending on an extension is nasty.

nvidia still provide new extension features for ARB programs. ati does not. no idea about intel. if you're not using gl3 features like texture arrays, it doesn't really matter which you use so use whichever you're more comfortable with.
also, compile times with glsl can be quite annoying, if you're auto-generating them. :s

[mh]

[revelator]

Totally agree i find the C like interface of glsl to be rather confusing cause its so strict you cannot cast simple types to another "vec2 to float cast or vice versa"
(though newer versions actually started supporting that to some degree) the older versions dont allow it at all so you need the exact type to cast to.

Example

The above is not legal according to the GLSL specification 1.10. With GLSL 1.20, it becomes legal.
float texel = texture2D(tex, texcoord);

The above is wrong since texture2D returns a vec4. Do one of these instead:
float texel = texture2D(tex, texcoord).r;
float texel = texture2D(tex, texcoord).x;

Many more examples also nvidia and ATI glsl versions differ on some types oh hell :S

[Barnes]

I removed arb_fp support a long time ago, and the totally reworked to render glsl. Compatibility I absolutely do not care and intel I just will not start. Pull a "zoo of old iron" I'm not going to.