In article <41dcce25$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> I don't need a C compiler to run shaders written in C, any more than I 
> need a C compiler to run POV-Ray written in C.

You do, since shaders are almost never distributed as native machine 
code.


> > I'm talking about the C compiler you suggested using for shaders.  GCC
> > might suffice, if the license allows bundling it like this, but it would 
> > add several megabytes at minimum to the POV-Ray distribution.
> 
> I'm not sure why you wouldn't distribute shaders (or whatever you wanted 
> efficiently) in the same way you distribute POV-Ray now.

Because shaders are written by the users, not the developers. This is 
the point I think you've been missing. Shaders are used when the built 
in primitives are too limited or awkward to accomplish a given job.


> > Because it has its own custom language for functions, the closest thing 
> > it currently has to shaders.
> 
> This has too many typos and pronouns for me to figure out what you're 
> talking about. What's "it"?

"It" is POV-Ray. It supports user-defined functions which are compiled 
into opcodes for a virtual machine, and optional further compilation 
into native machine code. These functions can be used to define 
isosurfaces, patterns, and with a little extra work, pigments. Not quite 
a full-blown shader language, but the closest thing POV-Ray currently 
has.


> > If you used C for a shader language, you 
> > would need a C development environment.
> 
> I'm not sure what a shader language is. I'm not suggesting a shader 
> language, but rather the use of Tcl as the basis for SDL.

Rather than assembling a material out of predefined patterns, the user 
writes a "shader program", a function that computes the resulting color 
for the renderer. Tcl is probably quite unsuitable for this, so you 
would need a separate language just for shaders and similar 
high-performance functions. There isn't any particular reason the entire 
SDL couldn't use the same VM. Some capabilities, such as defining 
objects, would be "low performance" and would be a bad thing to put in a 
shader, but I don't see a definite reason to have separate languages.


> > I don't see how that helps the security of the code written in C.
> 
> I don't know why you're fixated on C.

Because you suggested it as a high-performance alternative to Tcl, for a 
shader language.


> > They're typically compiled to bytecodes and interpreted.
> 
> You mean, like Tcl.

Superficially. What I was trying to point out was the difference from C, 
in that machine-specific forms are rarely distributed widely. You need a 
compiler that supports the platforms, or you need a VM capable of high 
performance FP math. That practically means a custom VM, 


> > But if Tcl doesn't even have built-in numeric calculations, 
> 
> Of course it has numeric calculations built in. I just said the syntax 
> isn't quite as standard as you might want, nor are numeric expressions 
> likely as efficient as a language compiled all the way down to machine code.

Earlier, you said:
> Mind, Tcl isn't really good at math as such, but on the other hand since 
> math isn't technically built into the language, that would probably be 
> pretty easy to improve.

I might have misunderstood this, but I took it to mean that math is 
implemented on top of mechanisms provided by the VM, rather than built 
into the VM. The extra abstraction can be useful, but can really hurt 
performance in floating-point heavy stuff like shaders.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message