pipmak-users — Content creation for the Pipmak Game Engine

Re: Panorama Cube Cornes

[NigeC <nig...@gm...>]

I've done by accident when editing pictures.. but i guess you mean within
Pipmak its self

I was trying different image effects to get a sketch art look, and one
called AKVIS Sketch left a 1px line around the edges

Actually it was fairly successful little test with other sketcher plugins,
and the sketch effect worked really well, the hardest part was getting the
sky to stitch properly

if its just for images to test the cubic room, maybe use the magic wand tool
in you art software, set the feather to 1px and feather the outer edge 

Urs Holzer wrote:
> 
> Hi
> 
> Is there a way to see the corners of panorama cubes? It is possible to
> show controls and edges of patches, but is it also possible to show the
> edges or corners of the cube?
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pipmak-Users mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.user
> https://lists.sourceforge.net/lists/listinfo/pipmak-users
> 
> 


-----
http://nigecstudios.co.uk NigeC Studios 
-- 
View this message in context: http://www.nabble.com/Panorama-Cube-Cornes-tp15121189p15121939.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Panorama Cube Cornes

[Urs H. <ur...@an...>]

Hi

Is there a way to see the corners of panorama cubes? It is possible to
show controls and edges of patches, but is it also possible to show the
edges or corners of the cube?

Re: node stack and panning question

[Christian W. <cwa...@gm...>]

shadowphile wrote:
> Sure, here's the upload.  It's very simple.

OK, I can reproduce this. Very weird behavior. I'll have a closer look, 
this seems worth fixing before the 0.2.7 release.

  -Christian

Re: Relative positioning

[Urs H. <ur...@an...>]

Christian Walther wrote:
> Urs Holzer wrote:
>> Do you think the following has a chance to work?
>> I render my patches with Povray using the partial rendering options
>> StartColumn, StartRow, EndColumn, EndRow by giving relative
>> coordinates (i.e. numbers between 0 and 1). Then I crop the images
>> with ImageMagick, again giving relative coordinates. At the end, I
>> place the patch in Pipmak using relative coordinates.
>> I fear that this is doomed to result in ugly artifacts.
> 
> That should work, provided that you deal with the following: I assume
> that both POV-Ray and ImageMagick round your relative numbers to whole
> pixels. Pipmak doesn't do that. So you need to make sure that the
> boundaries you give in relative coordinates already lie on pixel
> edges.

Ok, I give it up. It seems, that ImageMagick does treat offsets always
as pixels, only the _size_ of the region to be cropped out can be given
as percentage. I could use ImageMagick's -trim, which cuts off
uniformly coloured areas from all borders, but I don't know whether it
would always do the right thing. I don't even dare to think about how
to solve the problem you mentioned.

Re: node stack and panning question

[shadowphile <sha...@gm...>]

Sure, here's the upload.  It's very simple.

>
Christian Walther wrote:
> 
>>shadowphile wrote:
>>> I conceived of using a background cubic node to display a cloudy sky.
>>> I then overlayed a cubic node of my landscape, but then the screen locks
>>> up,
>>> won't allow me to pan.
>>> Is this right?  Does any stack of nodes block mouse control of panning?
> 
>>No, that must be a bug. I've never tried stacking multiple cubic nodes, 
>>but it should work. In fact, using two cubic nodes will be a great way 
>>to achieve a moving sky once the capability of rotating the cubes 
>>relative to each other is implemented, so I want this to work.
> 
>>Could you prepare a small example project that shows the problem, so we
>>can have a look at it?
> 
>>  -Christian"
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pipmak-Users mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.user
> https://lists.sourceforge.net/lists/listinfo/pipmak-users
> 
> 
http://www.nabble.com/file/p15105919/StackCubes.pipmak StackCubes.pipmak 
-- 
View this message in context: http://www.nabble.com/node-stack-and-panning-question-tp15085495p15105919.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: node stack and panning question

[Christian W. <cwa...@gm...>]

shadowphile wrote:
> I conceived of using a background cubic node to display a cloudy sky.
> I then overlayed a cubic node of my landscape, but then the screen locks up,
> won't allow me to pan.
> Is this right?  Does any stack of nodes block mouse control of panning?

No, that must be a bug. I've never tried stacking multiple cubic nodes, 
but it should work. In fact, using two cubic nodes will be a great way 
to achieve a moving sky once the capability of rotating the cubes 
relative to each other is implemented, so I want this to work.

Could you prepare a small example project that shows the problem, so we
can have a look at it?

  -Christian

node stack and panning question

[shadowphile <sha...@gm...>]

Hi all.  I've just started playing with this engine tonight.  I may be under
a misapprehension.
I conceived of using a background cubic node to display a cloudy sky.
I then overlayed a cubic node of my landscape, but then the screen locks up,
won't allow me to pan.
Is this right?  Does any stack of nodes block mouse control of panning?
thanks,
Matt
-- 
View this message in context: http://www.nabble.com/node-stack-and-panning-question-tp15085495p15085495.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: Loadlib and patch order...

[Christian W. <cwa...@gm...>]

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

Re: Relative positioning

[Christian W. <cwa...@gm...>]

Urs Holzer wrote:
> Is it possible to place patches at relative positions? For example,
> placing a patch at 40% from the left and 40% from the top. Using the
> parameters x and y, I have to provide the position of the patch in
> pixels. But I don't know the size of the images, I know only the
> relative positions. Is it possible to use nx and ny to do such a
> relative positioning?

On cubic nodes, yes. There the normalized coordinates go from -1 to 1, 
independently of the image resolution. On slides and panels, not 
directly - normalized coordinates are equal to pixel coordinates there, 
there is no "relative" coordinate system.

> I don't really get what is written in the documentation.

Once you do get it, please let me know if you have any suggestions on 
how it can be clarified.

> Perhaps using nz=1, nx and ny between -1 and 1 would work?

Yes. Just keep in mind that the edge of the cube face image does not lie 
on the cube edge (at nx,ny = +-1), but half a pixel outside.

> Of course, I also could use image:size() to get the size of a side or a
> patch ...

Right, that's what I would suggest on slides or panels.

> Do you think the following has a chance to work?
> I render my patches with Povray using the partial rendering options
> StartColumn, StartRow, EndColumn, EndRow by giving relative coordinates
> (i.e. numbers between 0 and 1). Then I crop the images with
> ImageMagick, again giving relative coordinates. At the end, I place the
> patch in Pipmak using relative coordinates.
> I fear that this is doomed to result in ugly artifacts.

That should work, provided that you deal with the following: I assume 
that both POV-Ray and ImageMagick round your relative numbers to whole 
pixels. Pipmak doesn't do that. So you need to make sure that the 
boundaries you give in relative coordinates already lie on pixel edges.

  -Christian

Relative positioning

[Urs H. <ur...@an...>]

Hi

Is it possible to place patches at relative positions? For example,
placing a patch at 40% from the left and 40% from the top. Using the
parameters x and y, I have to provide the position of the patch in
pixels. But I don't know the size of the images, I know only the
relative positions. Is it possible to use nx and ny to do such a
relative positioning? (I don't really get what is written in the
documentation. Perhaps using nz=1, nx and ny between -1 and 1 would
work? Right now I don't have the patience to do some experiments
myself, sorry.)
Of course, I also could use image:size() to get the size of a side or a
patch ...

Do you think the following has a chance to work?
I render my patches with Povray using the partial rendering options
StartColumn, StartRow, EndColumn, EndRow by giving relative coordinates
(i.e. numbers between 0 and 1). Then I crop the images with
ImageMagick, again giving relative coordinates. At the end, I place the
patch in Pipmak using relative coordinates.
I fear that this is doomed to result in ugly artifacts.

Re: Loadlib and patch order...

[Andrea V. <and...@gm...>]

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

Re: [pipmak-users] Direction control leaving/entering cubic rooms

[NigeC <nig...@gm...>]

Christian Walther wrote:
> 
> 
> 
> If I'm understanding you correctly, something must be wrong here.  
> Pipmak should maintain the viewing direction when switching from  
> panorama to panorama, so when you face east to go through the door,  
> you should still be facing east in the next room. Could it be that  
> your cube faces are in the wrong order?
> 
I made the cubes with Btyce going by the tutorial (0,90,180, etc), moving
the camera east for the first 3 areas, the next moved the camera north ... 
each time the camera face the direction the player came from
not to worry, I'm doing something a lot more interesting than a maze ;)

nige

-----
http://nigecstudios.co.uk NigeC Studios 
-- 
View this message in context: http://www.nabble.com/Direction-control-leaving-entering-cubic-rooms-tp14804465p14980405.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: Direction control leaving/entering cubic rooms

[Christian W. <cwa...@gm...>]

NigeC wrote:
> the first room starts with the camera facing north the exit is east,  
> when i
> exit the camera faces the exit i just went through, rather than
> east/straight ahead

If I'm understanding you correctly, something must be wrong here.  
Pipmak should maintain the viewing direction when switching from  
panorama to panorama, so when you face east to go through the door,  
you should still be facing east in the next room. Could it be that  
your cube faces are in the wrong order?

If you need to change the direction (e.g. when you go from a panorama  
to a slide, then return to the panorama), there's the  
pipmak.setviewdirection() function, as Andrea has pointed out.

   -Christian

Re: Build 172 and some debug facilities proposals

[Christian W. <cwa...@gm...>]

Andrea Viarengo wrote:
> Is there a method or a trick to set something like a "breakpoint" in
> the Lua code to put in pause Pipmak, so I can inspect tables in that
> position?

Not really. One thing that comes close is the debug.debug() function  
(and the rest of the debug library, which has been available in Pipmak  
since r162). But since it works on stdin/stdout, I guess it's useless  
on Windows (unless you compile Pipmak as a console application).

> I think it could be very useful a function like "pipmak.pause(key)"
> that stops running  until the pressing of the key "key" and show  
> message
> "Press <key> to continue", or better show a little overlayed window
> with the button "continue",
> so I could examine tables also inside function, or execute some code
>> from a breakpoint to another breakpoint, in this manner,
> with a very little waste of coding efforts, we could have a minimal,
> but useful debugging tool,
> waiting a complete debug protocol for connecting to an external  
> debug tool,
> that you have mentioned in the past.

The problem with this is that Lua execution and screen redrawing (and  
everything else except sound) is done synchronously in Pipmak. So,  
while Lua execution is stopped, the screen is not redrawn, and the  
table inspector etc. wouldn't work either. Perhaps there would be a  
way around this if all calls Pipmak makes into Lua were done as  
coroutines, but that would open a whole another can of worms. This is  
another reason why I think an external debugger would be an easier  
solution.

   -Christian

Re: Loadlib and patch order...

[Christian W. <cwa...@gm...>]

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

Re: [pipmak-users] 3rd Person games

[NigeC <nig...@gm...>]

I don't mind the comments at all
I totally agree to be honest, I was picking up on the Wiki post, theres
plenty of 2D engines that do the job perfectly well, its hard enough
controlling characters in those sometimes lol
Yes it would be a nice feature in in non cubic rooms

I've made 5 Flash/Lassie games and trust me characters can be hard work,
getting them walk right, move, etc  just on a flat plain, a similar game in
a cubic room would be a total nightmare, you might as well use a full 3D
engine..



-----
http://nigecstudios.co.uk NigeC Studios 
-- 
View this message in context: http://www.nabble.com/3rd-Person-games-tp14784525p14834962.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: [pipmak-users] 3rd Person games

[Aidan G. <wgs...@ih...>]

  If you don't mind my commenting, I think that using a first-person 
game engine to create a third-person game wouldn't be a good idea, 
because the purpose of a game engine (or at least one of them) is to 
separate the engine logic from game logic, and any sort of third person 
plug-in for Pipmak would be somewhat of a game engine written in Lua, 
using a game engine for a different type of game. Which would be 
somewhat redundant, I think. Although I think it would be useful for 
scenes or puzzles that would look better, or be easier to play in a 
third person view, but not for doing an entire game.

 -Aidan

NigeC wrote:
> I was looking at the Wiki and i was wondering if anyone had actually done 3rd
> Person games with Pipmak?
>
> Theres a small article on how its done in Action Script:
> http://langleycreations.com/andrew/blog/?p=52
>
> I wouldn't know how to translate AS to LUA, i'm not a coder, but theres
> quite a lot of examples to how its done in AS
>
> AGS uses a colour based "hotspot" system, walkable areas, walkbehind and
> hotspots, on walkabale areas each colour has a scale option, the trick would
> be a linear transition between colours
>
> I cant see how it would be done in a cubic view, the character could look
> kind of odd.. unless there was a way to use true 3D characters, wintermute
> uses X.file format to do it
>
> -----
> http://nigecstudios.co.uk NigeC Studios 
>   

[pipmak-users] LUAedit

[NigeC <nig...@gm...>]

I don't know if anyone uses it but i found a nasty problem with it...
I was editing a node file and saved it.. as you do lol, next thing I know a
whole room had gone!
Luckily a remembered someone mention this on nucleosys.com and its a bug
intended to delete a temp file, but for some reason grabs everything in the
same location

Just imagine if it was the main.lua it would take and bin someones whole
project.. even worse if they edited and didn't test they wouldn't know and
possibly empty the recycle bin next day

I'm going to look at the other editors!!

-----
http://nigecstudios.co.uk NigeC Studios 
-- 
View this message in context: http://www.nabble.com/LUAedit-tp14818863p14818863.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: [pipmak-users] Direction control leaving/entering cubic rooms

[NigeC <nig...@gm...>]

Thanks for the quick reply :)

I will give that a try

As soon as I have something useful to show i'll do something on the Wiki..
if you ever need someone to proof read docs etc , English is my first
language

thanks
Nige

-----
http://nigecstudios.co.uk NigeC Studios 
-- 
View this message in context: http://www.nabble.com/Direction-control-leaving-entering-cubic-rooms-tp14804465p14806629.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: Direction control leaving/entering cubic rooms

[Andrea V. <and...@gm...>]

NigeC <nigec999 <at> gmail.com> writes:

> 
> 
> How do i control the direction the camera faces as you enter a cubic room?
> 

Hello NigeC,
Welcome to Pipmak!!

I think you could use the method

pipmak.setviewdirection(azimuth,elevation)

And if you need to get the current direction there are also

az,el=pipmak.getviewdirection()

(See at page 22 of Pipmak manual of version 0.2.6)

I hope this can be helpful for you.

If you produce some example that you think it could be useful to others,
consider the Wiki!!

Andrea

[pipmak-users] Direction control leaving/entering cubic rooms

[NigeC <nig...@gm...>]

How do i control the direction the camera faces as you enter a cubic room?

Just for a simple project i've built a 3D maze

the first room starts with the camera facing north the exit is east, when i
exit the camera faces the exit i just went through, rather than
east/straight ahead


Theres a lot of expermenting at the moment, i normally dio static 2D so you
only have one view to add content to, i thought the maze would be a useful
way to get my head round camera control and the best places to place them..
great fun though!
can't wait until the next update

-----
http://nigecstudios.co.uk NigeC Studios 
-- 
View this message in context: http://www.nabble.com/Direction-control-leaving-entering-cubic-rooms-tp14804465p14804465.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Build 172 and some debug facilities proposals

[Andrea V. <and...@gm...>]

Hello Chris!!

I managed to compile Pipmak build 172 using Lua 5.0.3.

Now "really" all works fine without "any" source modification 
(including the function "checkinstanceof" that in the past give me 
some problem - remember it when you pass to Lua 5.1) 

Is there a method or a trick to set something like a "breakpoint" in 
the Lua code to put in pause Pipmak, so I can inspect tables in that
position? 

At the moment I cannot inspect value inside functions
(correct me if I am in wrong)
but only at the end of execution of node.lua or in case of error.

I think it could be very useful a function like "pipmak.pause(key)"
that stops running  until the pressing of the key "key" and show message 
"Press <key> to continue", or better show a little overlayed window
with the button "continue", 
so I could examine tables also inside function, or execute some code 
from a breakpoint to another breakpoint, in this manner, 
with a very little waste of coding efforts, we could have a minimal,
but useful debugging tool,
waiting a complete debug protocol for connecting to an external debug tool,
that you have mentioned in the past.

Off course pipmak.pause() will have no meaning in a finished game.

In this case, also another function could be useful:

pipmak.ignorepause(true|false)

to put at the beginning of the code, 
or better in main.lua should permit to ignore all breakpoint the I have
insert with pipmak.pause(), so I haven't to physically remove all 
pipmak.pause() in my code to run my code without interruption.
(but I will remove before game release of-course...)

What you think about?  

Now error traceback work fine in my build, but sometimes I didn't manage 
to read all the information reported quickly before the infos vanish away....
(I already mentioned to you a similar problem about stdout...)

A good solution could be to put error messages in a window like the new
Lua command line or the table inspector, 
so I could read with all calm, check files, line numbers, function names,...

The window could have also some buttons:

* continue
* open lua command line (for inspecting values)
* open node.lua (or the file/s involved in the errors)

Well, I think this is good only for error message that involve in a
stop of the node execution, but not for all other messages written
in the pipmak terminal (in this case is better have a copy of stdout on
file as discussed before)
  

I think these things (with little efforts, I think) could do better
highlight your work on traceback and table inspector.

Bye 

Andrea

Re: Loadlib and patch order...

[Andrea V. <and...@gm...>]

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

 

[pipmak-users] 3rd Person games

[NigeC <nig...@gm...>]

I was looking at the Wiki and i was wondering if anyone had actually done 3rd
Person games with Pipmak?

Theres a small article on how its done in Action Script:
http://langleycreations.com/andrew/blog/?p=52

I wouldn't know how to translate AS to LUA, i'm not a coder, but theres
quite a lot of examples to how its done in AS

AGS uses a colour based "hotspot" system, walkable areas, walkbehind and
hotspots, on walkabale areas each colour has a scale option, the trick would
be a linear transition between colours

I cant see how it would be done in a cubic view, the character could look
kind of odd.. unless there was a way to use true 3D characters, wintermute
uses X.file format to do it

-----
http://nigecstudios.co.uk NigeC Studios 
-- 
View this message in context: http://www.nabble.com/3rd-Person-games-tp14784525p14784525.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: [Pipmak-Users] Loadlib and co.

[Christian W. <cwa...@gm...>]

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