Am 17.11.2016 um 00:20 schrieb [GDS|Entropy]:

> One bit of irritation I have with arrays is that you cant do this:
> 
> #declare myArray = array[foo][bar];
> 
> // loop
> #local etc = myArray[iterator];
> 
> And similar with assignment.
> 
> I ended up making a 1d array of 1d arrays. Its just more code to do pretty
> much the same thing, and isn't really intuitive to those used to and coming
> from other languages.
> 
> I think some concessions to the way many of the popular languages work,
> like JS, Java and C# would be beneficial, with regard to array behavior.

I agree; but we have to make concessions between what would be nice to
have, and what we can bolt on to the existing parser architecture. Since
I have no immediate idea how to tackle this one, and there are usually
ways to work around the issue, I don't think it should have high priority.


> I also noticed that I cannot do the following:
> Short-circuit conditional ops (shocked me)

Short-circuit conditional ops (I presume you mean the `?:` ternary
operator) are nice-to-have sugar, but probably difficult to implement,
with the parser being as convoluted as it is; moreover, `#if ... #else
... #end` already provide a workaround if sort-circuit operation is
really necessary.

What bothers me much more is that we don't have a short-circuit `select`
statement, at least in user-defined functions, as that is an actual
factor in render performance of certain isosurfaces. But I prefer not to
touch the current VM, and instead wait for it to be replaced with a new one.

> Unary modification and assignment (+= and so forth)

Purely syntactic sugar. Should be reasonably easy to implement, but
isn't high on my personal agenda.


> It would be very cool if, as part of the refactor toward modularization,
> that the SDL were abstracted and facaded from the engine, so that ANY SDL
> which meets the required interface specification could then be used, which
> would likely simplify inclusion of Pov as a 3rd party rendering option.
> Frankly you could leave the internal SDL coding and just facade
> that...though that would be less ideal from an architectural standpoint
> than a purpose built generic DSL interpreter, but also far less work and so
> maybe a good "phase 1" go of it.

My goal is to introduce a clean conceptual separation between the render
engine and the parser, so that the parser (typically along with the
front-end) could be replaced by something else entirely. Which means
that there's still a lot of stuff to be moved from the parser to the
render engine (most notably object initialization and certain
post-parse/pre-render processing steps).

Bolting another layer on top of the parser? No, thanks.


> I had once tried to hook into Pov so that I could invoke the render and
> host the output in a C# app picturebox, but I never figured out how. Moray
> does it so it is obviously possible, but I don't know how much of a hack
> their method was or if there is some actual API for this.

POV-Ray for Windows does provide a GUI plug-in API, which to my
knowledge is how Moray interfaces to POV-Ray. I have never had a closer
look at the interface though -- my guess is that it is not much more
than a way for the plug-in to initiate a render of a POV or INI file.

Post a reply to this message