Re: Loadlib and patch order...
Status: Alpha
Brought to you by:
cwalther
From: Christian W. <cwa...@gm...> - 2008-01-20 07:48:15
|
Hello, I'm back among the living! My sudden silence was caused by an unexpected hospital visit for appendix surgery. All went well and I'm back at home now, catching up on mailing lists and stuff. Andrea Viarengo wrote: > Christian Walther <cwalther <at> gmx.ch> writes: >> 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... But then you still have to deal with paths. > Anyway I will restrict this operations only on project folder, > maintaning > file convention used for loadimage() and dofile(). I still have my doubts that - writing to the project in this way is a good idea, - being able to read from the project in this way adds much advantage over what you can already do with dofile(). > It would be useful have a flag in the preference page, and maybe a > lua function > like pipmak.enablestdout() or something like that. On the To Do list. > (In Windows when Pipmak starts, I notice that stdout and stderr > files are > created, and deleted when Pipmak ends, is it normal?) Yes, SDL does that on Windows because otherwise these streams would end up nowhere. The files are deleted at exit if they are empty, or left if they contain anything. > "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) Yes, in principle the solution is simple - just enable the depth buffer in OpenGL, and polygons occlude each other properly, independently of the order in which they are drawn. The problem is that everywhere else in Pipmak correct depth rendering is not necessary, and so it's possible that I ended up relying on having things show up in their drawing order rather than their geometrical order in a lot of places. I have never examined that. Probably we'd need to put the 3D-positioned patches into their own list and render these (and only them) with depth testing enabled. Obviously, proper depth rendering would also be a prerequisite for import of arbitrary 3D objects into Pipmak. I've added that to the To Do list. -Christian |