Yes thats the plan, but my fear is that im going to have to code 4 files. 1 GLSL, 1 fragment, 1 vertex, and 1 for both ATI_fragment_shader and NV_register_combine. Either that, or write a complicated parser to parse the fragment/vertex asm files and generate the OpenGL code like you said.
Yeah, writing such a general renderer is a big problem. I did it like that in Marathon initially, but then decided it wasn't worth the trouble and now I only have GLSL plus an NV_RC path for the crappy FX line of cards. Your decision should be based on what you want to support of course (we're going to support FX+, R300+).
By the way, I didn't mean an ARB_fragment_program to ATI_FS converter (very difficult), just a simple text representation of ATI_FS that can be easily modified without recompiling.
I still haven't looked at the NV_register_combine extention, is it similar to ATI's in terms of functionality? Any thing one of them doesn't support that the other does?
ATI_fragment_shader is the equivalent of NV_register_combiners + NV_texture_shader and both are the equivalent of DX <= 1.4 pixel shaders. Some differences:
- ATI_FS has a better internal color precision [-8, 8], whereas NV_RC has [-1, 1] with 9-bit signed fixed point values.
- NV_register_combiners is supported even on Geforce 1 & 2 (no NV_texture_shader though, only on NV20+), whereas ATI_FS needs R200+.
- NV has kept the NV_RC & NV_TS hardware on newer cards (super fast), whereas ATI is emulating the ATI_FS functionality with the fragment shader hardware on R300+ (I've not verified this, but even if it's true it's more than fast enough anyway).
Other than these, they are mostly equal in terms of functionality.
