#### 3.1.5 Cg programs

In order to define Cg programs, you have to have to load Plugin_CgProgramManager.so/.dll at startup, either through plugins.cfg or through your own plugin loading code. They are very easy to define:

    fragment_program myCgFragmentProgram cg
    {
        source myCgFragmentProgram.cg
        entry_point main
        profiles ps_2_0 arbfp1
    }

There are a few differences between this and the assembler program - to begin with, we declare that the fragment program is of type ’cg’ rather than ’asm’, which indicates that it’s a high-level program using Cg. The ’source’ parameter is the same, except this time it’s referencing a Cg source file instead of a file of assembler.
Here is where things start to change. Firstly, we need to define an ’entry_point’, which is the name of a function in the Cg program which will be the first one called as part of the fragment program. Unlike assembler programs, which just run top-to-bottom, Cg programs can include multiple functions and as such you must specify the one which start the ball rolling.
Next, instead of a fixed ’syntax’ parameter, you specify one or more ’profiles’; profiles are how Cg compiles a program down to the low-level assembler. The profiles have the same names as the assembler syntax codes mentioned above; the main difference is that you can list more than one, thus allowing the program to be compiled down to more low-level syntaxes so you can write a single high-level program which runs on both D3D and GL. You are advised to just enter the simplest profiles under which your programs can be compiled in order to give it the maximum compatibility. The ordering also matters; if a card supports more than one syntax then the one listed first will be used.

Lastly, there is a final option called ’compile_arguments’, where you can specify arguments exactly as you would to the cgc command-line compiler, should you wish to.