Thread: [Pipmak-Users] Loadlib and co.
Status: Alpha
Brought to you by:
cwalther
Menu
▾
▴
pipmak-users
|
From: Andrea V. <and...@gm...> - 2008-01-11 15:46:21
|
Hello!
It would be nice if next version 0.2.7 will enable at least loadlib,
which doesn't work in Windows (I don't know in Linux and Mac),
So it would be possible create plugins for Pipmak (For example, I'm
working on object3D in lua, and it works nice, but probably writing this
in "C" should be more efficient...and on other hand, I don't think that
implement this directly inside Pipmak could be a good idea...)
I would like also have lua "os", but I know your idea about it.
You think that it would be a bad idea having os enabled only for the
project folder, so I could write and read text file, check
the esistence of file, and so on, only there?
Another idea: I have implemented in my pipmak build:
pipmak.writetofile("path/file","text to write",append_flag),
(I use for example to write autocubic map or 3d object descriptions...)
I use also to debug purpose, because sometimes write a lot of text on
the screen isn't good, because is difficult to read, overall if the
text go beyond the bottom of the screen...
I don't think that User could do a lot of damages with pipmak.writetofile and
pipmak readfromfile.....
Bye
Andrea
|
|
From: Christian W. <cwa...@gm...> - 2008-01-11 22:22:02
|
Andrea Viarengo wrote:
> It would be nice if next version 0.2.7 will enable at least loadlib,
> which doesn't work in Windows
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.
> I would like also have lua "os", but I know your idea about it.
Making the unproblematic parts of the os library available is on my
to-do list for the release. I won't enable all of it - call me paranoid,
but I want Pipmak projects to be sandboxed. (Of course loadlib lets you
break out of the sandbox too, but it has a higher barrier of entry.)
> You think that it would be a bad idea having os enabled only for the
> project folder, so I could write and read text file, check
> the esistence of file, and so on, only there?
I mainly think it would have very limited use - a user won't look for
newly created files inside the project. Also, projects, like
applications, shouldn't modify themselves as a matter of principle.
Often they won't be able to anyway because they're zipped, on read-only
media, or in a place where the user doesn't have write permission.
> Another idea: I have implemented in my pipmak build:
>
> pipmak.writetofile("path/file","text to write",append_flag),
> (I use for example to write autocubic map or 3d object descriptions...)
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.
> I use also to debug purpose, because sometimes write a lot of text on
> the screen isn't good, because is difficult to read, overall if the
> text go beyond the bottom of the screen...
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?
-Christian
|
|
From: Andrea V. <and...@gm...> - 2008-01-14 09:24:39
|
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 |
|
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 |
|
From: Andrea V. <and...@gm...> - 2008-01-21 09:15:43
|
Hi, Christian. I'm happy that your surgery has gone well, So, now you are at home, in your bed... with your Powerbook... and you have a lot of time to spent with working on Pipmak.......!! ;) About methods for read and write: to read a text file, I can use dofile() if I the file format is Lua, it's ok, the real lack is the write method, because now I have no way to write a file! I think that your idea to associate write/read method to a dialog is not so bad, My only doubt was (thinking to a general use of read/write) that during a game should not appear the dialog window with the request of a file name, if the game, for some reason, wanted to be saved some information on file to re-read that at a later time ... But probably, This case may never be... and I could do the same just storing data in memory... Ok for read/write methods with dialog. By the way, are you thinking of implementing the dialogs for writing and reading files, inside pipmak (i.e.: without using OS API)? This is not only for future methods read / write, but also for opening Files .pipmak and .pipsave, that currently use API from host OS, but these can not be used in Fullscreen mode (they force a return to a windowed mode), and also in windowed mode, while these dialog windows are shown, the main window of Pipmak is no longer updated (of-course it is not serious, and also useless, but it's a little ugly, see the window under the dialog become white or with pieces of extraneous windows inside...ok, this happen in Windows...) Anyway, a thing to put at the very end of the TODO list... About 3D patches order, I think that permit showing them in their geometrical order, if this don't require a lot of coding, should be a very good idea, At limit, you could add a flag field in the patch method or elsewhere to enable/disable the deep buffer if you want preserve the drawing order... Well,I don't know if we really need a flag..., probably the good thing is use geometrical order only with 3D patch, and drawing order in all other cases, but we have to thought about the using of both patches type (3d and traditional) in the same scene. Bye and Wishes for your speedy recovery. (Probably there are some idiomatic phrase to tell this, but I don't known that, in Italian: "Auguri per la tua guarigione." Andrea |
|
From: Christian W. <cwa...@gm...> - 2008-01-22 17:00:27
|
Andrea Viarengo wrote: > So, now you are at home, in your bed... with your Powerbook... > and you have a lot of time to spent with working on Pipmak.......!! ;) Not really... when I'm fit enough to work on Pipmak, I'm also fit enough to return to work... (which I will tomorrow) :/ > My only doubt was (thinking to a general use of read/write) > that during a game should not appear the dialog window with the request > of a file name, if the game, for some reason, wanted to be saved > some information on file to re-read that at a later time ... > But probably, This case may never be... and I could do the same > just storing data in memory... Yes, that's what the state table is for. Let me know if you can think of a situation where writing and reading files would be better than using the state table (which is saved to saved game files). > By the way, are you thinking of implementing the dialogs for writing > and reading files, inside pipmak (i.e.: without using OS API)? No. I see no reason to replace a full-featured file dialog that looks and works the way users expect with a home-grown substitute. > these can not be used in Fullscreen mode (they force a return to a windowed > mode) Is that a problem? > (of-course it is not serious, and also useless, but it's a little ugly, > see the window under the dialog become white or with pieces of extraneous > windows inside...ok, this happen in Windows...) I have little inclination to work around Windows' deficiencies in this respect. I assume it should be possible to run the dialog in its own thread and have the project run along in the background, but I don't think it's worth the effort. > "Auguri per la tua guarigione." Grazie! -Christian |
|
From: Evgen <ev-...@ya...> - 2009-01-22 11:12:32
|
Some time ago i find Pipmak, and i think that is very interesting project =)
My english not well, and first time I translate wiki and manual.
Next I try build little demo, but when I check save and load functions, I
saw Windows (save/load) dialog with MyDocument folder.. I think it not nice
When players play game, and want to save/load progress, I think nobody want
see Windows dialogs or Windows system messages, and search files, or get
keyboard and write long special name with description =)
I think it nice if players will save/load game with special functions
without Windows dialog.
for example pipmak.savegame2("name") -- and game will saved as name.pipsave
in game folder without windows dialogs.
May be in future versions it will be? Or anybody already do it?
Thanks
--
View this message in context: http://www.nabble.com/Loadlib-and-co.-tp14759194p21602085.html
Sent from the pipmak-users mailing list archive at Nabble.com.
|
|
From: Christian W. <cwa...@gm...> - 2009-01-22 12:28:36
|
Hello Evgen
Administrative detail first: please start a new thread for a new
topic, instead of replying in an unrelated old thread. Makes the list
archives easier to follow.
> Next I try build little demo, but when I check save and load
> functions, I
> saw Windows (save/load) dialog with MyDocument folder.. I think it
> not nice
>
> When players play game, and want to save/load progress, I think
> nobody want
> see Windows dialogs or Windows system messages, and search files, or
> get
> keyboard and write long special name with description =)
From a personal point of view, I disagree. I prefer being able to
save as many games as I want, under whatever name I want, anywhere I
want to the limited in-game save facilities some games have. True, I
wouldn't want to see Windows dialogs, but I'm pretty happy with my Mac
OS dialogs ;).
But I recognize that my personal opinion is not the measure of all
things here, so of course project authors should eventually be able to
implement an in-game saved game browser if they so choose. The present
solution was just the minimum necessary.
> I think it nice if players will save/load game with special functions
> without Windows dialog.
> for example pipmak.savegame2("name") -- and game will saved as
> name.pipsave
> in game folder without windows dialogs.
>
> May be in future versions it will be? Or anybody already do it?
It has been in a corner of my head as a vague idea, but as far as I
know nobody has done any work on it. It hasn't even made it onto the
to-do list yet :).
I disagree with the suggestion to save in the game folder though
(assuming you mean the folder that contains the project), because this
location might not be writable by the user (e.g. located on a CD). The
standard location should be somewhere in the user's home directory (~/
Library/Application Support/ on Mac OS, don't know where on Windows).
-Christian
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X