pipmak-users — Content creation for the Pipmak Game Engine

Re: [Pipmak-Users] [pipmak-users] I just wanted to say

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

How Awakening does it by downloaded a .exe archive from the webpage which is
commented to unpack and run/load into the webplayer from temp files. but yes
i agree you may as well just download the game, most browsers throw a wobbly
now if they even get a sniff of an activeX plugin

I'm suprised how easy Pipmak is to use, I'm very impressed, I've got my
first cubic room, with hotspots and also close ups
 i had a look at the SCream engine awhile ago and didn't get anywhere with
it. what is impressive is you don't get the vertigo feeling with Pipmak as
you do with Scratches and other panning games





-----
http://nigecstudios.co.uk NigeC Studios 
-- 
View this message in context: http://www.nabble.com/I-just-wanted-to-say-tp14743768p14766368.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: [Pipmak-Users] [pipmak-users] conversations

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

Cool B-)
I'm looking forward to the next release, hopefully i can do something useful
by then!

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

Re: [Pipmak-Users] conversations

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

NigeC wrote:
> Is there a way to control where text is placed, other than the top corner..

You can't change where the Pipmak terminal text appears, but that one 
isn't meant for use in a finished game anyway. It's intended more as a 
debugging tool.

The upcoming 0.2.7 release has support for drawing text (in arbitrary 
fonts, sizes, colors) onto patches, so that you can place it anywhere 
you want.

> an example would be if the player examined an object a discription would
> appear at the bottom of the screen

You'll be able to do that.

  -Christian

Re: [Pipmak-Users] [pipmak-users] I just wanted to say

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

NigeC wrote:
> What a great engine Pipmak is!

Thanks! Hope it helps you create some great content!

> Just out of interest would a web browser version be possible? A 3D engine
> called Awakening by awingsoft.com uses LUA and has a web player

I guess it would be possible, with some effort, to build Pipmak into a 
web browser plugin, as Awakening does. But I don't see the point - if 
you're going to require your users to install extra software (and 
platform-specific one at that), you can just as well have them download 
the application.

If you mean a web viewer that only uses capabilities that are already 
present in web browsers, no, I can't see a way to make that work.

  -Christian

[Pipmak-Users] [pipmak-users] conversations

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

Is there a way to control where text is placed, other than the top corner..

an example would be if the player examined an object a discription would
appear at the bottom of the screen

Thanks
Nige

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

[Pipmak-Users] Loadlib and co.

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

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

[Pipmak-Users] [pipmak-users] I just wanted to say

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

What a great engine Pipmak is! We've been thinking about doing another 1st
person game for quite some time but the flash engine we used for the first
wasn't ideal.

Just out of interest would a web browser version be possible? A 3D engine
called Awakening by awingsoft.com uses LUA and has a web player
-- 
View this message in context: http://www.nabble.com/I-just-wanted-to-say-tp14743768p14743768.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: [Pipmak-Users] Imaging manipulation methods

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

Andrea Viarengo wrote:
> I'm start a new tread, because I cannot manage to visualize your last reply
> in gmane (but only in nabble)
> which across the two mailinglist (start from "devel" end go to "user")

You're right, the post shows up on devel instead of user in Gmane's web 
interface. Weird. Guess I have to break the thread next time I do such a 
thing.

> About image manipulation,
> I understand that loadimage() come from last pipmak version, when image 
> manipulation was not possible, and you want preserve its old behaviour.

Right.

> With the Adding the constructor newimage("/path/image.ext"),
> loadimage could become obsolet and maintained only for backward compatibility.

Not really. According to my latest proposal, its name becomes obsolete 
(because it's misleading now), but its functionality persists under the 
new name "getimage". Although this will continue to be mostly used 
internally and rarely by users (usually, users specify a file name and 
Pipmak converts it to an image object itself).

Reusing the same image data rather than reloading it from disk over and 
over again is crucial in situations like the following, so I'm not going 
to give this up:

hotspot { onhilite = function(self, hilite) patch:setimage(hilite and 
"hilited.png" or "normal.png") end }

> Another possibility could be adding method:
> image:copyfrom("/path/image.ext")

Right, that would be more versatile than the extended "newimage" 
function I proposed. How should differing sizes of the source and 
destination image be handled in this case? Would the source image just 
be copied to the top left corner of the destination?

In addition, that function could also take an existing image object 
instead of a file name. Then you could save intermediate stages of your 
image composition process and reuse them (whether that's really useful I 
don't know).

> and next
> 
> image:copyfrom("/path/image.ext",x,y,w,h)
> 
> permitting the loading of a image file just in a limited portion of the
> newimage, this will be very usefull, instead using a lot of patches to
> create composed image.

I'm not sure. I intended not to encourage people to do the thing you 
describe, for efficiency reasons. In the current implementation, it 
means copying around a lot of image data in main memory, while 
composition of images could also happen on the GPU, as is currently the 
case when you use separate patches.

Actually, allowing users to draw onto images loaded from files already 
violates that principle (except for the case of using image:fill() with 
alpha < 1 to cut holes). As you may remember, I didn't even anticipate 
that use when I started designing image manipulation - my expectation 
was that you would draw on a patch and place that above the unmodified 
image.

But maybe I should do some actual profiling before jumping to 
conclusions about efficiency. Actually, I can think of cases where 
composition on the CPU would probably be more efficient.

> I don't known if having object carrying modifiable and unmodifiable image
> could be a good idea...I think could confuse newbies... 

Perhaps. Although newbies probably won't deal with getimage (loadimage) 
at all. I'm still leaning towards that solution, however, because it 
would also take care of the missing-alpha-channel bug, and it would be 
easier to implement than the alternative. The copy-on-write solution 
that would make all images mutable from the point of view of the user, 
while still taking advantage of data reuse internally, could still be 
implemented in 0.3 or a later version.

Thanks for your input!

  -Christian

[Pipmak-Users] Imaging manipulation methods

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

Hi, Christian

I'm start a new tread, because I cannot manage to visualize your last reply
in gmane (but only in nabble)
which across the two mailinglist (start from "devel" end go to "user")

http://thread.gmane.org/gmane.games.devel.pipmak.devel/77

About image manipulation,
I understand that loadimage() come from last pipmak version, when image 
manipulation was not possible, and you want preserve its old behaviour.

With the Adding the constructor newimage("/path/image.ext"),
loadimage could become obsolet and maintained only for backward compatibility.  

Another possibility could be adding method:

image:copyfrom("/path/image.ext")

and next

image:copyfrom("/path/image.ext",x,y,w,h)

permitting the loading of a image file just in a limited portion of the
newimage, this will be very usefull, instead using a lot of patches to
create composed image.

I don't known if having object carrying modifiable and unmodifiable image
could be a good idea...I think could confuse newbies... 

Andrea     

Re: [Pipmak-Users] Different patches positioning

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

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

I had loosed this your reply,

Ok, probably you are on right.

I have to investigate more about patch positioning...
I'm little confused now.
I'm thinking also about solution of patch image reusing..

But what about different rendering of not-trasparent and trasparent PNG 
(see http://article.gmane.org/gmane.games.devel.pipmak.devel/76 )?

Well, the next revision of autocubic will be totally different, 
because it will use 3d positioning (that it was a my request, remember?)

For the moment I am working on object3d which I mentioned on the wiki, 
and 3d patch positioning seems work correctly, with just a strange behaviour...
if I move a patch through faces edges, it leave a track on 
the background images...
it seems a behavior like in official 0.2.6 when you put a patch outside a face.
but i want to investigate more before propose to you an example.

Bye.

Andrea

   

Re: [Pipmak-Users] Different patches positioning

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

Andrea Viarengo wrote:
> I have tryed to compile SVN Build 144=20
> (I think this build correspond more or less to version 0.2.6, isn't it?=
)
>=20
> This build compiled with MS Visual C++ work exactly as your official ve=
rsion=20
> 0.2.6
>=20
> I have posted screenshots to=20
>=20
>  http://viarengo.altervista.org/download/Patch.zip
>=20
> You could see separation line between patches.

OK... I've studied this, and I have determined that the new behavior=20
(tested in rev. 170, probably unchanged since 155) is correct, and the=20
old behavior (in Pipmak 0.2.6) is wrong.

If that confuses you, read section 2.9 "Patches" in the reference, in=20
particular the top left part of figure 5, and the following paragraph=20
under "Advanced Placement in 3D":
   Width and height of the patch can also be speci=EF=AC=81ed in normaliz=
ed=20
units using the nw and nh parameters. Unlike w and h, which give the=20
total width and height of the patch, these parameters describe the=20
visible width and height. On panoramas and slides, this is one patch=20
pixel less than the total width or height because a margin of half a=20
pixel is cut off each side of the patch, so that the centers of the=20
outermost pixels lie on the edge, to enable a bilinearly interpolated=20
patch to blend seamlessly into a bilinearly interpolated background=20
image. This is similar to what=E2=80=99s done with the cube faces as desc=
ribed=20
under =E2=80=9CMaking Cubic Panoramas=E2=80=9D in section 2.8 =E2=80=9CCu=
bic Panoramas=E2=80=9D. As an=20
example, this means that to make a patch of the same size coincide with=20
cube face 1 (the same thing that would be accomplished by setting face =3D=
=20
1, x =3D 0, y =3D 0), you would specify anchorh =3D 0.5, anchorv =3D 0.5,=
 nx =3D=20
-1, ny =3D 1, nz =3D -1, nw =3D 2, nh =3D 2.

You're relying on a bug in Pipmak 0.2.6 that causes the 0.5 pixel offset =

to be applied in the wrong direction for patches with negative height,=20
making the patches overlap. Try giving your patches positive heights,=20
and you'll see that you get these gaps even in 0.2.6.

You should easily be able to get rid of the gaps by positioning your=20
patches using normalized coordinates (don't forget anchorh =3D 0.5,=20
anchorv =3D 0.5).

  -Christian

Re: [Pipmak-Users] This code show the image-cache-bug...

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

[For those who only read -users: This is a continuation of a thread=20
started on pipmak-devel. I'm moving it here because I'm interested in=20
feedback from everyone. Read the beginning here:=20
<http://thread.gmane.org/gmane.games.devel.pipmak.devel/77>.]

I wrote:
> What trips you up is this (from section 3.12 "Image Manipulation" of th=
e=20
> reference):
> "pipmak.loadimage(filename) ... Calling this function multiple times=20
> with the same path returns the same object, and the image is only=20
> reloaded from disk if it isn=92t already in memory."
>=20
> ...
>=20
> I'm not sure what the best solution to this is. I don't think giving up=
=20
> the returns-the-same-object behavior of pipmak.loadimage is a good idea=
,=20
> as I rely on it in many places. I'll try to think of something better

I'm still pondering the copy-on-write thing, but here's another solution:=


- Rename pipmak.loadimage to pipmak.getimage to emphasize its behavior=20
(keeping the old name around for backwards compatibility).

- Disallow modification of images gotten from pipmak.getimage - if you=20
want to draw on an image, you must create it using pipmak.newimage.

- Allow pipmak.newimage to be called with a path instead of width and=20
height, to initialize the new image from a file.

What do you think?

This would be simpler to implement, but would complicate things from the =

point of view of the user, by dividing image objects into two classes.

  -Christian

Re: [Pipmak-Users] a clock

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

Urs Holzer wrote:
> When I play a game in fullscreen mode, I always have to keep my watch
> ready. So I think it would be nice if the player could simply hit a key
> to get the time.
> 
> I think Pipmak should, by default, display the time if the user hits T.

Interesting idea. Although I think this feature is high-level enough 
that it shouldn't be implemented in Pipmak itself, but in the project. 
If only because Pipmak doesn't know how to render a clock in a way that 
fits the graphical style of the game.

Of course Pipmak needs to provide the infrastructure for it, which it 
currently doesn't.

> the os package seems to be missing in Pipmak.

That is deliberate, because I don't want projects to be able to do 
certain things like executing arbitrary shell commands or deleting 
arbitrary files. Although perhaps it would make sense to include the 
useful parts of the os library (like os.date and os.time) and only 
exclude the problematic ones (os.execute etc.).

  -Christian

[Pipmak-Users] a clock

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

Hi

I added the chapter "a clock" to the proposals page in the wiki. (Which
tells no more than this mail, so you do not need to look it up just for
reading.)

When I play a game in fullscreen mode, I always have to keep my watch
ready. So I think it would be nice if the player could simply hit a key
to get the time.

I think Pipmak should, by default, display the time if the user hits T.
Is someone else interested in such a feature?

How can this be implemented? Using lua fails, because the os package
seems to be missing in Pipmak.

Greetings
Urs

Re: [Pipmak-Users] Node images

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

Urs Holzer wrote:
> So it would be good if I could do something like
> 
> cubic { 
> state.light .. "1.jpeg", 
> state.light .. "2.jpeg", 
> state.light .. "3.jpeg",
> ....
> 
> Is this possible? 

Apparently you haven't tried it? Yes, this is possible. You can use any 
Lua expression that evaluates to a string at any place where a string is 
expected (and likewise for all other data types). Don't forget that 
"cubic" is just a function and "{...}" is just one way of specifying a 
table, so, assuming that state.light is a boolean value, you could also 
write something like

   cubic(state.light and {"1l.jpeg", ... } or {"1d.jpeg", ... })

(the parentheses are necessary if the opening brace doesn't immediately 
follow "cubic")

or

   if state.light then
     cubic {"1l.jpeg", ... }
   else
     cubix {"1d.jpeg", ... }
   end

However, I wouldn't really call that "changing the node images", since 
it only takes effect when the node is loaded. If you want the change to 
happen while that node is displayed, you must reload it 
(pipmak.gotonode(pipmak.getcurrentnode())). There's currently no way of 
changing the node background images "on the fly".

  -Christian

[Pipmak-Users] Node images

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

Hi

Is it possible to change the images of nodes? Consider for example a
node with

cubic { "1.jpeg", "2.jpeg", "3.jpeg", "4.jpeg", "5.jpeg", "6.jpeg" }

I am in the situation, that the lighting of my game world can change.
The functionality of all nodes is independent of the lighting. However,
changing the lighting changes the images of all sides of all cubic
nodes.
So it would be good if I could do something like

cubic { 
state.light .. "1.jpeg", 
state.light .. "2.jpeg", 
state.light .. "3.jpeg",
...

Is this possible? 

Re: [Pipmak-Users] File name limitations

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

Christian Walther wrote:
> Pipmak is currently officially supported on Mac OS X (>= 10.3.9),
> Linux, and Windows (>= 98). I don't know offhand what the limitations
> of these OSes and/or their usual file systems are. If you want to be
> paranoid, stick to something like [a-zA-Z0-9_-] and a maximum length
> of 31 characters. More importantly, make sure not to depend on case
> sensitivity: having two files that only differ in case won't work on a
> case-insensitive file system (usual on Mac OS and Windows), referring
> to a file using different case than what it's actually named won't
> work on a case-sensitive file system (usual on Linux and other
> Unixes).
> 
> On the other hand, if your project is zipped, the file system
> limitations play no role at all. You're only limited by the ZIP format
> itself. (Whose limitations I don't remember either - I guess you
> should find them somewhere in the specification,
> <http://www.pkware.com/documents/casestudies/APPNOTE.TXT>.)

Thank you! This helps me very much.

Re: [Pipmak-Users] File name limitations

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

Urs Holzer wrote:
> Different platforms have different filename limitations. Which
> characters should I use for filenames and how long should they be at
> maximum? I don't want that my game does not run on a platform where
> pipmak works, only because of unsupported filenames.

Pipmak is currently officially supported on Mac OS X (>= 10.3.9), Linux, 
and Windows (>= 98). I don't know offhand what the limitations of these 
OSes and/or their usual file systems are. If you want to be paranoid, 
stick to something like [a-zA-Z0-9_-] and a maximum length of 31 
characters. More importantly, make sure not to depend on case 
sensitivity: having two files that only differ in case won't work on a 
case-insensitive file system (usual on Mac OS and Windows), referring to 
a file using different case than what it's actually named won't work on 
a case-sensitive file system (usual on Linux and other Unixes).

On the other hand, if your project is zipped, the file system 
limitations play no role at all. You're only limited by the ZIP format 
itself. (Whose limitations I don't remember either - I guess you should 
find them somewhere in the specification, 
<http://www.pkware.com/documents/casestudies/APPNOTE.TXT>.)

  -Christian

[Pipmak-Users] File name limitations

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

Hello

One more question: Different platforms have different filename
limitations. Which characters should I use for filenames and how long
should they be at maximum? I don't want that my game does not run on a
platform where pipmak works, only because of unsupported filenames.

Re: [Pipmak-Users] Node names

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

Urs Holzer wrote:
> The nodes must be named by numbers, right? Are there any further
> restrictions? Does it matter if there are some numbers in between that
> are no nodes? I.e. does it matter if there are the nodes 1, 2, 4, 5 but
> if there is no node 3?

This is perfectly acceptable. The numbers do not need to be consecutive 
(as seen in the demo project).

> Which is the highest number possible? I.e. do you expect it to be a 32-bit integer?

Good question. The node IDs are stored as int on the C side and as 
double on the Lua side, so that should allow you 1 to 2147483647 on a 
typical 32-bit platform. Unless there are any other limitations in the 
code that I've missed right now. However, there are no checks for this, 
so using higher numbers might get you unpredictable results.

Zero and negatives are reserved for internal use (main menu, Lua command 
line, etc.).

> Sorry if this question is answered by the documentation.

It actually isn't (at least not clear enough). I'll add a note about it.

  -Christian

[Pipmak-Users] Node names

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

Hello

The nodes must be named by numbers, right? Are there any further
restrictions? Does it matter if there are some numbers in between that
are no nodes? I.e. does it matter if there are the nodes 1, 2, 4, 5 but
if there is no node 3? Which is the highest number possible? I.e. do
you expect it to be a 32-bit integer?

Sorry if this question is answered by the documentation. I don't have
much time right now to read the documentation, but I need to know how I
have to name my nodes now. ;-)

Greetings
Urs

Re: [Pipmak-Users] [pipmak-users] Screenshots

[Riko-kun <wa...@ma...>]

I understand this. I was just asking if there is such option so i'm not
searching for something that doesn't exist ^_^;;
I can manage without it, just tought it woul'd be nice. Thanks you for your
answers.
Marek


Christian Walther wrote:
> 
> Riko-kun wrote:
>> Well yeah, i woul'd like to have this feature. It woul'd be greate for
>> posting images on blendernations or something ^_^ I know i can grab it
>> using
>> printscreen, but then i have to crop it and save it in separate prog and
>> i'm
>> somehow lazy to do that ^_^
> 
> OK... to be honest, I don't see that use as a high priority feature. I 
> thought you wanted to use the screenshot within Pipmak, which wouldn't 
> be possible with externally taken screenshots.
> 
> The feature you want may come about as a side effect when PNG saving 
> (for painted hotspot maps) and internal screenshotting (for saving a 
> screenshot in a saved game file) are implemented, but these aren't very 
> high on my priority list right now. Of course, contributions are always 
> welcome...
> 
> You might want to look for a screenshot application that lets you set a 
> capture rectangle once and reuse it for many shots. I don't know any for 
> Windows, but I would assume there are dozens. (FRAPS perhaps?)
> 
>   -Christian
> 
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Pipmak-Users mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.user
> https://lists.sourceforge.net/lists/listinfo/pipmak-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Screenshots-tp14243576p14264459.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: [Pipmak-Users] [pipmak-users] Screenshots

[Riko-kun <wa...@ma...>]

Yeah, i know about this option, but it still take window border...
Thanks anyway.


Stefan Gro=C3=9Fhauser-2 wrote:
>=20
>> using printscreen, but then i have to crop it and save it in separate
>> prog
>> and i'm somehow lazy to do that ^_^
>=20
> Do you know that Alt+PrintScreen grabs only the focused window?
>=20
> Stefan
>=20
>=20
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Pipmak-Users mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.user
> https://lists.sourceforge.net/lists/listinfo/pipmak-users
>=20
>=20

--=20
View this message in context: http://www.nabble.com/Screenshots-tp14243576p=
14264443.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: [Pipmak-Users] Screenshots

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

Riko-kun wrote:
> Well yeah, i woul'd like to have this feature. It woul'd be greate for
> posting images on blendernations or something ^_^ I know i can grab it using
> printscreen, but then i have to crop it and save it in separate prog and i'm
> somehow lazy to do that ^_^

OK... to be honest, I don't see that use as a high priority feature. I 
thought you wanted to use the screenshot within Pipmak, which wouldn't 
be possible with externally taken screenshots.

The feature you want may come about as a side effect when PNG saving 
(for painted hotspot maps) and internal screenshotting (for saving a 
screenshot in a saved game file) are implemented, but these aren't very 
high on my priority list right now. Of course, contributions are always 
welcome...

You might want to look for a screenshot application that lets you set a 
capture rectangle once and reuse it for many shots. I don't know any for 
Windows, but I would assume there are dozens. (FRAPS perhaps?)

  -Christian

Re: [Pipmak-Users] [pipmak-users] Screenshots

[Stefan <s1s...@st...>]

> using printscreen, but then i have to crop it and save it in separate prog
> and i'm somehow lazy to do that ^_^

Do you know that Alt+PrintScreen grabs only the focused window?

Stefan