Re: Loadlib and patch order...

Christian Walther <cwalther <at> gmx.ch> writes:

>
> Doh! I enabled dynamic loading in Lua for Mac OS X (for Windows it's
> enabled by default), but then didn't notice that I should have added a
> "luaopen_loadlib(L);" to Pipmak to make the loadlib function
> available... I'll correct that.
>
> Making the unproblematic parts of the os library available is on my
> to-do list for the release.

Thanks! I think this could resolve also the request of Urs to have a "clock"
inside Pipmak...

> Would it be acceptable for your use to inseparably couple file
> reading/writing to file dialogs? I.e. the project could only access
> files that the user has explitly selected in an open or save dialog
> once. That would allow access to files anywhere on the file system,
> while still being hard to abuse, and as a bonus it would bypass the
> problem of different path syntax and filesystem layout on different
> platforms entirely.

Ok, using dialog for writing could be a good idea, but for reading,
I think it could be avoided, because I just "read" and I don't
perform any abuse to the host system...like pipmak.dofile
that don't ask anything...
Anyway I will restrict this operations only on project folder, maintaning
file convention used for loadimage() and dofile().
 
>
> I agree, that has annoyed me a few times too. Perhaps it would be useful
> to have a way of turning on the COPY_PIPMAK_TERMINAL_TO_STDOUT flag at
> runtime?
>

It would be useful have a flag in the preference page, and maybe a lua function
like pipmak.enablestdout() or something like that.
(In Windows when Pipmak starts, I notice that stdout and stderr  files are
created, and deleted when Pipmak ends, is it normal?)


Another question:

I greatly appreciated your efforts about arbitrary patch positioning,
but now I have discover that determining the patches order isn't as simple as
I had imagined...

I'm speaking about this note in your documentation:

"Note that although the normalized coordinates allow you to place patches
geometrically behind each other, this has no influence on how they visibly
overlap. All patches still overlap in the order of their definition,
i.e. a patch defined further down in node.lua will be seen in front of an
earlier patch even if it is geometrically behind it"

I imagine that You have written this note because You confronted with the
problem...

Unfortunately, I know very little SDL and OpenGL, but since you are using
these libraries to draw patches in a 3D space, I wonder if these libraries
do not already have methods to do this action, or permit natively draw
patches in the correct order (I really don't known this)

Do you think it would require a lot of work, to permit patch drawing using
its geometrical order (May be in future release)?
(Well, I suppose that if you don't already do that,
the reason is that this's very complex. But asking do not cost anything ...)

It could be useful also having just a method that got 2 patches (with
visible=false) and return which patch are in front and which are behind,
so I could draw they in the correct order.

You (or anyone is reading now) have some ideas to how write this function
in lua?

Now I have found some compromise using distance of the central point
of a patch from the observation point (0,0,0) and the values ymin,xmin,zmin
but sometimes I got patches in the wrong order....any other ideas?

Bye

Andrea

 











-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Pipmak-Users mailing list
Pipmak-Users@...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users