[edit] actually, no it’s not a bug… 
[This message has been edited by knackered (edited 11-12-2002).]
I don’t know what bug you meant (since you removed your message ;-), but there are actually quite a few bugs or missing features in nvparse.
It doesn’t support the _sat modifier. Even though it now claims to support ps 1.1, it doesn’t correctly support the .b source register selector. It doesn’t correctly work for a lot of cases when using co-issued instruction pairs. It doesn’t correctly handle the replication of the result of a dp3 instruction into the alpha channel. And let’s better not talk about the syntax and semantic checking (which is incomplete to say the least).
The list probably goes on…
I discovered all these deficiencies recently when working on my own DirectX pixel shader -> OpenGL reg combiners/texture shaders translator.
I’d like to pitch in and complain too
First off, I hate the number of external files that it’s necessary to drag into my stuff to use nvparse.
It was still worth the effort, though, until I found that it doesn’t support VS1.1. See my frustration here: http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/007668.html
Between that and the incomplete state of all the shading languages, it’s back to opengl function calls for me
– Zeno
[This message has been edited by Zeno (edited 11-12-2002).]
Hi Zeno,
I wrote a couple of cross-compilers for various languages for my engine. They’re all open source and you can grab them from CVS of my project site http://xengine.sourceforge.net , if you’re interested. Of course, the translators themselves are tailored for my engine, but you can use the flex++/bison++ lexers/parsers that I wrote and slightly modify the translators to suit your needs.
A quick round up of what’s there right now:
ARBvp lexer/parser
NVvp lexer/parser
DirectX VS 1.0-1.1 lexer/parser
DirectX PS 1.0-1.3 lexer/parser
and translators for
NVvp -> ARBvp
DirectX VS -> NVvp
DirectX VS -> ARBvp
DirectX PS -> reg combiners/texture shaders
ARBvp -> DirectX VS
NVvp -> DirectX VS
[This message has been edited by Asgard (edited 11-12-2002).]
…and these are feature complete parsers/translators?!
Fantastic if they are… 
Pretty much. There are some things that cannot be translated and yield a warning or exception, but it’s usually nothing serious.
An example: In DirectX vertex shaders you can use any positive number to do indexed relative addressing into the constant registers. When using DirectX shaders on NVvp or ARBvp with the translator the maximum positive index is 63.
There’s a document on the site that describes all the restrictions and limitations in detail.
Hey, really nice engine!
Love the documentation.
One point:
Note that it is not possible to specify multiple bindings for a single vertex attribute. So it’s, for example, not possible to specify a binding that binds the second vertex attribute to TexCoord[0] and to TexCoord[1]. You’ll get an assert in the debug build of the library, if you try to do this. If you want to use one set of per-vertex texture co-ordinates for multipel texture stages, you have to write a vertex shader that copies the texture co-ordinates to multiple output texture co-ordinates registers.
Is there a technical reason for this? My renderer (which is not disimilar in design to yours) can bind a single attribute to multiple streams - but then again, I haven’t implemented the d3d interface as yet…is this a restriction of d3d?
That’s a limitation of the fixed function pipe in Direct3D. When using the programmable pipeline no such restriction applies.