hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Thanks jr, for the initial versions.inc template. Yes, such an include
> could be provided with code. However, we'd need to be careful about
> 'declaring' any version of POV-Ray to be an official one. Today ONLY the
> pre-compiled windows releases are official.

made me think what is John/Jane User's perspective?  if they only ever use
official builds on MS Windows, then "the problems" do not arise.  if however
they write scenes which will get parsed by POV-Ray proper or a variant, then
they can source the include.  I think one can simply "turn the logic around"[*]
without harm, ie name the macro 'unofficial_program' + reverse its result.  then
we could write an even simpler conditional:

  #if (unofficial_program())
    ...
  #end

[*] assuming POV-Ray proper will continue to return clamped values + everybody
else switches to '99'.


> Hmm, suppose we could extend this code to optionally end with an #error
> if the desired hook or fork is not found for SDL written specifically
> for a particular fork.

re error, sorry snipped too much.  just to confirm, unlike on Windows, the
self-compiled POV-Rays all accept "unofficial" w/out a murmur.  while I can see
the logic, it feels wrong - now.  we're 2nd class users anyway, with RTR not
working :-(.

on the point, if I test in a scene for '6e4ed6c2' (:-)) but the executable is
older/newer/not compatible and won't do, then yes, I think it has to be an
error.


>  > what was (f_odd's) original purpose?  reading that the argument is
>  > a "field strength" made me wonder whether it's anything to do
>  > with 'blob's.
>
> I don't know, I think it was likely some unfinished effort where some
> initial code got copied. Code wise it was always a match for f_cushion()
> and so pointless as shipped.

I found _that_ definition (and description in the docs) equally .. illuminating.
 </grin>


regards, jr.

Post a reply to this message