Slashdot Mirror

← Back to Stories (view on slashdot.org)

Codeplay Responds to NVidia's Cg

Posted by michael on from the my-megapixels-are-bigger-than-yours dept.

Da Masta writes "Codeplay Director Andrew Richards has some interesting things to say about NVidia's Cg graphics language. Just to refresh, Codeplay is the company that publishes Vector C, the badassed, high performance C compiler. In brief, it seems as though Cg isn't the universal, standard graphics language some pass it off to be. Certain design considerations in the language, such as the lack of integers, break/continue/goto/case/switch structures, and pointers suggest a general lack of universal usefulness. This leads to suspicion that NVidia plans to add and tailor the language in the future according to its own hardware and their respective features. Of course, this is all old news to those of us who noticed NVidia co-developed the language with the Evil Empire."

1 of 163 comments (clear)

  1. My bone with Cg by Anonymous Coward · · Score: 0, Flamebait

    've been coding in Cg for some time, there have been a number of problems I've faced so far:

    1. The vertex engine calls are not logical. Sometimes you call passing a referenced pointer, other time you have to pass a referenced strucute, some form of standarization to calls would have made it easier for developers to write function calls (more insane than POSIX threads).

    2. The lanugae is not truely Turning complete. Which could have been fixed by taking some more time and making the language more complete.

    3. The compiled bytecode is giving a security mask that disables it's use on chips that do not carry a compliment decoder (To keep competetors away?).

    4. Confusing definitions of pointer/references. They could have made this easier by removing the entire pointer usage.

    5. Class calls outside of friend functions can at certain times reach memory outside of parent definitions (Bad language design?! I think this is one of the most debated feature/bug, since you can piggyback this to implement vertex calls within lighmaps).

    6. No SMP support in current implmentation and no thoughts to future support (What about threading?!).

    7. Inlining support is bad and possibly unusable outside the scope of inling cg within c.