Le 21/02/2021 à 15:10, William F Pokorny a écrit :
> On 2/21/21 6:03 AM, Le_Forgeron wrote:
>> Le 19/02/2021 à 00:32, Bald Eagle a écrit :
>>>> Do you have some commercials for povr ?
>>>> I mean some catalog of all the features that povr has ?
>>> I think that may mean "You should consider doing an hgpovray38 version."
>>> Which, I think, is an excellent idea. :D
>> The catalog for hgpovray38 is in the wiki.
>> (as well as illustrated in the distribution, but that's only after
>> download, so not a real advertisement)
>> I'm lacking such information about povr.
> As am I currently for any concise form for the whole.
> I'm struggling with how to document. I have no plans to continue to use
> the wiki though a chunk of my early documentation is there, if you look.
> The wiki method is too slow to use and not under code control.
I tried to use the github wiki (separate repository, tied to the
project), but it was painful (especially with dual repository in github
& bitbucket). So I returned to povray.wiki.
If you like documentation in code control, there is the md files which
could be used (but focus on supported features by github, forget fancy
options). Everything starts at README.md,
> The povr branch is based off of v3.8, but it's absolutely a break from
> strong backward compatibility. Mostly, this is because it's all I can
> manage - but I also think it's necessary to fix many of the long
> standing issues! There are hundreds of fixes little and large in povr. I
> think too often today's documented features are not really working as
> they should! Is adding many new features on such a base the best
> immediate path forward?
Stalled fixing, or adding needed stuff, large dilemma.
I answered for myself when CLipka starts rewriting a lot of the code and
moved files. One cook in the kitchen is enough.
> Aside: I'm only four years getting into c++ when it takes 10 to be
> really good at anything. I'd probably be much further along if I'd long
> been a c++ programmer. As a language c++ is nothing if not a huge
> mountain to climb all by itself... :-( Let alone all our own classes and
> template classes.)
Beware, CLipka (I believe) was applying Misra/Autosar C++ coding rules,
a fully painful set of constraints, on the rewrite of the old C object
oriented code (from the very old code in 3.1). It is more than just C++.
> Anyway. Me rambling. The povr branch is my strong push toward what I
> think 'POV-Ray' should be in the future, but there is no doubt, it's
> more than I can handle in any short term time frame.
> FYI. I'm away from my computer for the next few days.
> Bill P.
Post a reply to this message