Ken <tyl### [at] pacbellnet> wrote:

> I seem to recall Chris H. started doing patches not so long ago and with
> little to no C or C++ experience. If Chris can do it so can you.

This is true, when I started patching, my only C experience was from a
C++ course, not even a very good one: "Learn C++ in 21 Days".

Someone, I think it was Michael Paul (who wrote the angle-dependant
reflection patch and maintained WyzPOV) or Ron Parker helped me get
started by explaining how to write a simple pattern patch, from there,
I just worked by looking at existing source code and copying from it.

I wrote a simple tutorial, a draft version of which is in the
povray.binaries.tutorials group, which may be useful, though it is
only for patching the official version...the changes needed to modify
MegaPOV shouldn't be difficult to figure out, though.


-- 
Christopher James Huff - chr### [at] maccom
Home Page: http://homepage.mac.com/chrishuff/
POV-Ray TAG e-mail: chr### [at] povrayorg
POV-Ray TAG web site: http://tag.povray.org/

Post a reply to this message

Thank you for your support Ken! :)

Post a reply to this message

See, I get in, make a messy patch, and then hand it over to other POV
programmers who can clean it up. The idea is to get the ball rolling. :)

Post a reply to this message

> If you start coding the patch from the scratch,
> with no experience at all, you'll probably make things in 50 lines which
> could be made in 5 lines much more efficiently and with a lot less trouble
and
> work.

I plan to finish reading the book for my class before even looking at the
POV-Ray sources. I can compile a one *.C file with a few *.H files in the
mix, but I haven't the foggiest about multiple *.C file programs. I'll get
to it when I feel up to the task. I know I won't make the greatest or most
efficient program, but I'll give it a try at least. My book includes some
excellent examples, including a big (1000+) line program that you work
through chapter by chapter at the end of each. It's for controlling an
elevator. Very interesting problem. Much more complex than it seems at the
beginning. My book also has tons of little tips strewn throughout from a
performance perspective (speed) and a software-engineering perspective
(reusability/portability). I like this book. I trust I'll learn a lot from
it. I respect your opinion, but I think I'll do it my way. OK? :)

Post a reply to this message

Thank you for your support as well! :)

Post a reply to this message

Tony[B] <ben### [at] catholicorg> wrote:
: See, I get in, make a messy patch, and then hand it over to other POV
: programmers who can clean it up. The idea is to get the ball rolling. :)

  And cause a lot more work than necessary?

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

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

> : See, I get in, make a messy patch, and then hand it over to other POV
> : programmers who can clean it up. The idea is to get the ball rolling. :)
>
>   And cause a lot more work than necessary?

It only causes more work if the person supposed to clean it up does not know
about implementation problems or they are not obvious.  If just the same
idea is implemented by writing new code no additional work needs to be done
:-)


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Tony[B] wrote in message <3b11138f@news.povray.org>...
>See, I get in, make a messy patch, and then hand it over to other POV
>programmers who can clean it up. The idea is to get the ball rolling. :)


You mean, like the spline{} patch in MegaPOV?  The code for that is a mess.
Splines are limited to 256 entries, the "cubic splines" are actually an
average of two quadratic splines, none of the code is commented, and in
general, the whole thing needs to be re-written from scratch.

--
Mark

Post a reply to this message

In article <3b11d751$1@news.povray.org> , "Mark Wagner" 
<mar### [at] gtenet> wrote:

> You mean, like the spline{} patch in MegaPOV?  The code for that is a mess.
> Splines are limited to 256 entries, the "cubic splines" are actually an
> average of two quadratic splines, none of the code is commented, and in
> general, the whole thing needs to be re-written from scratch.

A limit of 256 entries?  Good to know, another bug to add to the list - I
guess the original author was not sure how to dynamically grow a block of
memory in C <sigh>


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3b11fcb3@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> A limit of 256 entries?  Good to know, another bug to add to the list - I
> guess the original author was not sure how to dynamically grow a block of
> memory in C <sigh>

It actually looks like it was just not completely implemented...the 
necessary changes were added later by others. I don't recall where the 
changed versions were uploaded, but I thought they were included in the 
last version of MegaPOV.

-- 
Christopher James Huff - chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message