In article <3d4b341f@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   This reminds me of something else: Seemingly patch makers have not followed
> the strict programming guidelines in the POV-Ray source code, which has
> caused a big problem: The code is extremely hard to optimize for RISC
> processors, which means that POV-Ray is quite slow in them, even though
> it could be a lot faster if the patches were coded in the right way.

What "strict programming guidelines" are you talking about?!?

The Source is very messy and inconsistent, badly commented, with 
different coding styles in different areas and often doing things the 
hard way when an existing function does the same thing. It isn't just 
the patches that have this problem, some of the worst code is very old: 
The leopard pattern (and several others) could be a 1-liner[1], but it 
uses 4 temporary variables. The onion pattern has a (unnecessary) 
variable named "noise" and the following comment:
/* The variable noise is not used as noise in this function */
The code is littered with unused variables and produces huge amounts of 
warnings.
And there is no documentation other than the source code itself, 
definitely no strict guidelines. And I don't think the code has ever 
been good on RISC machines...it has been like that from the beginning.


[1] Specifically:
return Sqr((sin(EPoint[X]) + sin(EPoint[Y] + sin(EPoint[Z])))/3.0);

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message