It seems the patch contained in MegaPOV to fix up the behaviour for 
End_Rows applies only to End_Rows, not to the short form of the option, +er.

Let's make it clear by an example.

When I call MegaPOV like this:

./megapov +itest.pov +otest.png +fn +w320 +h240 +sc0.5 +ec1.0 +sr0.5 +er1.0

I get image variant A, an empty image (126 bytes in size). Calling 
MegaPOV like this:

./megapov +itest.pov +otest.png +fn +w320 +h240 +sc0.5 +ec1.0 +sr0.5 
End_Rows1.0

I get image variant B (7170 bytes), which is the desired lower right 
quarter of the image.

Vanilla POV-Ray would render image variant B in both cases (tested with 
self-compiled versions of POV and MegaPOV, on linux). This is what I 
consider the right behaviour.

Now I know very well why the fix was necessary:

./povray +itest.pov +otest.png +fn +w320 +h240 +sr0 +er1

should render the top two lines of the image only, not everything. 
MegaPOV does it right:

./megapov +itest.pov +otest.png +fn +w320 +h240 +sr0 +er1

Here the behaviour of MegaPOV is what I consider to be The Right Thing(tm).

The only reason why this bothers me at all is that feature in the 
Windows GUI version where you can select a rectangle to be rendered with 
the mouse. This feature defines the rectangle coordinates using the 
short form of the options, and with fractional coordinates, not pixels.

It is quite irritating to select something and get nothing.

Correct me if my thoughts are wrong. But if they are right I'd like to 
see this fixed in the next release of MegaPOV (and vanilla POV of course).

-- 
(defun f(p x)(If(Eq x nil)nil(If(p(Car x))(Cons(Car x)(f p(Cdr x)))(f p
(Cdr x)))))(defun q(x)(Q nil x))(defun Q(a x)(If(Eq x nil)a(Q(Cons(Car
x)(Q a(f(Lt(Car x))(Cdr x))))(f(Gt(Car x))(Cdr x)))))

Post a reply to this message