>> #local n--;
> 
> Oh yes, we should definitely add that to pov4 SDL!

and even I guess #local n++ should also be allowed ,-)

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

> A better solution would be to be able
> to define texturing shaders using a shader language. This language could
> do almost anything (including sending new rays) and affect the texturing
> of the surface in almost any possible way.
> ...........
>   Of course this doesn't stop POV-Ray from having a library of shaders
> which imitate what the current hard-coded lighting models and textures do.
> (In some cases perhaps some hard-coded versions may be necessary for
> speed reasons.)

I agree with Warp ideas. We could compare such a technique with Design Pattern
in programming language. Design Patterns says just to avoid hard-coded
features.

Post a reply to this message

Warp wrote:
>   Of course this doesn't stop POV-Ray from having a library of shaders
> which imitate what the current hard-coded lighting models and textures do.
> (In some cases perhaps some hard-coded versions may be necessary for
> speed reasons.)

And in point of fact, hard-coding the common algorithms is something 
that ought to be considered for version of POV-Ray beyond v4.

I know that there will be trade-off considerations.  Code that is 
simple, small, and very commonly used will be hard-coded first.

The way POV-Ray currently does macros allows something to be done with 
macros at the start, then implemented in binary later, and the only 
thing that has to be done to make the scene code work is to comment out 
the macro.

Giving the SDL the capability to detect whether a keyword is part of the 
SDL may be the simplest way to support this.  #ifndef makes semantic 
sense in this regard:

#ifndef(function_name)
   // SDL code to define function_name()
#end

Until function_name is hard coded, the code block defines the function 
and its behavior, but one it's defined, the SDL version is no longer 
needed and is no longer parsed.  If done right, the effect should be 
transparent to later users of the code.

Regards,
John

Post a reply to this message