|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So, clearly the flow control in this other language is different than SDL,
I have a while (1) with an #if, and then other little nested bits like:
#if (A >= 0)
#for (m, 0, 3)
#if (tris[A][m]=R){
#local tris[A][m]=L;
#break;
#end
#end
#end
I'm assuming some, or all of those #break statements are meant to exit the
#while(1), but of course, they don't, and so I'm stuck in the dreaded infinite
loop.
Please advise.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, clearly the flow control in this other language is different than SDL,
>
> I have a while (1) with an #if, and then other little nested bits like:
>
> #if (A >= 0)
> #for (m, 0, 3)
> #if (tris[A][m]=R){
> #local tris[A][m]=L;
> #break;
> #end
> #end
> #end
>
> I'm assuming some, or all of those #break statements are meant to exit the
> #while(1), but of course, they don't, and so I'm stuck in the dreaded infinite
> loop.
>
> Please advise.
I recommend that you do not use break in loops.
I've not yet seen a case where it cannot be avoided.
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> I recommend that you do not use break in loops.
> I've not yet seen a case where it cannot be avoided.
Indeed.
I've had several of the problems spontaneously resolve, and then ... spawn new
problems.
The new problems (and likely the old) are (were) a result of the values for nT
and j not working well with the arrays and/or flow control conditions.
I don't mind translating code from other languages (though pointers, operator
overloading, and things like "==>" are a pain) but translating crappily written
code is a real PITA, esp in SDL where we have limited visualization and
debugging tools, and no error trapping - coupled with the text buffer overflow
problem.
I was hoping to reach then end of the macro, so I could at least debug a faulty
result. But now I'm just stuck in an endless loop (again).
I'm setting this aside for now - gotta get some sleep before driving one of the
Death Machines through a warehouse of people.
I'll just post the current "scene" file as it is so far, in case anyone wants to
feast their eyes on the horror.
Post a reply to this message
Attachments:
Download 'delaunaytriangulatetest1.pov.txt' (19 KB)
|
|
| |
| |
|
|
From: Alain Martel
Subject: Re: Break out of main while (1) loop using #break directive in a sub-loop state=
Date: 16 Jan 2023 11:53:43
Message: <63c58117$1@news.povray.org>
|
|
|
| |
| |
|
|
Le 2023-01-15 à 20:05, Bald Eagle a écrit :
> So, clearly the flow control in this other language is different than SDL,
>
> I have a while (1) with an #if, and then other little nested bits like:
>
> #if (A >= 0)
> #for (m, 0, 3)
> #if (tris[A][m]=R){
> #local tris[A][m]=L;
> #break;
> #end
> #end
> #end
>
> I'm assuming some, or all of those #break statements are meant to exit the
> #while(1), but of course, they don't, and so I'm stuck in the dreaded infinite
> loop.
>
> Please advise.
>
As I understand it : At most, that #break would break out of the #for
loop, not the #while containing the #for.
In the present case, it will ONLY end the #for loop early if the
condition is met. The outer #while loop is left unaffected.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> I'm assuming some, or all of those #break statements are meant to exit the
> #while(1), but of course, they don't, and so I'm stuck in the dreaded infinite
> loop.
>
> Please advise.
just to add to AM's advice, use macros where possible, then '#break' can be used
to terminate early.
<https://wiki.povray.org/content/Reference:Conditional_Directives#The_switch.2C_case.2C_range_and_break_Directives>
regards ,jr.
Post a reply to this message
|
|
| |
| |
|
|
From: kurtz le pirate
Subject: Re: Break out of main while (1) loop using #break directive in a sub-loop state=
Date: 16 Jan 2023 12:34:46
Message: <63c58ab6$1@news.povray.org>
|
|
|
| |
| |
|
|
On 16/01/2023 02:05, Bald Eagle wrote:
> So, clearly the flow control in this other language is different than SDL,
>
> I have a while (1) with an #if, and then other little nested bits like:
>
> #if (A >= 0)
> #for (m, 0, 3)
> #if (tris[A][m]=R){
> #local tris[A][m]=L;
> #break;
> #end
> #end
> #end
>
> I'm assuming some, or all of those #break statements are meant to exit the
> #while(1), but of course, they don't, and so I'm stuck in the dreaded infinite
> loop.
>
> Please advise.
>
I agree with Tor Olav. The "break" breaks the logic of the code.
However, we can arrange it with something like :
#declare DoLoop = true;
#while ( (condition) & DoLoop)
...
...
#if ( exit_condition )
#declare DoLoop=false;
#end
#end
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I will agree with everyone - certainly when I first saw that #while (1), my
first reaction was "WHAT.... THE .... ....."
I think that most of the #breaks are just poor coding practice meant to exit the
smaller loops early, not the outer while.
It's certainly interesting to learn more about this "short circuiting" and other
aspects of flow control code. To my knowledge, no one has ever posted any SDL
code that illustrates the detailed behaviour of POV-Ray's SDL condition
evaluation.
One thing that I did run across that is being used in this code, but isn't
natively supported by SDL is the referencing of a 1D "slice" of a 2D array.
"Although it is permissible to reference an entire array as a whole, you may not
reference just one dimension of a multi-dimensional array."
https://wiki.povray.org/content/Reference:Array
So I made a macro as a workaround for that, in case anyone has any need to do
such a thing. Basically, it just takes the array and whatever element of the
first dimension that you want to use and copies that into a smaller "2D" array,
which can then get passed as an argument to a macro.
#macro Reference2DSubarray (Array, Index)
#local Size = dimension_size (Array, 2);
#local Temp = array[1][Size];
#for (i, 0, Size-1)
//#debug concat ("i = ", str (i, 0, 0), "\n")
#local Temp[0][i] = Array[Index][i];
#end
Temp
#end
I'll see if I can do any debugging or high-level perusal of the code and make
any progress - otherwise it might be another lost cause since I have yet to
determine what it actually DOES.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> One thing that I did run across that is being used in this code, but isn't
> natively supported by SDL is the referencing of a 1D "slice" of a 2D array.
>
> "Although it is permissible to reference an entire array as a whole, you may
> not reference just one dimension of a multi-dimensional array."
You can kind-of do this in SDL, but only if you use arrays of arrays instead of
multi-dimensional arrays. So, instead of
#declare A = array[3][2];
use
#declare A = array[3];
#for (I, 0, 2)
#declare A[I] = array[2];
#end
which may or may not be more trouble depending on how you're populating the
arrays. However, it is indexed in exactly the same way - A[I][J] - and you can
indeed reference A[I] as an array[2].
Bill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > One thing that I did run across that is being used in this code, but isn't
> > natively supported by SDL is the referencing of a 1D "slice" of a 2D array.
> >
> > "Although it is permissible to reference an entire array as a whole, you may
> > not reference just one dimension of a multi-dimensional array."
>
> You can kind-of do this in SDL, but only if you use arrays of arrays instead of
> multi-dimensional arrays. So, instead of
>
> #declare A = array[3][2];
>
> use
>
> #declare A = array[3];
> #for (I, 0, 2)
> #declare A[I] = array[2];
> #end
>
> which may or may not be more trouble depending on how you're populating the
> arrays. However, it is indexed in exactly the same way - A[I][J] - and you can
> indeed reference A[I] as an array[2].
>
> Bill
Indeed, I had also thought to do this, but wanted to try the little macro
approach first, and that seemed to work well enough.
I've hacked the living daylights out of the code such that i make it to the end,
but I've hacked enough out that I get no results.
The first place the code goes off the rails is with a negative subscript do to a
reassigning of j. At first I puzzled over how this could possibly be working
code, but given the fact that it's C, I decided to check:
https://www.geeksforgeeks.org/overloading-subscript-or-array-index-operator-in-c/
Positive and Negative subscripts
The first element of an array is stored at index 0. The range of a C++ array is
subscripts. Negative subscripts must fall within array boundaries; if they do
not, the results are unpredictable. The following code shows positive and
negative array subscripts:
// CPP program illustrating the
// positive and negative subscripts
#include <iostream>
using namespace std;
// Driver Method
int main()
{
int intArray[1024];
for (int i = 0, j = 0; i < 1024; i++) {
intArray[i] = j++;
}
// 512
cout << intArray[512] << endl;
// 257
cout << 257 [intArray] << endl;
// pointer to the middle of the array
int* midArray = &intArray[512];
// 256
cout << midArray[-256] << endl;
// unpredictable, may crash
cout << intArray[-256] << endl;
}
Output:
512
257
256
0
So, does that mean that I can just use abs(subscript) as a C-to-SDL hack or ...
?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> >
> > "Although it is permissible to reference an entire array as a whole, you may
> > not reference just one dimension of a multi-dimensional array."
>
> You can kind-of do this in SDL, but only if you use arrays of arrays instead of
> multi-dimensional arrays. So, instead of
>
> #declare A = array[3][2];
>
> use
>
> #declare A = array[3];
> #for (I, 0, 2)
> #declare A[I] = array[2];
> #end
>
That is very clever, and will go into my 'bag of tricks'. Thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|