If you have a little bit time and experience at your hand, you can help
me to find my error.

When calling the texture macro directly from another file, it works. But
when calling it from within the parameter liner of another macro, I get
the error message you cans see as comment behind one of the lines. Why?
Why? Why?



--------------------------

#declare MyShipTex = on;
#declare MyRandom  = seed(now*24*60*60);

include "Rand.inc"
include "SL - Woods.inc"







 #macro MyBrownSimpleQuoVadis(MyOrientation)
  #declare MySeeder    = seed(now*24*60*60);
  #declare MyDirection = MyOrientation*<1,2,3>;
  #declare MyAlignment = MyDirection.x+MyDirection.y+MyDirection.z;
  #switch(MyAlignment)
   #case(1)
    texture { MyBrownDarkwood rotate < 00.0, 90.0, 00.0 > rotate < 00.0,
00.0, 00.0 > scale 0.5+rand(MySeeder)*1.5 translate < rand(MySeeder),
rand(MySeeder), rand(MySeeder) > } //  X
    texture { MyBrownSimple } // Parse Error: Expected ")", # found instead

   #break
   #case(2)
    texture { MyBrownDarkwood rotate < 90.0, 00.0, 00.0 > rotate < 00.0,
00.0, 00.0 > scale 0.5+rand(MySeeder)*1.5 translate < rand(MySeeder),
rand(MySeeder), rand(MySeeder) > } // Y
    texture { MyBrownSimple }
   #break
   #case(3)
    texture { MyBrownDarkwood rotate < 00.0, 00.0, 90.0 > rotate < 00.0,
00.0, 00.0 > scale 0.5+rand(MySeeder)*1.5 translate < rand(MySeeder),
rand(MySeeder), rand(MySeeder) > } // Z
    texture { MyBrownSimple }
   #break
  #end
 #end




#macro
PostsSideRailing(MyLength,MyPlankHeight,MyMinimum,MyMaximum,MyIncrease,MyR,
MyT,MyRY,MyX,MyMacroTexture)
// 1.99,0.15,0.55,1.45,0.30,2.5,0.02,0.0,9.90,MyYellowSimple
 union
 {
  #declare MyLevel   = MyMinimum;
  #declare AllLevels = MyMaximum;
  #while(MyLevel<=AllLevels)
   box { <  -MyLength, 0.00, -0.025 > <   MyLength,  MyPlankHeight, 0.00
> MyMacroTexture rotate < 0.0, 0.0, RRand(-MyR,MyR,MyRandom) > rotate <
0.0, MyRY, 0.0 > translate <  0.0, MyLevel+RRand(-MyT,MyT,MyRandom),
-MyX > scale < 1.0, 1.0,  1.0 > }
   box { <  -MyLength, 0.00, -0.025 > <   MyLength,  MyPlankHeight, 0.00
> MyMacroTexture rotate < 0.0, 0.0, RRand(-MyR,MyR,MyRandom) > rotate <
0.0, MyRY, 0.0 > translate <  0.0, MyLevel+RRand(-MyT,MyT,MyRandom),
-MyX > scale < 1.0, 1.0, -1.0 > }
   #declare MyLevel=MyLevel+MyIncrease;
  #end
 }
#end




object {
PostsSideRailing(0.725,0.30,0.60,4.50,0.65,1.5,0.02,-90.0,6.675,MyBrownSimp
leQuoVadis(x))
translate < -20.9, 0.0, 0.0 > }

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

Le 22/04/2018 à 07:47, Sven Littkowski a écrit :
> If you have a little bit time and experience at your hand, you can help
> me to find my error.
> 
> When calling the texture macro directly from another file, it works. But
> when calling it from within the parameter liner of another macro, I get
> the error message you cans see as comment behind one of the lines. Why?
> Why? Why?
> 
> 
> 
> --------------------------
> 
> #declare MyShipTex = on;
> #declare MyRandom  = seed(now*24*60*60);
> 
> include "Rand.inc"
> include "SL - Woods.inc"
> 

I guess the missing # before include are not part of the issue, right ?

Post a reply to this message

No, that's not the problem - I just forgot them inside this demo scene.
The source of the error must be somewhere else.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

Le 22/04/2018 à 07:47, Sven Littkowski a écrit :
> If you have a little bit time and experience at your hand, you can help
> me to find my error.
> 
> When calling the texture macro directly from another file, it works. But
> when calling it from within the parameter liner of another macro, I get
> the error message you cans see as comment behind one of the lines. Why?
> Why? Why?
> 

Macro call inside macro call...
I'm not sure the parser is expecting such thing, at least in its design
& specification.

Foo( Bar() )

The above line, I would avoid, and use instead

#local BarValue = Bar():
Foo( BarValue )

I'm not a big fan of meta-programming in SDL, so even if there could be
legitimate use cases of a macro invocation from within another macro, I
do not know which path should be followed to handle Foo( Bar() )

1. Bar() is evaluated and its value is used as the parameter (or rather,
the text of the parameter is replaced with the value of Bar() and parsed
every time the parameter is used inside the macro Foo.

2. Bar() is copied as the parameter, and parsed every time the parameter
is used inside the macro Foo.

when Bar() has side effect, it results in something different.

Such as

#declare BarCounter = 0;

#macro Bar()
#declare BarCounter = BarCounter+1;
BarCounter
#end

Should the parser become painful and more complex by forbidding such
macro in macro ? I'm not sure.

Post a reply to this message

Am 22.04.2018 um 08:47 schrieb Le_Forgeron:

> Macro call inside macro call...
> I'm not sure the parser is expecting such thing, at least in its design
> & specification.

"What design & specification?"

> do not know which path should be followed to handle Foo( Bar() )
> 
> 1. Bar() is evaluated and its value is used as the parameter (or rather,
> the text of the parameter is replaced with the value of Bar() and parsed
> every time the parameter is used inside the macro Foo.
> 
> 2. Bar() is copied as the parameter, and parsed every time the parameter
> is used inside the macro Foo.

Whenever the tokenizer encounters an existing macro name `Bar` (except
in special contexts such as `#undef Bar`, `#define Bar` or `#macro
Bar`), it immediately invokes the macro, and effectively inserts the
"results" of the macro in-place. So for instance the following SDL code
is perfectly legitimate, as the apparent single parameter `Bar()`
actually happens to resolve to two parameters:

    #macro Bar()
      "4711", "42"
    #end

    #macro Foo(A,B)
      #debug concat(A,"\n")
      #debug concat(B,"\n")
    #end

    Foo(Bar())

Post a reply to this message

Am 22.04.2018 um 07:47 schrieb Sven Littkowski:

> When calling the texture macro directly from another file, it works. But
> when calling it from within the parameter liner of another macro, I get
> the error message you cans see as comment behind one of the lines. Why?
> Why? Why?

The parser is a bit old and creaky in the joints, and some of its
features may interfere in unexpected ways.

For instance, while parsing the parameter list of a macro invocation,
the parser doesn't like directives (`#if`, `#else`, `#break`, ...) after
a `texture{}` statement -- presumably as an unintended side effect of
the layered textures feature (`texture{} texture{}`).

A simple workaround is to first assign the result of the texture macro
to a temp variable, and then use that temp variable in the object macro
invocation.

Post a reply to this message

You mean, calling the texture macro at first before calling the object
macro, and saving the texture macro's result in a DECLARE, and using
that Declare inside the object macro?

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> The parser is a bit old and creaky in the joints, and some of its
> features may interfere in unexpected ways.
>
> For instance, while parsing the parameter list of a macro invocation,
> the parser doesn't like directives (`#if`, `#else`, `#break`, ...) after
> a `texture{}` statement -- presumably as an unintended side effect of
> the layered textures feature (`texture{} texture{}`).
>
> A simple workaround is to first assign the result of the texture macro
> to a temp variable, and then use that temp variable in the object macro
> invocation.

I would argue that the layered texture feature is defective by design. It is
pretty much the only case where two blocks of the same kind without any wrapper
have a special meaning. For other cases, namely with the addition of "material"
this has been fixed a long time ago. Maybe it is time to force something similar
for layered textures... at least outside scene objects.

Post a reply to this message

Am 22.04.2018 um 16:04 schrieb Sven Littkowski:
> You mean, calling the texture macro at first before calling the object
> macro, and saving the texture macro's result in a DECLARE, and using
> that Declare inside the object macro?

I /think/ what you're trying to say is what I was trying to say, yes ;)

Post a reply to this message

Am 22.04.2018 um 20:15 schrieb Thorsten Froehlich:

> I would argue that the layered texture feature is defective by design. It is
> pretty much the only case where two blocks of the same kind without any wrapper
> have a special meaning. For other cases, namely with the addition of "material"
> this has been fixed a long time ago. Maybe it is time to force something similar
> for layered textures... at least outside scene objects.

I do agree that the current syntax was a bad idea. I would even argue
that its use in a geometric object is also broken, because it assigns
different semantics to the `texture{}` statement in different
situations; for example, in the following code,

    #declare O0 = sphere { ... }
    #declare O1 = object { O0 texture { T1 } }
    #declare O2 = object { O1 texture { T2 } }

the statement `texture{T2}` has the semantics "replace the object's
texture with T2", while in

    #declare O0 = sphere { ... }
    #declare O1 = object { O0 texture { T1 } texture { T2 } }

the statement `texture{T2}` has the semantics "layer T2 on top of the
object's current texture".


I guess a more reasonable syntax for creating layered textures would be:

    texture {
      layered
      texture { ... }
      texture { ... }
      ...
    }

One problem however -- besides the need to maintain backward
compatibility for legacy scenes -- is that with all the additions and
changes that have been made since the introduction of the layered
texture feature, it's probably difficult to identify (a) which portions
of the parser code actually constitute the implementation of this
feature in its current form, and (b) which of these portions have by now
been co-opted by other features.


And then there is the limitation of being unable to layer patterned
textures on top of one another, which I find pretty... well, limiting.

But that has (almost) nothing to do with parsing, and instead is a
limitation of the current rendering engine implementation.

Post a reply to this message