Hi(gh)!

I re-organized my POVigma project the way that distribution of floor 
tiles, non-Oxyd stones (and later on also switches and doors), Oxyd 
stones and other items are stored in ASCII "maps", such as:

1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,9,6,6,6,6,6,6,6,6,10,1,1,
1,1,1,1,1,1,1,1,6,6,6,6,6,6,6,6,6,6,1,1,
1,1,9,6,10,1,1,1,6,6,6,6,6,6,6,6,6,6,1,1,
1,1,6,6,6,3,1,2,6,6,6,6,6,6,6,6,6,6,1,1,
1,1,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,1,1,
1,1,6,6,6,4,1,5,6,6,6,6,6,6,6,6,6,6,1,1,
1,1,8,6,7,1,1,1,6,6,6,6,6,6,6,6,6,6,1,1,
1,1,1,1,1,1,1,1,6,6,6,6,6,6,6,6,6,6,1,1,
1,1,1,1,1,1,1,1,8,6,6,6,6,6,6,6,6,7,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1

(Layer 1: floor tiles)

with meaning of the numbers as follows:

POVIGMA LEVEL LAYER 1 DOCUMENTATION: FLOOR TILES

Code  |  Description 
          |  Friction
-----------------------------------------------------------------------------------------------
    0  | Black void, ball falls endlessly, life is lost
    1  | Grass floor
    2  | Grass/Light Grass floor, with Grass in quarter-circle centered 
at SW
    3  | Grass/Light Grass floor, with Grass in quarter-circle centered 
at SE
    4  | Grass/Light Grass floor, with Grass in quarter-circle centered 
at NE
    5  | Grass/Light Grass floor, with Grass in quarter-circle centered 
at NW
    6  | Light Grass floor
    7  | Light Grass/Grass floor, with Light Grass in quarter-circle 
centered at SW
    8  | Light Grass/Grass floor, with Light Grass in quarter-circle 
centered at SE
    9  | Light Grass/Grass floor, with Light Grass in quarter-circle 
centered at NE
   10  | Light Grass/Grass soil, with Light Grass in quarter-circle 
centered at NW

(friction to be added later on)

same with stones:

1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1

(Layer 2: stones, doors, switches)

Code explanation:

POVIGMA LEVEL LAYER 2 DOCUMENTATION: STONES, DOORS, SWITCHES

Code  |  Description 

-----------------------------------------------------------------------------------------------
    0  | none
    1  | grey marble, brass roof

and with Oxyd stones:

0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,21,0,0,0,0,0,0,20,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,20,0,0,0,0,0,0,21,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

(Layer 3: Oxyd stones)

Code explanation:

POVIGMA LEVEL LAYER 3 DOCUMENTATION: OXYD STONES

Code  |  Description 

-----------------------------------------------------------------------------------------------
    0  | none
   20  | grey marble, blue white-finned roofs, not hit or covered again 
because of mismatch, +0: blue symbol
   21  | +1: red symbol
   22  | +2: green symbol
   23  | +3: yellow symbol
   24  | +4: magenta symbol
   25  | +5: cyan symbol
   26  | +6: white symbol
   27  | +7: black symbol
   30  | +10: hit, uncovered but not yet matched (blinking question 
mark), symbol codes accordingly
   40  | +20: hit, uncovered and matched, symbol codes accordingly

These "maps" are read from disk when parsing each frame and, if any 
changes occur, are written back to disk afterwards.

Furthermore, the current direction of the ball's movement (degrees), its 
speed (POV units/frame) and the clock value at the last change of these 
two values are also stored in an ASCII file.

The rendering of the static scene works fine, but...

...I obviously just can't get right the logic conditions for collision 
detection!

Here is what I cooked up until now:

#declare rows=0; // check for collision with any stone
#while (rows < LevelLength)
   #declare cols=0;
   #while (cols < LevelWidth)
     #warning concat("row: ", str(rows, 1, 0), ", col: ", str (cols, 1, 0))
     #if (layer2_array[rows][cols] = 1 | layer3_array[rows][cols] >= 20)
       #declare xmin=cols-0.35;
       #declare xmax=cols+1+0.35;
       #declare zmin=rows-0.35;
       #declare zmax=rows+1+0.35;
       #if (ballpos_next.x > xmin & ballpos_next.x < xmax & 
ballpos_next.z > zmin & ballpos_next.z < zmax)
         #declare dir = 360-dir;
	#declare hit=1;
	#break
       #end
       /* #if ( < zmax & (ballpos.x <= xmin | ballpos.x >= xmax))
         #declare dir = 180-dir;
	#declare hit=1;
	#break
       #end */
     #end
     #declare cols=cols+1;
   #end
   #if (hit)
     #break
   #end
   #declare rows=rows+1;
#end

Each stone (Oxyd or non-Oxyd) essentially is a box of 1 by 1 by 1 units 
defined with its lower left front corner at the origin.

Attached is the basic layout of the scene (lower left corner: <0, 0, 0>, 
upper right corner: <20, 1, 13>), and when I start animating the ball at 
a speed of 0.1 and starting angle of 60 degrees, first all goes fine, 
the ball is reflected from the northwestern Oxyd stone (those with the 
blue pyramidal roofs) and then heads towards the northern stone wall - 
but shortly before it hits, a strange thing happens: the ball starts 
moving parallel to the z axis and goes right through the wall rather 
than being reflected!

What did I wrong? Do I have to post all include files such as pigments, 
finishes, textures and objects for you to understand (and perhaps solve) 
my problem?

See you in Khyberspace!

Yadgar

Post a reply to this message

Attachments:
Download '2015-08-27 povigma level 1, take 7.jpg' (193 KB)

Preview of image '2015-08-27 povigma level 1, take 7.jpg'

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 27/08/2015 21:45, "Jörg \"Yadgar\" Bleimann" a écrit :
> #if (ballpos_next.x > xmin & ballpos_next.x < xmax & ballpos_next.z
> > zmin & ballpos_next.z < zmax) #declare dir = 360-dir; #declare
> hit=1;

* that's seems to detect a pinball's hit: ball hitting a nail on its
center.

* 360-dir is not the opposite direction.

hitting a bumber to get the opposite direction: dir = (dir+180)%360

You should detect walls' hit, and there is horizontal walls and
vertical walls. Both are harder to handle with a single dir variable.

Horizontal wall, reflecting the vertical component.
Vertical wall, reflecting the horizontal component.

Assuming 0 is North, 180 is South, 90 is East.

Horizontal wall: 0->180, 180->0, 90->90, 270->270, 30->150, 80->100

Vertical wall: 0->0, 180->180, 90->270, 270->90, 30->330, 80->280



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlXgkFAACgkQhKAm8mTpkW3rVwQA2xzfj0wn+y9SZH5esqtsx2Nj
Ers/qjqcM1z8Qqos8sD1Bso/a0WFCw8zWiUlmKmp1NzIrOrk9QmPOhd3Q5PSz8WM
+mza/TTofD6I84W4ktgOGcjOxs+er98vSOPM4NGBNLvns9d7yKdIyxhgRyjprKO2
MmCxvKDxsX61PqWZz1Q=
=kJMo
-----END PGP SIGNATURE-----

Post a reply to this message

Hi(gh)!

> You should detect walls' hit, and there is horizontal walls and
> vertical walls. Both are harder to handle with a single dir variable.
>
> Horizontal wall, reflecting the vertical component.
> Vertical wall, reflecting the horizontal component.
>
> Assuming 0 is North, 180 is South, 90 is East.
>
> Horizontal wall: 0->180, 180->0, 90->90, 270->270, 30->150, 80->100

which would yield the formula; dir = 180-dir

> Vertical wall: 0->0, 180->180, 90->270, 270->90, 30->330, 80->280

equalling dir = 360-dir - or just dir = -dir

Meanwhile I found out that my conditions left out the (rare) case that 
the z coordinate of the ball's position in the last frame before 
"entering" a stone is equal to that of the stone's southern face... I 
fixed this (and also re-activated the branch for the vertical walls) and 
now it runs fine (see attached video)!

Thank you for motivating me!

See you in Khyberspace!

Yadgar

Post a reply to this message

Attachments:
Download 'povigma_level0001_ballview_0-1_60b.mp4.mpg' (1109 KB)

Hi(gh)!

And I thought I got it right... forget about it! While with speed=0.1 
and starting angle=60 degrees all went fine, with speed=0.25 and 
starting angle=340 degrees, at frame 219 the script starts to behave 
bizarrely. As you can see in the attached video clip, the ball bounces 
off a non-existing "horizontal" wall and then moves through the eastern 
wall...

This is the collision detecting routine:

#declare rows=0; // check for collision with any stone
#while (rows < LevelLength)
   #declare cols=0;
   #while (cols < LevelWidth)
     // #warning concat("row: ", str(rows, 1, 0), ", col: ", str (cols, 
1, 0))
     #if (layer2_array[rows][cols] = 1 | layer3_array[rows][cols] >= 20)
       #declare xmin=cols-0.35;
       #declare xmax=cols+1+0.35;
       #declare zmin=rows-0.35;
       #declare zmax=rows+1+0.35;
       // horizontal obstacles
       #if (ballpos_next.x >= xmin & ballpos_next.x <= xmax & 
ballpos_next.z >= zmin & ballpos_next.z <= zmax & (ballpos.z < zmin | 
ballpos.z > zmax))
         #declare dir = 180-dir;
	#declare hit=1;
	#break
       #end
       // vertical obstacles
       #if (ballpos_next.x >= xmin & ballpos_next.x <= xmax & 
ballpos_next.z >= zmin & ballpos_next.z <= zmax & (ballpos.x < xmin | 
ballpos.x > xmax))
         #declare dir = -dir;
	#declare hit=1;
	#break
       #end
     #end
     #declare cols=cols+1;
   #end
   #if (hit)
     #break
   #end
   #declare rows=rows+1;
#end

These are the values at frame 219:

xmin = 18.65
xmax = 20.35
zmin = 3.65
zmax = 5.35

ballpos = <18.6344,0,4.38568> 	
ballpos_next = <18.7199,0,4.15076>

Now let's check both #if conditions:

Horizontal ("west-east") obstacles:
#if (ballpos_next.x >= xmin & ballpos_next.x <= xmax & ballpos_next.z 
 >= zmin & ballpos_next.z <= zmax & (ballpos.z < zmin | ballpos.z > zmax))

ballpos_next.x >= xmin TRUE
ballpos_next.x <= xmax TRUE
ballpos_next.z >= zmin TRUE
ballpos_next.z <= zmax TRUE
ballpos.z < zmin FALSE
ballpos.z > zmax FALSE

...so the following block should NOT be executed! But in fact it does! 
Why? WHY?? WHY??? Am I too feeble-minded to understand this?!?

See you in Khyberspace!

Yadgar

Post a reply to this message

Attachments:
Download 'povigma_level0001_topview_0-25_340_newtexture.mp4.mpg' (1040 KB)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 29/08/2015 18:02, "Jörg \"Yadgar\" Bleimann" a écrit :
> Hi(gh)!
> 
> And I thought I got it right... forget about it! While with
> speed=0.1 and starting angle=60 degrees all went fine, with
> speed=0.25 and starting angle=340 degrees, at frame 219 the script
> starts to behave bizarrely. As you can see in the attached video
> clip, the ball bounces off a non-existing "horizontal" wall and
> then moves through the eastern wall...
> 
> This is the collision detecting routine:
> 
> #declare rows=0; // check for collision with any stone #while (rows
> < LevelLength) #declare cols=0; #while (cols < LevelWidth) //
> #warning concat("row: ", str(rows, 1, 0), ", col: ", str (cols, 1,
> 0)) #if (layer2_array[rows][cols] = 1 | layer3_array[rows][cols] >=
> 20) #declare xmin=cols-0.35; #declare xmax=cols+1+0.35; #declare
> zmin=rows-0.35; #declare zmax=rows+1+0.35; // horizontal obstacles 
> #if (ballpos_next.x >= xmin & ballpos_next.x <= xmax & 
> ballpos_next.z >= zmin & ballpos_next.z <= zmax & (ballpos.z < zmin
> | ballpos.z > zmax)) #declare dir = 180-dir; #declare hit=1; 
> #break #end // vertical obstacles #if (ballpos_next.x >= xmin &
> ballpos_next.x <= xmax & ballpos_next.z >= zmin & ballpos_next.z <=
> zmax & (ballpos.x < xmin | ballpos.x > xmax)) #declare dir = -dir; 
> #declare hit=1; #break #end #end #declare cols=cols+1; #end #if
> (hit) #break #end #declare rows=rows+1; #end
> 
> These are the values at frame 219:
> 
> xmin = 18.65 xmax = 20.35 zmin = 3.65 zmax = 5.35
> 
> ballpos = <18.6344,0,4.38568> ballpos_next = <18.7199,0,4.15076>
> 
> Now let's check both #if conditions:
> 
> Horizontal ("west-east") obstacles: #if (ballpos_next.x >= xmin &
> ballpos_next.x <= xmax & ballpos_next.z >= zmin & ballpos_next.z <=
> zmax & (ballpos.z < zmin | ballpos.z > zmax))
> 
> ballpos_next.x >= xmin TRUE ballpos_next.x <= xmax TRUE 
> ballpos_next.z >= zmin TRUE ballpos_next.z <= zmax TRUE ballpos.z <
> zmin FALSE ballpos.z > zmax FALSE
> 
> ...so the following block should NOT be executed! But in fact it
> does! Why? WHY?? WHY??? Am I too feeble-minded to understand
> this?!?
> 

Rewrite the loop to avoid #break, using #else instead... might help.

> See you in Khyberspace!
> 
> Yadgar

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlXh7C4ACgkQhKAm8mTpkW3rLQQArvsbl6tEbbwHuUmAkSYFiZKH
eSDZ6jSnFX78/0bQATUr4TYfxyFVDzzxNtQnBKwPtGAVZJI+sxYDTvvdex/uHJcg
vFsGGY04Cd7A5amvzISQrVvZW3BkraXi0ajwciUPXtSEJC1twTqrkDvE05dcdDE7
GziC13EJRVXzCusPRBs=
=GBOg
-----END PGP SIGNATURE-----

Post a reply to this message

Hi(gh)!

On 29.08.2015 19:30, Le_Forgeron wrote:

> Rewrite the loop to avoid #break, using #else instead... might help.

To be honest, I have no clue how to do this...

See you in Khyberspace!

Yadgar

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 29/08/2015 22:36, "Jörg \"Yadgar\" Bleimann" a écrit :
> Hi(gh)!
> 
> On 29.08.2015 19:30, Le_Forgeron wrote:
> 
>> Rewrite the loop to avoid #break, using #else instead... might
>> help.
> 
> To be honest, I have no clue how to do this...
> 

You should try harder, because, contrary to C and Java, in povray SDL,
#break does not jump out of a block (or loop).

#break is reserved to #switch, and jump to the next #end. Nothing
less, nothing more. (and given the parser, it's not really a jump,
just ignoring thinks until #end is found).

so, your code is not doing what you think it should do.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlXioKoACgkQhKAm8mTpkW3+YgP+I1BSyi18KT2BHD0+KlTPZYG0
b0w5iSqGFJ5y13mV3Ad7v5IbfIpdZDxhHfLdVEbGznaxqQo25xDi/5EpgFWjTEFr
7+RGcShJguHgk6tZI69JG5gP2fFkizknbXTGMlB6gI3GUcgMhSXbOM4hgDUDCgjx
YgH+OPKUzDv7MVRt/p8=
=Oplz
-----END PGP SIGNATURE-----

Post a reply to this message

Hi(gh)!

On 30.08.2015 08:20, Le_Forgeron wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Le 29/08/2015 22:36, "Jörg \"Yadgar\" Bleimann" a écrit :
>> Hi(gh)!
>>
>> On 29.08.2015 19:30, Le_Forgeron wrote:
>>
>>> Rewrite the loop to avoid #break, using #else instead... might
>>> help.
>>
>> To be honest, I have no clue how to do this...
>>
>
> You should try harder, because, contrary to C and Java, in povray SDL,
> #break does not jump out of a block (or loop).
>
> #break is reserved to #switch, and jump to the next #end. Nothing
> less, nothing more. (and given the parser, it's not really a jump,
> just ignoring thinks until #end is found).

And I already wondered why there is no #continue in POV-Ray...
>
> so, your code is not doing what you think it should do.

Instead, I now simply set cols and rows to LevelWidth and LevelLength 
respectively after a detected collision, so that the nested loops both 
come to an end...

...now the ball at least does not go through the wall anymore - but 
instead, it is reflected in a somewhat strange way off the eastern and 
southern bordering wall - see attachment!

This is not entirely absurd, as the border stones are beveled at the 
corners, unlike the Oxyd stones - but the bevel angle is 45°, and the 
ball hits always at angles which are not multiples of 45°, so it can not 
be reflected this way...

Then I combined this with an #else solution:

#declare rows=0; // check for collision with any stone
#while (rows < LevelLength)
   #declare cols=0;
   #while (cols < LevelWidth)
     // #warning concat("row: ", str(rows, 1, 0), ", col: ", str (cols, 
1, 0))
     #if (layer2_array[rows][cols] = 1 | layer3_array[rows][cols] >= 20)
       #declare xmin=cols-0.35;
       #declare xmax=cols+1+0.35;
       #declare zmin=rows-0.35;
       #declare zmax=rows+1+0.35;
       // horizontal obstacles
       #if (ballpos_next.x >= xmin & ballpos_next.x <= xmax & 
ballpos_next.z >= zmin & ballpos_next.z <= zmax & (ballpos.z < zmin | 
ballpos.z > zmax))
         #declare dir = 180-dir;
	#declare hit=1;
	#declare cols=LevelWidth;
	#declare rows=LevelLength; // loop is aborted
       #else
	#if (ballpos_next.x >= xmin & ballpos_next.x <= xmax & ballpos_next.z 
 >= zmin & ballpos_next.z <= zmax & (ballpos.x < xmin | ballpos.x > xmax))
	  #declare dir = -dir;
	  #declare hit=1;
	  #declare cols=LevelWidth;
	  #declare rows=LevelLength; // loop is aborted
	#end
       #end
     #end
     #declare cols=cols+1;
   #end
   #declare rows=rows+1;
#end

...and it is the same like before!!! (see second attachment)

I hardly have words anymore for this... it's so frustrating... so 
endlessly frustrating... perhaps I should give up POV-Ray and 
programming in general completely and content myself with watching TV! 
Obviously my mind is too weak to tackle with the tasks of programming...

See you in my trailer park!

Yadgar

Post a reply to this message

Hi(gh)!

On 30.08.2015 08:20, Le_Forgeron wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Le 29/08/2015 22:36, "Jörg \"Yadgar\" Bleimann" a écrit :
>> Hi(gh)!
>>
>> On 29.08.2015 19:30, Le_Forgeron wrote:
>>
>>> Rewrite the loop to avoid #break, using #else instead... might
>>> help.
>>
>> To be honest, I have no clue how to do this...
>>
>
> You should try harder, because, contrary to C and Java, in povray SDL,
> #break does not jump out of a block (or loop).
>
> #break is reserved to #switch, and jump to the next #end. Nothing
> less, nothing more. (and given the parser, it's not really a jump,
> just ignoring thinks until #end is found).
>
> so, your code is not doing what you think it should do.


And I already wondered why there is no #continue in POV-Ray...
 >
 > so, your code is not doing what you think it should do.

Instead, I now simply set cols and rows to LevelWidth and LevelLength 
respectively after a detected collision, so that the nested loops both 
come to an end...

...now the ball at least does not go through the wall anymore - but 
instead, it is reflected in a somewhat strange way off the eastern and 
southern bordering wall - see attachment!

This is not entirely absurd, as the border stones are beveled at the 
corners, unlike the Oxyd stones - but the bevel angle is 45°, and the 
ball hits always at angles which are not multiples of 45°, so it can not 
be reflected this way...

Then I combined this with an #else solution:

#declare rows=0; // check for collision with any stone
#while (rows < LevelLength)
   #declare cols=0;
   #while (cols < LevelWidth)
     // #warning concat("row: ", str(rows, 1, 0), ", col: ", str (cols, 
1, 0))
     #if (layer2_array[rows][cols] = 1 | layer3_array[rows][cols] >= 20)
       #declare xmin=cols-0.35;
       #declare xmax=cols+1+0.35;
       #declare zmin=rows-0.35;
       #declare zmax=rows+1+0.35;
       // horizontal obstacles
       #if (ballpos_next.x >= xmin & ballpos_next.x <= xmax & 
ballpos_next.z >= zmin & ballpos_next.z <= zmax & (ballpos.z < zmin | 
ballpos.z > zmax))
         #declare dir = 180-dir;
     #declare hit=1;
     #declare cols=LevelWidth;
     #declare rows=LevelLength; // loop is aborted
       #else
     #if (ballpos_next.x >= xmin & ballpos_next.x <= xmax & 
ballpos_next.z >= zmin & ballpos_next.z <= zmax & (ballpos.x < xmin | 
ballpos.x > xmax))
       #declare dir = -dir;
       #declare hit=1;
       #declare cols=LevelWidth;
       #declare rows=LevelLength; // loop is aborted
     #end
       #end
     #end
     #declare cols=cols+1;
   #end
   #declare rows=rows+1;
#end

...and it is the same like before!!! (see second attachment)

I hardly have words anymore for this... it's so frustrating... so 
endlessly frustrating... it only HURTS! Perhaps I should give up POV-Ray 
and programming in general completely and content myself with watching 
TV! Obviously my mind is too weak to tackle with the tasks of programming...

See you in some redneck trailer park!

Yadgar

Post a reply to this message

Attachments:
Download 'povigma_level0001_ballview_0-1_60c.mp4.mpg' (506 KB) Download 'povigma_level0001_ballview_0-1_60d.mp4.mpg' (501 KB)

Am 30.08.2015 um 08:20 schrieb Le_Forgeron:
> Le 29/08/2015 22:36, "Jörg \"Yadgar\" Bleimann" a écrit :
>> Hi(gh)!
> 
>> On 29.08.2015 19:30, Le_Forgeron wrote:
> 
>>> Rewrite the loop to avoid #break, using #else instead... might
>>> help.
> 
>> To be honest, I have no clue how to do this...
> 
> 
> You should try harder, because, contrary to C and Java, in povray SDL,
> #break does not jump out of a block (or loop).
> 
> #break is reserved to #switch, and jump to the next #end. Nothing
> less, nothing more. (and given the parser, it's not really a jump,
> just ignoring thinks until #end is found).
> 
> so, your code is not doing what you think it should do.

Your information about the #break statement is outdated since 2010-04-18 ;-)

As of Perforce change 4942 (included in 3.7.beta.37 and later), you can
also use #break in any #while, #loop or #macro block to leave the
respective construct early.

Post a reply to this message