> Geoff Wedig wrote:
>> 
>> Well, I've run up against a problem.  In Megapov, you can't define macros
>> within macros, which doesn't seem to be a big deal, except for what I'm
>> trying to do.  See, I've written a general engine for doing certain kinds of
>> manipulations.  To make it general, I define several macros that the engine
>> calls, thus allowing me to change the macros externally.  However, now I
>> want to use the engine inside a macro.  Oops!  I can't define the
>> appropriate bits, because they're macros, and you can't define macros within
>> macros.  So I have to define them externally to the macro which uses them.
>> However, I have several macros, each with different parameterizations, and
>> they're called from a different file.  Now that file has to define a whole
>> bunch of stuff before calling the appropriate macro.  Not exactly useful
>> behavior.
>> 
>> Now, these macros simply calculate floating point numbers.  I considered
>> using functions, but that didn't work as I could not evaluate the functions
>> at the points I wanted.  One macro evaluates to a material/texture, but I
>> can forgive that one being a little odd if I could get the others to work.
>> 
>> So, any of you Megapov gurus got any ideas?  I this this is an unsolveable
>> limitation in the program, but maybe someone else has found a way around it.
>> Is there any way to turn off the memory management feature that limits the
>> macro declarations, maybe?  It wouldn't be ideal, but it would work.
>> 
>> Thoughts?
>> 
>> Geoff

> Not a guru, but a though: have your engine macros generated in a file then
> include that file...
> So, first use your engine, next get the result of it for use,
> instead of doing all at once.

Tried that.  But since the file contains macros, it must be included at
global level, and when you have macros calling other macros, that's not
always a sensible thing from a coding standpoint.  You can't just include
the appropriate types before the macro definition either, since if you use
two variants, whatever variant happens to be "in power" at the time of the
macro's function call takes precedence.  Essentially, the scene gets divided
up into sections of macrovariant1, macrovaraint2, etc, at the global level,
or some of the macro calls won't work properly.


Geoff

Post a reply to this message