|
 |
On Sun, 24 Nov 2002 14:40:58 GMT, mca### [at] aol comcom (Stephen McAvoy)
wrote:
>In Basic I would use a "goto" or "gosub" statement, but
>the SDL does not have labels or line numbers, as far as I can see.
>Using macros seems very heavy handed and inelegant. No offence meant.
So the BASIC way, which is virtually the BASIC-only way, is more
elegant that what 95% of the rest of the languages use (that is,
function calls with parameters and return values)? Sorry, beats me.
You can pass parameters to a macro, it can return a value - what else
do you need? The reason it is not a function is that it can do stuff
only a macro can do, and it is executed at parse time, not at render
time - other than that, it's a good as function (or sub, if you like)
as any. Just read the docs more carefully to learn how to use it.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
|
|
On Sun, 24 Nov 2002 14:40:58 GMT, mca### [at] aolcomcom (Stephen McAvoy) wrote:
> In Basic I would use a "goto" or "gosub" statement...
BASIC | SDL
---------------------------|--------------------------------------
10 INPUT P | #declare P=Input();
20 IF P="A" GOTO NOT_C | #if(ctrcmp(P,"A")<>0)
30 INPUT C | #declare C=Input();
40 IF C="N" GOTO NOT_Z | #if(ctrcmp(P,"N")<>0)
50 INPUT Z | #declare Z=Input();
60 PRINT Z | #debug Z
70 LABEL NOT_Z | #end
80 PRINT C | #debug C
90 LABEL NOT_C | #end
100 PRINT P | #debug P
---------------------------|--------------------------------------
|
| #macro Print_A()
| #debug "A was input"
| #end
|
10 INPUT P | #declare P=Input();
20 IF P="A" GOSUB PRINT_A | #if(ctrcmp(P,"A")0) Print_A() #end
30 PRINT "Happy End" | #debug "Happy End"
40 EXIT |
50 LABEL PRINT_A |
60 PRINT "A was input" |
70 RETURN |
|
Note 1: Input() is some macro to get value from somewhere. Just wrapper for
some abstract operation.
Note 2: strcmp() is macro to compare strings, check documentation for details
Note 3: If you do not know how to replace "goto" with conditions or something
then you really should ask in newuser group. You can be master in
texturing and very experienced in modelling, but as long as you are
asking for things not explored earlier you should really ask there.
That's not shame. Other advanced users usually reads both groups.
It can result in some order of knowledge. Some other newusers would
faster find answer reading that group.
Note 4: Sorry if my Basic or SDL is not accurate in some place but I mostly
use C recently
ABX
Post a reply to this message
|
|
|
|
On Sun, 24 Nov 2002 20:33:45 GMT, mca### [at] aolcomcom (Stephen McAvoy)
wrote:
>Unless someone can help me with my problem I suggest we close this
>thread and go off topic with any other comments. Remember it costs
>nothing to be polite.
Stephen, please accept my apologies if my answer sounded rude, it was
not intended so. Hey, I also started with BASIC (on the Apple II, at
that) :)
Considering that you seem to only be familiar with a non-structural
language, it might be hard to grasp a new concept in the beginning,
but trust me, it's a piece of cake once you get the basics (pun
intended :) ).
In POV, you have the following flow control statements (square
brackets indicate optional parts):
#if (expression)
statement(s)1
[#else
statement(s)2
#end
If the expression evaluates to non-zero or true, then the
statement(s)1 block is parsed. Note that the expression can be boolean
(for example, (a<10) ) or arithmetic ( for example, mod(a,2)). In POV,
0 is always equivalent to false, and non-zero is true. A boolean
expression that evaluates to true also has an arithmetic value of 1.
So in the above example, statement(s)1 will be executed if expression
evaluates to non-zero (true). If you have the #else block,
statement(s)2 will be executed if expression evaluates to 0 (false).
Next come the #switch statement:
#switch (expression)
#case (value1)
statement(s)1
#break
#case (value2)
statement(s)2
#break
...
#range (start_of_range, end_of_range)
statement(s)3
#break
#else
statement(s)4
#end
In this example, (expression) is evaluated and tested against specific
values and ranges of values (the latter only works for numbers, I
think). It is parsed top-to-bottom, as usual. If a value matches, the
block until the #break is parsed, and flow then continues after the
#end token. If none of the checks matches, the #else block is
executed. You can have as many #case and #range blocks as you want,
and up to one #else block.
Then comes the loop control. It is achieved by the #while directive,
like this:
#declare Counter = 0;
#while (Counter < 100)
statement(s)
#declare Counter = Counter + 1;
#end
The above example is similar to the BASIC for Counter = 0 to 100 step
1. The difference is that using #while, the loop may not be executed
at all (for example, if Counter is 1000 in the beginning, it won't
enter the loop at all, as the expression (Counter<100) will not
match).
Last, the #macro directive:
#macro MyMacro (param1, param2)
statement(s)
#end
Simple, eh? Well, it is, but it's also very powerful.
Parameters are optional, so you can have a macro like this:
#macro DefaultCamera ()
camera {
location <0,2,-5>
look_at 0
}
#end
Parameters are identifiers accessible only within the macro. Global
identifiers (objects, textures, variables, you name it) are also
accessible within the macro. In case of a name collision, parameters
take precedence.
Here's an example how to use parameters:
#macro Ball (Position)
sphere { Position, 1 }
#end
Then you can invoke it like this:
object { Ball(<0,10,0>) pigment { Red } }
What happens is that the text in the body of the macro is "pasted" at
the invocation point with the parameters replaced by the values that
you pass. This is significantly different from the way a function
works in C or similar languages, but the result is similar.
Anyway, there's a whole lot one can say on the subject, but it's
already very well documented in the manual. I suggest you go through
the relevant manual sections and tutorials again and practice bit by
bit until you get a hang of it.
Hope this helps. If not, you can give some more info about your
specific problem and will probably get a solution here, but you won't
learn as much as you would if you tackled it yourself.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
