>>There certainly is a good reason to use NV_vertex_program, at least in the world of real shipping software<<
that is just stupid. sorry.
updating drivers is easy, buying an nvidia gpu just to have a possibility to play a game isn’t. (while matt would love it that way for sure…)
backward compatibility is not a big problem. as i stated yet, most people need to update drivers to play an actual game anyways quite often, and else, they need it then. it’s quite normal, i had to do it on the gf2 as well all the time… so what?
multiple vendors compatibility IS a big problem. NV_vp runs on gf1,2,3,4,5, and pathelia (and mesa). ARB_vp runs on gf1,2,3,4,5 with newest drivers, will be in soon on pathelia (or is yet, dunno), and is in the next release of mesa. it is as well on the radeon8500, and bigger, 9000,9500,9700. it will be by a big chance on older radeons as well.
it is newer => not yet that supported. but it’s standart. and, now the major point. it WILL be supported for ever. well, as long as ever can be
do you think any future radeon will support NV_vp? do you think any future matrox will? any future 3dlabs? anything else? no. if you then relie on your game on nv_vp, you will be as lost as you are today trying to get glide working… NV_vp is proprietary, while currently quite a bit around spread, it should not be used anymore for any future projects. and even matt knows that. and its annoying to see he does not state that, mostly “refering to real world situation”. real world is not nvidia only. it’s nearly perverse to say NV_vp is bether then.
matt, i fully disagree on your position.
and what do you dislike in arb_vp? the aliasing? or that you can have named variables? makes cg less sweet, doesn’t it? arb_vp code is actually quite readable thanks to the variables and direct access to stuff like light[0].data etc…
still, i would use cg, if nvidia could release some standard compliant ARB_fp profile finally.