In article <3894D0C0.CBF01B51@enter.net> , Charles Fusner 
<cfu### [at] enternet>  wrote:

> ...won't change this behaviour even though setting...
>
> "#version official 3.1;"

You should be able to continue to use the "#version 3.1;" for backward
compatibility with the official 3.1 parser.

> in, it apparently automatically sets itself for version 3.00 which
> of course kills the #macro directive.

It still sets itself to 3.1, so this is either a bug (or a precision
problem).


     Thorsten

Post a reply to this message

sme### [at] skynetbe (smellenbergh) writes:

> MegaPov 0.4 is ready for downloading. 
> 
> You can find Nathan's Windows version at (this is not the usual place!):
> ftp://ftp.povray.org/pub/povray/Unofficial/MegaPOV/
> 
> The Macintosh version at the usual site:
> http://users.skynet.be/smellenbergh

First, let me thank you for the time that you invest in the megapatch. 

In frame.h it says:
    #define CLOCKDIVIDER CLK_TCK /*provided by standard c? */	
and as far as I know the answer is "No". According to the documentation
available to me, you should use CLOCK_PER_SEC instead and include <time.h>.

In postproc.c there are two //-comments. Remove the lines or comment
them out with /* */.

In tokenize.c I have removed the "Not-quite-so-Static" function declarations.
Now, only the static declarations exists. 


With these changes it compiles flawlessly under Sun Solaris using gcc.
You can dowload the modified version including the Makefile at
http://www.povray.willhalm.de/povaddon/

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

Yes, I use Ron Parker's brick wall code. Shouldn't it run with MegaPov 0.4?
What #statements should be present?

--
Regards,
Sander


Ken <tyl### [at] pacbellnet> schreef in berichtnieuws
3894ABB8.FA864E23@pacbell.net...
>
> Did you by any chance check it against the code Ron Parker recently
> posted in povray.text.scene-files ? That code is known to work with
> earlier versions.
>
>     Subject:  Re: Brick wall and paving stones macros (~80kb)
>        Date:  19 Jan 2000 10:15:35 -0500
>        From:  ron### [at] povrayorg (Ron Parker)
>  Newsgroups:  povray.binaries.images, povray.text.scene-files
>  Followup-To: povray.text.scene-files
>   References: 1 , 2 , 3 , 4

Post a reply to this message

"mr.art" wrote:
> 
> I have used the #macro statement without any problem.
> I did have to set  #version unofficial MegaPov 0.4; to
> get isosurfaces to work, but that was all.
> I am using WinMeagPov0.4. Are you on a different os?
> 

No, WinMegaPOV0.4 here. The only thing required to (reliably)
reproduce the problem for me is that I have to pull the...

Version=3.1

...out of my INI file. When this is done, without expressly
saying "#version official 3.1;" before the macro definitions
causes them to fail with the following error message:

C:\C_wip\test.pov:1: error: Macros require #version 3.1 but #version
3.00 is set

I may be the only person this even affects, of course.
I imagine most people keep the Version=3.1 in their INI
even though logically, it seems to me it should be
useless since the default version compatibility should
logically be the latest syntax. I would think the only
time Version should be needed in an INI is if you are
distributing a custom INI designed to render a piece of
"legacy" POV code, and even then, it would normally be
unneeded, since you could always use #version in the code
itself more effectively. 

Anyway, just thought I'd mention it in case anyone else
sees a similar problem. The solution is just to add the
"Version=3.1" back to your INI file. It's weird, but not
a show stopper. 

Charles

Post a reply to this message

Thorsten Froehlich wrote:
> > ...won't change this behaviour even though setting...
> >
> > "#version official 3.1;"
> 
> You should be able to continue to use the "#version 3.1;" for backward
> compatibility with the official 3.1 parser.

Yup, that also works. I was just keeping in the spirit of the
new syntax in the MegaPOV docs <g>. 

> It still sets itself to 3.1, so this is either a bug (or a precision
> problem).

The only way I can reliably reproduce the behaviour is to yank 
"Version=3.1" from my INI file, and since I would think the parser
would naturally assume version 3.1 until told otherwise, I'm
inclined to agree its a bug. A very very tiny one with an easy
workaround though, so I'm just observing, not complaining.

Charles

Post a reply to this message

In article <3896214F.9BBB720D@enter.net> , Charles Fusner 
<cfu### [at] enternet>  wrote:

>> It still sets itself to 3.1, so this is either a bug (or a precision
>> problem).
>
> The only way I can reliably reproduce the behaviour is to yank
> "Version=3.1" from my INI file, and since I would think the parser
> would naturally assume version 3.1 until told otherwise, I'm
> inclined to agree its a bug. A very very tiny one with an easy
> workaround though, so I'm just observing, not complaining.

The parser sets 3.1 but sometimes precision comes in the way and a compiler
stores (= presets) 3.1 as 3.09999999.  The code correctly initialises to 3.1
so that is the likely cause as this has also been a problem with certain
compiler settings for the official 3.1, at least on Macs.


       Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> New in this version:
>   *Chris Huff's blob pattern, proximity pattern, evaluate pigment/pattern, noise3d.

Days when new pov versions arrive are like Christmas :)

I have used noise3d, however, in 0.3.  Was there some kind of change to this function?

Post a reply to this message

In article <3897068A.7984E169@my-dejanews.com>, 
gre### [at] my-dejanewscom wrote:

> I have used noise3d, however, in 0.3.  Was there some kind of change to 
> this function?

I wrote a patch which allows it to be used in normal POV-Ray script, 
instead of only in isosurface functions.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Sander <san### [at] stolscom> wrote...
> Maybe I forget something, but the 'reset-children' feature doesn't work
even
> after adding the #version etc. line. What do I do wrong??

What does 'not work' mean?  Do you get a #version-related error message, or
does it parse and then not function.

-Nathan

Post a reply to this message

Charles Fusner <cfu### [at] enternet> wrote...
> While I'm on the subject, I'll mention here for the benefit of
> anyone else who doesn't bother putting Version=3.1 in their INI
> files (like me, duh!), if you don't tell MegaPOV anything going
> in, it apparently automatically sets itself for version 3.00 which
> of course kills the #macro directive.

The default should be 3.1.  Do you have Version=3.0 in an ini file
somewhere?  Otherwise, it might be a round-off error.

> For some reason, setting ...
>
> #version unofficial MegaPov 0.4;"
>
> ...won't change this behaviour even though setting...
>
> "#version official 3.1;"

Just "#version 3.1;" will work.  The word "official" will disable the
unofficial features, but if you don't use the word "official", then the
unofficial features will remain activated.

-Nathan

Post a reply to this message