pipmak-devel — Development of the Pipmak Game Engine

Re: [Pipmak-Devel] new features in Pipmak

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

Aidan Gauland wrote:
> Hmmmm, now I'm feeling REALLY stupid.  I just realised that I've never tried 
> this! :-/  I hope I didn't make you waste any time.

So it works for you too? All the better. No worries, I'll file this as a 
success under "regression testing". ;)

  -Christian

Re: [Pipmak-Devel] new features in Pipmak

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

Christian Walther wrote:
> Aidan Gauland wrote:
>> Christian Walther wrote:
>>> How about adding a "duration" method to sounds, so that you could query 
>>> the duration and use pipmak.schedule? That should be trivial.
>> That should work just fine for what I want to do, since I don't need
>> *seamless* concatenation of sounds.
> 
> Good, I'll add that when I get around to it.
> 
>> Maybe I should explain it in a different way: parts of the engine state that 
>> aren't game-specific (i.e. joystick speed, screen resolution, mouse mode, 
>> etc.) don't get saved.
> 
> That must be a bug. They're supposed to be saved. I'll see if I can 
> reproduce it.

Hmmmm, now I'm feeling REALLY stupid.  I just realised that I've never tried 
this! :-/  I hope I didn't make you waste any time.

Re: [Pipmak-Devel] new features in Pipmak

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

Christian Walther wrote:
>>> How about adding a "duration" method to sounds, so that you could query 
>>> the duration and use pipmak.schedule?

This is in SVN as r204 (barely tested).

>> parts of the engine state ...  don't get saved.
> 
> I'll see if I can reproduce it.

I can't - seems to work properly for me, in the case I tested. Could I 
have a look at one of your saved game files (preferably one from the 
demo project, if you can reproduce it there)? Here's one of mine to 
test, it should set the video mode to fullscreen 1024x640, joystick 
speed to 16, mouse mode to direct, and other settings as follows (this 
is its deserialized form):

{
	["overlays"] = {
		[1] = 50
	}
	["path"] = "/Users/cwalther/Documents/Mac OS 
X/Pipmak/trunk/demo/Demo.pipmak"
	["el"] = -2.1995887756348
	["fov"] = 45
	["w"] = 1024
	["az"] = 11.344421386719
	["state"] = {
		["lamp1on"] = false
		["welcomed"] = true
		["keyinhouse"] = true
		["lamp2on"] = false
		["doorisopen"] = false
		["bridgepos"] = 0
		["inventory"] = {
			[1] = "note"
		}
		["lamp4on"] = false
		["lamp3on"] = false
	}
	["h"] = 640
	["title"] = "Pipmak Demo"
	["joyspeed"] = 16
	["full"] = true
	["mouse"] = 1
	["node"] = 2
	["texfilter"] = 9729
}

  -Christian

Re: [Pipmak-Devel] new features in Pipmak

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

Aidan Gauland wrote:
> Christian Walther wrote:
>> How about adding a "duration" method to sounds, so that you could query 
>> the duration and use pipmak.schedule? That should be trivial.
> 
> That should work just fine for what I want to do, since I don't need
> *seamless* concatenation of sounds.

Good, I'll add that when I get around to it.

> Maybe I should explain it in a different way: parts of the engine state that 
> aren't game-specific (i.e. joystick speed, screen resolution, mouse mode, 
> etc.) don't get saved.

That must be a bug. They're supposed to be saved. I'll see if I can 
reproduce it.

  -Christian

Re: [Pipmak-Devel] new features in Pipmak

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

Christian Walther wrote:
> How about adding a "duration" method to sounds, so that you could query 
> the duration and use pipmak.schedule? That should be trivial.

That should work just fine for what I want to do, since I don't need
*seamless* concatenation of sounds.

> Neither of these approaches would be accurate enough for seamless 
> concatenation of sounds, due to Pipmak's synchronous frame-by-frame 
> design. For that, you'd have to queue the sound buffers into the same 
> OpenAL source, while currently every Pipmak sound has its own source (so 
> that sounds can play concurrently).

> 
> That should be easy to add, but can you elaborate a bit on how you'd use 
> it? I'm not convinced there's no bug involved or there isn't an easier 
> way of achieving your goal.
> 
> Engine settings should be restored automatically from saved game files 
> (if they aren't, that's a bug). For your own custom settings, how is 
> restoring them to the state table not sufficient, what exactly would you 
> need to do in that hypothetical "onloadsavedgame" handler?

Maybe I should explain it in a different way: parts of the engine state that 
aren't game-specific (i.e. joystick speed, screen resolution, mouse mode, 
etc.) don't get saved.  So I was thinking of saving the user-specified values 
for these variables in the state table, but then there's no way to 
automatically change the engine state when a saved game is loaded.

So, basically, I just want a way to save the *entire* engine state in a saved 
game file.

Re: [Pipmak-Devel] new features in Pipmak

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

Aidan Gauland wrote:
> 1.
> Problem: Running Lua code immediately after a certain sound stops playing.
> 
> Specific instance: In node 122, I want to make the a button pulse to a 
> heartbeat sound, which is started by moving the mouse over a hotspot, and then 
> started again when the sound stops playing.  I could use Pipmak schedule, but 
> I'd have to hard-code the duration of the sound file, and, besides, that would 
> leave a little more room for accumulated time-sync errors.
> 
> Possible Solution: Giving sounds something like the onenternode handler for nodes.

That sounds like a good idea. To implement it, however, it seems that 
you'd have to poll OpenAL whether the sound is still playing, and you 
could just as well do that directly from Lua (sound:playing() method).

How about adding a "duration" method to sounds, so that you could query 
the duration and use pipmak.schedule? That should be trivial.

Neither of these approaches would be accurate enough for seamless 
concatenation of sounds, due to Pipmak's synchronous frame-by-frame 
design. For that, you'd have to queue the sound buffers into the same 
OpenAL source, while currently every Pipmak sound has its own source (so 
that sounds can play concurrently).

> 2.
> Problem: Restoring engine settings from variables in the state table (specific 
> to a particular Pipmak project file).
> 
> Specific instance: I have a settings node (121), but the settings don't 
> persist between sessions (i.e. they're lost when you save and resume a game).
> 
> Possible Solution: Adding a handler equivelant to onopenproject that is run 
> when opening a saved game.

That should be easy to add, but can you elaborate a bit on how you'd use 
it? I'm not convinced there's no bug involved or there isn't an easier 
way of achieving your goal.

Engine settings should be restored automatically from saved game files 
(if they aren't, that's a bug). For your own custom settings, how is 
restoring them to the state table not sufficient, what exactly would you 
need to do in that hypothetical "onloadsavedgame" handler?

  -Christian

Re: [Pipmak-Devel] new features in Pipmak

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

Andrea Viarengo wrote:
> Hi Aidan,
> 
>      Running Lua code immediately after a certain sound stops playing.
> 
> 
> I think that adding this possibility can be very useful!
> 
> It would be useful also if someone would to concatenate different sounds 
> (when finish one, then start another).
> For example, some time ago I tried to add voice messages, and I didn't 
> want to record a sound for each message,
> but I wanted to compose the message using a dictionary of words...(like 
> TomTom do....)
> So the message "the door is closed" was composed by 4 sounds played in 
> sequence "the" "door" "is" "closed",
> but this is difficult with actual pipmak sound APIs.
> 
> One possible implementation could be adding the method "onsoundstop"
> 
> mysound = sound "mysound.ogg"
> mysound:onsoundstop (
>      function ()
>      ....
>      end
> )
> 
> Another implementation:
> 
> onsoundstop( function(sound)
>     if sound:getfilename() == "sound1.ogg" then ..... end
>     if sound:getfilename() == "sound2.ogg" then ..... end
> end
> )
> 
> offcourse adding also the method getfilename()

I like the first one.  No idea where to start with putting this in Pipmak 
though.  It would probably be pretty simple once I get started.


>     2.
>     Problem: Restoring engine settings from variables in the state table
>     (specific
>     to a particular Pipmak project file).
> 
> 
> I think that the simple way should be add the possibility to read/write 
> text file....I asked to add this to Pipmak some time ago,
> but Christian have an hard position about that.....
> Off course, if you really want, you can use lua loadlib function  and 
> write a DLL or SO lib file to add file read/write API.
> I have already writen a DLL to do this (sorry just for Windows....), if 
> you need it I can send you.

I don't need an IO API, I just need a way of triggering the execution of Lua 
code when the user opens a saved game for that particular project file.

>  
> 
> Bye,
> 
> Andrea

Re: [Pipmak-Devel] new features in Pipmak

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

Hi Aidan,

 Running Lua code immediately after a certain sound stops playing.
>

I think that adding this possibility can be very useful!

It would be useful also if someone would to concatenate different sounds
(when finish one, then start another).
For example, some time ago I tried to add voice messages, and I didn't want
to record a sound for each message,
but I wanted to compose the message using a dictionary of words...(like
TomTom do....)
So the message "the door is closed" was composed by 4 sounds played in
sequence "the" "door" "is" "closed",
but this is difficult with actual pipmak sound APIs.

One possible implementation could be adding the method "onsoundstop"

mysound = sound "mysound.ogg"
mysound:onsoundstop (
     function ()
     ....
     end
)

Another implementation:

onsoundstop( function(sound)
    if sound:getfilename() == "sound1.ogg" then ..... end
    if sound:getfilename() == "sound2.ogg" then ..... end
end
)

offcourse adding also the method getfilename()


>
> 2.
> Problem: Restoring engine settings from variables in the state table
> (specific
> to a particular Pipmak project file).
>
>
I think that the simple way should be add the possibility to read/write text
file....I asked to add this to Pipmak some time ago,
but Christian have an hard position about that.....
Off course, if you really want, you can use lua loadlib function  and write
a DLL or SO lib file to add file read/write API.
I have already writen a DLL to do this (sorry just for Windows....), if you
need it I can send you.


Bye,

Andrea

[Pipmak-Devel] new features in Pipmak

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

Hello,

  I have reached a point with my game where I can't think of a way to do what 
I want with Pipmak's current capabilities.

1.
Problem: Running Lua code immediately after a certain sound stops playing.

Specific instance: In node 122, I want to make the a button pulse to a 
heartbeat sound, which is started by moving the mouse over a hotspot, and then 
started again when the sound stops playing.  I could use Pipmak schedule, but 
I'd have to hard-code the duration of the sound file, and, besides, that would 
leave a little more room for accumulated time-sync errors.

Possible Solution: Giving sounds something like the onenternode handler for nodes.

2.
Problem: Restoring engine settings from variables in the state table (specific 
to a particular Pipmak project file).

Specific instance: I have a settings node (121), but the settings don't 
persist between sessions (i.e. they're lost when you save and resume a game).

Possible Solution: Adding a handler equivelant to onopenproject that is run 
when opening a saved game.

  Would anyone else find features like these useful?  Could these be easily 
implemented in Pipmak?  Do we just have too much spare time on our hands? :)

  -Aidan

Re: [Pipmak-Devel] The Pipmak Make setup for Linux

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

Aidan Gauland wrote:
> # A wrapper script for Pipmak on UNIX systems.  It makes sure Pipmak gets the
> # full path to project files given to it (if any).

Of course, the better solution would be to fix Pipmak's inability to 
deal with relative paths on the command line. Thanks for bringing that 
bug to my attention! I wonder why I never noticed that...

  -Christian

Re: [Pipmak-Devel] The Pipmak Make setup for Linux

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

Aidan Gauland wrote:
> So if I add the line...
> 
> export SHELL=/bin/bash
> 
> ....to the top of the Makefile, it runs, and actually finishes.
> 
> Since the Makefile for the Pipmak documentation uses some bash specific 
> features (i.e. is not 100% POSIX compliant), should this line be added to the 
> documentation Makefile?

I would suggest that instead the Makefile be changed so that it runs on 
any POSIX shell.

> I think that might be best, so that the EXACT SAME file is packaged with each 
> OS build of Pipmak.  I don't know if there would be any slight differences if 
> there were different people generating Reference.pdf on different systems, but 
> it would probably best to try to avoid that for the official release.

Agreed.

  -Christian

Re: [Pipmak-Devel] The Pipmak Make setup for Linux

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

Christian Walther wrote:
> Aidan Gauland wrote:
>> when I type "make" in "pipmak/documentation/" it seems to run
>> something that looks like it's dealing with LATEX in an infinite
>> loop
> 
> The loop isn't supposed to be infinite. It's supposed to loop until the 
> .toc, .aux, and .ind files stop changing. Two or three times through the 
> loop should be sufficient for that. The files depend on each other in a 
> roundabout way: the first pdflatex run creates Reference.toc, 
> Reference.idx, and an unfinished version of Reference.pdf. Then 
> makeindex generates Reference.ind from Reference.idx. The second run of 
> pdflatex integrates Reference.toc and Reference.ind to generate an 
> updated version of Reference.pdf. Or something like that. I don't 
> remember what the .aux file is for, perhaps section links.

Ok, I figured out what the problem was: By default, make uses /bin/sh as the
shell, and that is very often, on Unix systems, a link to the bash binary, but
on some Linux configurations, that is instead a link to (or is the binary) a
more stripped down, POSIX compliant shell that isn't compatable with all bash
scripts.  So if I add the line...

export SHELL=/bin/bash

...to the top of the Makefile, it runs, and actually finishes.

Since the Makefile for the Pipmak documentation uses some bash specific 
features (i.e. is not 100% POSIX compliant), should this line be added to the 
documentation Makefile?

> 
>> but when I run "pdflatex Reference.tex" it seems to generate
>> Reference.pdf, Reference.aux, Reference.idx, Reference.log,
>> Reference.out, and Reference.toc just fine.
> 
> But I bet that Reference.pdf has incomplete or missing table of 
> contents, index, or section links.
> 
>> Is this okay for putting in the Pipmak releases?
> 
> If you don't want to fiddle with the LaTeX stuff, you could package the 
> Reference.pdf generated by me. We can talk about how to best organize that.

I think that might be best, so that the EXACT SAME file is packaged with each 
OS build of Pipmak.  I don't know if there would be any slight differences if 
there were different people generating Reference.pdf on different systems, but 
it would probably best to try to avoid that for the official release.

> 
>>> That looks like it only runs if the current working directory is the 
>>> directory that contains pipmak-bin and libs. Is that acceptable?
>> Hmmm, maybe not.  I could put pipmak-bin and libs in a directory called
>> something like "data", and leave the wrapper script "pipmak" where it is.
> 
> How would that solve the problem?
> 
>> I guess the best way to find out works best is to let Linux users try
>> it out, and make changes based on feedback (on the Pipmak users
>> mailing list).
> 
> OK. I'm still trying to find out how we would publish such test 
> packages. SourceForge doesn't want us to release files on the web site, 
> and using the file release systems where each release will be kept 
> around forever doesn't sound right either. I somehow seem to remember 
> that SourceForge had a specific facility for releasing nightly builds, 
> but I can't find any trace of it now.
> 
>   -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-Devel mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
> 

Re: [Pipmak-Devel] The Pipmak Make setup for Linux

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

Aidan Gauland wrote:
> when I type "make" in "pipmak/documentation/" it seems to run
> something that looks like it's dealing with LATEX in an infinite
> loop

The loop isn't supposed to be infinite. It's supposed to loop until the 
.toc, .aux, and .ind files stop changing. Two or three times through the 
loop should be sufficient for that. The files depend on each other in a 
roundabout way: the first pdflatex run creates Reference.toc, 
Reference.idx, and an unfinished version of Reference.pdf. Then 
makeindex generates Reference.ind from Reference.idx. The second run of 
pdflatex integrates Reference.toc and Reference.ind to generate an 
updated version of Reference.pdf. Or something like that. I don't 
remember what the .aux file is for, perhaps section links.

> but when I run "pdflatex Reference.tex" it seems to generate
> Reference.pdf, Reference.aux, Reference.idx, Reference.log,
> Reference.out, and Reference.toc just fine.

But I bet that Reference.pdf has incomplete or missing table of 
contents, index, or section links.

> Is this okay for putting in the Pipmak releases?

If you don't want to fiddle with the LaTeX stuff, you could package the 
Reference.pdf generated by me. We can talk about how to best organize that.

>> That looks like it only runs if the current working directory is the 
>> directory that contains pipmak-bin and libs. Is that acceptable?
> 
> Hmmm, maybe not.  I could put pipmak-bin and libs in a directory called
> something like "data", and leave the wrapper script "pipmak" where it is.

How would that solve the problem?

> I guess the best way to find out works best is to let Linux users try
> it out, and make changes based on feedback (on the Pipmak users
> mailing list).

OK. I'm still trying to find out how we would publish such test 
packages. SourceForge doesn't want us to release files on the web site, 
and using the file release systems where each release will be kept 
around forever doesn't sound right either. I somehow seem to remember 
that SourceForge had a specific facility for releasing nightly builds, 
but I can't find any trace of it now.

  -Christian

Re: [Pipmak-Devel] The Pipmak Make setup for Linux

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

Christian Walther wrote:
> Aidan Gauland wrote:
>> I'll take over building the Linux binary release, if that would make things
>> easier. 
> 
> That would be very welcome, let's see how that goes. One of the main 
> reasons why I release so rarely is the effort it takes to build and test 
> on all platforms. Distributing that burden onto more shoulders should 
> make things faster. (It also means more management duties for me, 
> getting away a bit from my hermit programmer attitude. We'll see how I 
> cope with that. :) )
> 
> If you tell me your SourceForge user name (make one at 
> <http://sourceforge.net/account/registration/> if you don't already have 
> one), I'll give you write access to the SVN repository.

My SourceForge username is wgsilkie, but hang on a minute, when I type "make"
in "pipmak/documentation/" it seems to run something that looks like it's
dealing with LATEX in an infinite loop, but when I run "pdflatex
Reference.tex" it seems to generate Reference.pdf, Reference.aux,
Reference.idx, Reference.log, Reference.out, and Reference.toc just fine.  Is
this okay for putting in the Pipmak releases?

> 
>>> I don't see a Makefile here, so I can't comment in detail...
>> I'll send that now.
> 
> I haven't tested it, but it looks OK. If you commit it, don't forget to 
> update Building.txt. One thing I wonder, wouldn't it be more elegant to 
> do the uncomment-this-comment-out-that sections using ifs and a variable 
> set on the command line (like 'version' and 'dependencies')?
> 
>> And the wrapper script.
> 
> That looks like it only runs if the current working directory is the 
> directory that contains pipmak-bin and libs. Is that acceptable?

Hmmm, maybe not.  I could put pipmak-bin and libs in a directory called
something like "data", and leave the wrapper script "pipmak" where it is.  Or,
then again, maybe that would be needlessly redundant.  I guess the best way to
find out works best is to let Linux users try it out, and make changes based
on feedback (on the Pipmak users mailing list).

> 
>>> That seems to have been the usual approach for closed-source games. 
>>> However, I seem to remember Gabriele Greco posting that he had some 
>>> problems with that because some newer distributions used that variable 
>>> for system purposes, or something. Have you happened on this in your 
>>> research?
>> I've not heard of that.  I thought Linux systems used something else.  But
>> even if that is a problem, I can easily avoid that, by appending to that
>> variable, rather than overwriting it.
> 
> For reference, since I just have it in front of me, that post is here: 
> <http://thread.gmane.org/gmane.comp.lib.sdl/35714/focus=35778>
> 
>> And by the way, I tried searching the SDL mailing list archives, but it 
>> wasn't working for me.

I was just using the archive that the SDL website lead me to, but now that
I've tried Gmane, I'm having no trouble.  Thanks.

> 
> What archive were you using? Gmane works fine for me: 
> <http://search.gmane.org/?query=&author=Gabriele+Greco&group=gmane.comp.lib.sdl&sort=date&DEFAULTOP=and> 
> (I hope Gabriele doesn't mind me using him as a generic search term, but 
> it seems that he reliably has at least one post in every thread relevant 
> to this topic :) )
> 
>   -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-Devel mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
> 

Re: [Pipmak-Devel] The Pipmak Make setup for Linux

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

Aidan Gauland wrote:
> I'll take over building the Linux binary release, if that would make things
> easier. 

That would be very welcome, let's see how that goes. One of the main 
reasons why I release so rarely is the effort it takes to build and test 
on all platforms. Distributing that burden onto more shoulders should 
make things faster. (It also means more management duties for me, 
getting away a bit from my hermit programmer attitude. We'll see how I 
cope with that. :) )

If you tell me your SourceForge user name (make one at 
<http://sourceforge.net/account/registration/> if you don't already have 
one), I'll give you write access to the SVN repository.

>> I don't see a Makefile here, so I can't comment in detail...
> 
> I'll send that now.

I haven't tested it, but it looks OK. If you commit it, don't forget to 
update Building.txt. One thing I wonder, wouldn't it be more elegant to 
do the uncomment-this-comment-out-that sections using ifs and a variable 
set on the command line (like 'version' and 'dependencies')?

> And the wrapper script.

That looks like it only runs if the current working directory is the 
directory that contains pipmak-bin and libs. Is that acceptable?

>> That seems to have been the usual approach for closed-source games. 
>> However, I seem to remember Gabriele Greco posting that he had some 
>> problems with that because some newer distributions used that variable 
>> for system purposes, or something. Have you happened on this in your 
>> research?
> 
> I've not heard of that.  I thought Linux systems used something else.  But
> even if that is a problem, I can easily avoid that, by appending to that
> variable, rather than overwriting it.

For reference, since I just have it in front of me, that post is here: 
<http://thread.gmane.org/gmane.comp.lib.sdl/35714/focus=35778>

> And by the way, I tried searching the SDL mailing list archives, but it 
> wasn't working for me.

What archive were you using? Gmane works fine for me: 
<http://search.gmane.org/?query=&author=Gabriele+Greco&group=gmane.comp.lib.sdl&sort=date&DEFAULTOP=and> 
(I hope Gabriele doesn't mind me using him as a generic search term, but 
it seems that he reliably has at least one post in every thread relevant 
to this topic :) )

  -Christian

Re: [Pipmak-Devel] The Pipmak Make setup for Linux

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

Christian Walther wrote:
> Aidan Gauland wrote:
>>   Ok, I have.. more than "tweaked" the Pipmak Makefile for building on Linux,
>> and here's how it works...
>>
>> ...
>>
>>   But what do all you other Pipmak users/developers think of this?
> 
> I don't see a Makefile here, so I can't comment in detail...

I'll send that now. :-D  And the wrapper script.

> 
> Generally, I don't really have an opinion either way. I lack the 
> experience with Linux to tell whether that is the approach that leads to 
> the best compatibility with different distributions. As long as either 
> a) it does not get much more difficult for me to build the binary 
> releases or b) you take over building of the binary releases, I'm open 
> to trying this. (Not for the 0.2.7 release though, which I am planning 
> on getting done this weekend.)

I'll take over building the Linux binary release, if that would make things
easier.

> 
>> The wrapper script (just a shell script) sets the LD_LIBRARY_PATH
>> environment variable to look in the libs folder that was created earlier, and
>> executes pipmak-bin.
> 
> That seems to have been the usual approach for closed-source games. 
> However, I seem to remember Gabriele Greco posting that he had some 
> problems with that because some newer distributions used that variable 
> for system purposes, or something. Have you happened on this in your 
> research?

I've not heard of that.  I thought Linux systems used something else.  But
even if that is a problem, I can easily avoid that, by appending to that
variable, rather than overwriting it.

And by the way, I tried searching the SDL mailing list archives, but it wasn't 
working for me.

Re: [Pipmak-Devel] The Pipmak Make setup for Linux

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

Aidan Gauland wrote:
>   Ok, I have.. more than "tweaked" the Pipmak Makefile for building on Linux,
> and here's how it works...
> 
> ...
> 
>   But what do all you other Pipmak users/developers think of this?

I don't see a Makefile here, so I can't comment in detail...

Generally, I don't really have an opinion either way. I lack the 
experience with Linux to tell whether that is the approach that leads to 
the best compatibility with different distributions. As long as either 
a) it does not get much more difficult for me to build the binary 
releases or b) you take over building of the binary releases, I'm open 
to trying this. (Not for the 0.2.7 release though, which I am planning 
on getting done this weekend.)

> The wrapper script (just a shell script) sets the LD_LIBRARY_PATH
> environment variable to look in the libs folder that was created earlier, and
> executes pipmak-bin.

That seems to have been the usual approach for closed-source games. 
However, I seem to remember Gabriele Greco posting that he had some 
problems with that because some newer distributions used that variable 
for system purposes, or something. Have you happened on this in your 
research?

Thanks for your work!

  -Christian

[Pipmak-Devel] The Pipmak Make setup for Linux

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

Hello,

  Ok, I have.. more than "tweaked" the Pipmak Makefile for building on Linux,
and here's how it works...

  Note: Skip step 1 if you're going to use your system-wide shared libraries,
but it still links to Lua statically so you still have to compile Lua.

  Step 1: Compile libogg, libvorbis, physfs, and
openal with the --disable-static option passed to the configure script.

  Step 2: Compile Lua.  (Its make system is different from most libraries,
and doesn't have the option to disable shared libraries.)

  Step 3: Move or symolically link each of those libraries to
pipmak/build-linux, truncating the version number from the directory name.
Example:
ln -s /path/to/libvorbis-1.2.0 build-linux/libvorbis
OR
mv /path/to/libvorbis-1.2.0 build-linux/libvorbis

  Step 4: Now if you're building for the official tarball release, just type
make version=x.y.z release
as before.  But if you want to build Pipmak from source for yourself, using
your system-wide shared libraries, then you will need to comment and uncomment
a few lines in the Makefile.  The lines are clearly marked.  After that, run
make, and it will build Pipmak against your system-wide libraries (assuming
you have installed them correctly).

  What actually happens when you run "make version=x.y.z release" is (in
addition to what it did with the original Makefile) is copies the shared
object files for the libraries it needs to pipmak-x.y.z/libs/ and copies a
wrapper script to pipmak-x.y.z/pipmak and the actual Pipmak binary is named
pipmak-bin.  The wrapper script (just a shell script) sets the LD_LIBRARY_PATH
environment variable to look in the libs folder that was created earlier, and
executes pipmak-bin.

  However, I still left it so that it links to Lua statically, not because I
think it an uncommon library, but because we will want Pipmak to be using a
properly configured build of Lua (right?).  For example I found that it
doesn't enable loadlib by default in the configuration file.

  So why did I do it this way instead of linking to all of these libraries
statically?  Because (at least on my system, I haven't done extensive testing)
if the system already has the libraries installed system-wide, then those are
used instead of the .so files packaged with Pipmak, so a user, at their
option, can remove the .so files packaged with Pipmak, or replace them with
their own.  And after talking to some other Linux users, I understand that
when you try to link to several libraries statically, especially when some
libraries depend on others, you get into what some call dependency hell.
That's when you have to keep trying to resolve dependencies of dependencies,
until it's nearly impossible to figure out what it is that you're missing.
So the answer is, in short, because it's simpler.

  But what do all you other Pipmak users/developers think of this?

  -Aidan

Re: [Pipmak-Devel] Transition interrupts

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

  I actually missed something when I was testing this: the bug only 
shows up if I move the mouse when clicking "Cancel".  And I made the 
erroneous  assumption that the openProject function opened a dialog at 
the same time as the saveGame dialog.

  Anyway, I think I did it properly this time.  Try the patch with this 
message.

  -Aidan

Christian Walther wrote:
> Aidan Gauland wrote:
>>  Ok, here's a patch to fix this.
> 
> Does that really fix it?? The warp you've inserted happens before the 
> dialog is opened, not after, unlike in the save dialog case that you 
> fixed in r180. (Just wondering, I haven't tested 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-Devel mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
> 

Re: [Pipmak-Devel] direct mouse mode bug

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

Aidan Gauland wrote:
>   I'm moving this thread to the developers' list.  So, any ideas as to 
> where the bug with panning in direct mouse mode is coming from?

My first guess would be that we forget to grab the mouse somewhere, so 
that the (invisble) system cursor is still confined to the screen and we 
don't get unclamped relative motion events.

I'm not ruling out the possibility that it's an SDL bug (I've had to fix 
a few of them in this area over the years), but we should look in our 
own code first.

  -Christian

Re: [Pipmak-Devel] Transition interrupts

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

Aidan Gauland wrote:
>  Ok, here's a patch to fix this.

Does that really fix it?? The warp you've inserted happens before the 
dialog is opened, not after, unlike in the save dialog case that you 
fixed in r180. (Just wondering, I haven't tested it.)

  -Christian

[Pipmak-Devel] direct mouse mode bug

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

Hi,

  I'm moving this thread to the developers' list.  So, any ideas as to 
where the bug with panning in direct mouse mode is coming from?

  -Aidan

Re: [Pipmak-Devel] Transition interrupts

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

  Ok, here's a patch to fix this.  I generated the patch from revision 180.

  Since you're using Linux, too, can you please test this?

  -Aidan

Aidan Gauland wrote:
> Right!  I'll get on that.  :)
> 
> Urs Holzer wrote:
>> Urs Holzer wrote:
>>> Christian Walther wrote:
>>>> Aidan Gauland wrote:
>>>>>  And I am sending the patch for my workaround for the bug where
>>>>>  Pipmak
>>>>> grabs the mouse if the user clicks cancel on the save game dialog.
>>>>> Maybe not the best solution, but I don't think it broke anything.
>>>> Thanks, this is committed (without extensive testing): rev. 180.
>>> For the sake of completeness: This fixes the problem on my system and
>>> doesn't seem to create any other problems.
>> However, I just found out that you should do the same thing for the open
>> dialog ;-)
>>
>>
>> -------------------------------------------------------------------------
>> 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-Devel mailing list
>> Pip...@li...
>> news://news.gmane.org/gmane.games.devel.pipmak.devel
>> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
>>
> 
> -------------------------------------------------------------------------
> 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-Devel mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
> 

Re: [Pipmak-Devel] Transition interrupts

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

Aidan Gauland wrote:
>   Ok, that makes sense, I'm sending another patch (generated r180), 
> which does the same thing as the last one, but with no extra variable.

Thanks, this is in - rev. 181.

> My point is that you might have to take a more general approach to work on as many Linux distributions as possible.

That's exactly what I was trying to do by not requiring system-installed 
versions of Lua and Physfs. It takes a bit more hand work for the 
builder, but we can stick with a single Makefile, which seems more 
maintainable to me than having several ones, or one and a set of patches 
on top of it, for different distributions. That's why I see 
autodetection as a better alternative.

Another point on the topic of working on as many Linux distributions as 
possible: I have never taken any particular steps to make my binary 
releases distribution-independent (which is a somewhat delicate science 
- for more info, see the SDL mailing list archives, the topic comes up 
every now and then there, with links to articles on the web). I just 
build them on my Ubuntu or Fedora boxes, and if they work elsewhere, 
good, if not, people have to live with building from source. If anyone 
would like to spend some effort on this, that would be welcome.

In general, you would be welcome to take over maintenance of the Linux 
build system and the official binary releases. In that case I would give 
you free rein on the makefiles and stuff. I admit that I have been 
treating this with a somewhat reduced priority since Linux is not my 
main day-to-day OS.

  -Christian

Re: [Pipmak-Devel] Transition interrupts

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

Right!  I'll get on that.  :)

Urs Holzer wrote:
> Urs Holzer wrote:
>> Christian Walther wrote:
>>> Aidan Gauland wrote:
>>>>  And I am sending the patch for my workaround for the bug where
>>>>  Pipmak
>>>> grabs the mouse if the user clicks cancel on the save game dialog.
>>>> Maybe not the best solution, but I don't think it broke anything.
>>> Thanks, this is committed (without extensive testing): rev. 180.
>> For the sake of completeness: This fixes the problem on my system and
>> doesn't seem to create any other problems.
> 
> However, I just found out that you should do the same thing for the open
> dialog ;-)
> 
> 
> -------------------------------------------------------------------------
> 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-Devel mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.devel
> https://lists.sourceforge.net/lists/listinfo/pipmak-devel
>