pipmak-devel — Development of the Pipmak Game Engine

Re: [Pipmak-Devel] Transition interrupts

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

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 ;-)

Re: [Pipmak-Devel] Transition interrupts

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

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.

Re: [Pipmak-Devel] Transition interrupts

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

Ok, that was stupid.  I forgot the attachment.  THIS message has it.

Aidan Gauland wrote:
> Christian Walther wrote:
>> Aidan Gauland wrote:
>>> Christian Walther wrote:
>>>> Aidan Gauland wrote:
>>>>>  Using your Lua code, I was able to make changes to Pipmak, so it will 
>>>>> now ignore a click during a transition, but will also ignore the button 
>>>>> up event ONLY if it is from a click DURING a transition.  It would 
>>>>> probably make more sense if you look at my changes.
>>>> Looks good, from the distance (I don't have time to really test it right 
>>>> now). I wonder, would any bad things happen if you'd check for "&& 
>>>> mouseButton != 0" instead of "&& clickDuringTransition == 0" in the 
>>>> SDL_MOUSEBUTTONUP case? Then you could get rid of the new 
>>>> clickDuringTransition variable.
>>>   Wouldn't that just be, in English:  "If a mouse button is down"?
>> "If a mouse button is down from the point of view of Pipmak", yes. Not 
>> necessarily "if a mouse button is physically down", since you skip 
>> setting mouseButton to non-zero at SDL_MOUSEBUTTONDOWN if 
>> TRANSITION_RUNNING.
>>
>>> If another button was still down when one comes up, how would that tell 
>>> us if the click was from before a transition or not?
>> "one mouse button coming up while another one is still down" is not a 
>> mouse-up event from the point of view of Pipmak. Mouse-up doesn't happen 
>> until *all* buttons are up. That's what made most sense to me when I 
>> decided to have Pipmak expose a one-button-mouse interface to projects.
> 
>   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.
> 
>>>>>  Oh, I almost forgot, I'm also sending a patch to the file 
>>>>> build-linux/Makefile, which changes the path to look for the Lua, and 
>>>>> PhysFS libraries.  It changes the paths to where the Debain packages for 
>>>>> these libraries get installed, but I don't know if it would work for 
>>>>> non-Debain Linux systems.
>>>> This means that the instructions in Building.txt wouldn't work anymore. 
>>>> You'd need to change these instructions too. But even then I'm not sure 
>>>> if I want this. Can we rely on all distributions having packages for Lua 
>>>> and Physfs? Perhaps something could be done with automatically 
>>>> determining whether these libraries are present in the system, and 
>>>> otherwise use the ones installed in the build-linux folder according to 
>>>> the instructions? Would it be possible to use system-installed libraries 
>>>> without modifying the makefile by placing symlinks in build-linux?
>>>   I tried that, and it didn't work, but it might, if I changed the make 
>>> file, in which case I might as well change it in the way that I did.
>> OK.
>>
>>>> Also, you're linking Lua and Physfs dynamically now (assuming their 
>>>> Debian packages include dynamic libraries). That's fine when you're 
>>>> compiling from source, but for the distributed binary I'd rather move 
>>>> towards linking more libraries statically, not less, to avoid dependency 
>>>> problems.
>>>>
>>>> Is there a reason for the removal of two empty lines?
>>>   I think Lua is pretty widely available on Linux distributions, but I 
>>> don't know about PhysFS.  And the removal of the two lines is just so 
>>> Emacs doesn't give me a warning.
>> What does that warning say?
> 
> Just something like "suspicious blank line".  Yeah, I know, big help.
> 
>>> What about adding an optional patch for the Makefile?
>> I think it would be easier to maintain if we could either autodetect the 
>> presence of system-installed libraries (do they include pkg-config files 
>> or anything?), or provide a command-line argument to switch to using 
>> them ("make use_system_lua=1 pipmak" or something).
> 
>   I have no idea, I haven't ever used make (except for building other
> people's projects).  But I know that on the distribution Gentoo (not 
> based on Debain), all packages are source, and the package management 
> system is completely different from apt and dpkg (Debians package 
> management tools).  My point is that you might have to take a more 
> general approach to work on as many Linux distributions as possible.
> 
>>   -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
>>
> 
> -------------------------------------------------------------------------
> 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

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

Christian Walther wrote:
> Aidan Gauland wrote:
>> Christian Walther wrote:
>>> Aidan Gauland wrote:
>>>>  Using your Lua code, I was able to make changes to Pipmak, so it will 
>>>> now ignore a click during a transition, but will also ignore the button 
>>>> up event ONLY if it is from a click DURING a transition.  It would 
>>>> probably make more sense if you look at my changes.
>>> Looks good, from the distance (I don't have time to really test it right 
>>> now). I wonder, would any bad things happen if you'd check for "&& 
>>> mouseButton != 0" instead of "&& clickDuringTransition == 0" in the 
>>> SDL_MOUSEBUTTONUP case? Then you could get rid of the new 
>>> clickDuringTransition variable.
>>   Wouldn't that just be, in English:  "If a mouse button is down"?
> 
> "If a mouse button is down from the point of view of Pipmak", yes. Not 
> necessarily "if a mouse button is physically down", since you skip 
> setting mouseButton to non-zero at SDL_MOUSEBUTTONDOWN if 
> TRANSITION_RUNNING.
> 
>> If another button was still down when one comes up, how would that tell 
>> us if the click was from before a transition or not?
> 
> "one mouse button coming up while another one is still down" is not a 
> mouse-up event from the point of view of Pipmak. Mouse-up doesn't happen 
> until *all* buttons are up. That's what made most sense to me when I 
> decided to have Pipmak expose a one-button-mouse interface to projects.

  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.

>>>>  Oh, I almost forgot, I'm also sending a patch to the file 
>>>> build-linux/Makefile, which changes the path to look for the Lua, and 
>>>> PhysFS libraries.  It changes the paths to where the Debain packages for 
>>>> these libraries get installed, but I don't know if it would work for 
>>>> non-Debain Linux systems.
>>> This means that the instructions in Building.txt wouldn't work anymore. 
>>> You'd need to change these instructions too. But even then I'm not sure 
>>> if I want this. Can we rely on all distributions having packages for Lua 
>>> and Physfs? Perhaps something could be done with automatically 
>>> determining whether these libraries are present in the system, and 
>>> otherwise use the ones installed in the build-linux folder according to 
>>> the instructions? Would it be possible to use system-installed libraries 
>>> without modifying the makefile by placing symlinks in build-linux?
>>   I tried that, and it didn't work, but it might, if I changed the make 
>> file, in which case I might as well change it in the way that I did.
> 
> OK.
> 
>>> Also, you're linking Lua and Physfs dynamically now (assuming their 
>>> Debian packages include dynamic libraries). That's fine when you're 
>>> compiling from source, but for the distributed binary I'd rather move 
>>> towards linking more libraries statically, not less, to avoid dependency 
>>> problems.
>>>
>>> Is there a reason for the removal of two empty lines?
>>   I think Lua is pretty widely available on Linux distributions, but I 
>> don't know about PhysFS.  And the removal of the two lines is just so 
>> Emacs doesn't give me a warning.
> 
> What does that warning say?

Just something like "suspicious blank line".  Yeah, I know, big help.

>> What about adding an optional patch for the Makefile?
> 
> I think it would be easier to maintain if we could either autodetect the 
> presence of system-installed libraries (do they include pkg-config files 
> or anything?), or provide a command-line argument to switch to using 
> them ("make use_system_lua=1 pipmak" or something).

  I have no idea, I haven't ever used make (except for building other
people's projects).  But I know that on the distribution Gentoo (not 
based on Debain), all packages are source, and the package management 
system is completely different from apt and dpkg (Debians package 
management tools).  My point is that you might have to take a more 
general approach to work on as many Linux distributions as possible.

> 
>   -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] A strange behaviour: visualization bug or what?

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

Andrea Viarengo wrote:
> Why the rectangular patch (the third) doesn't cut circles exactly half? But it seems moved back?

Let me guess: The rectangle does cut the circles in half. But you're 
using an extremely large field of view and therefore have lots of 
perspective distortion.

Try placing your eye so close to the screen that you actually see it 
under the field of view that you've set the camera to, and you'll see 
that the cylinder looks perfectly normal.

Or try zooming in the camera as far as it will go (5 degrees) and move 
the scene farther away in the y direction so you still see all of it.

> The attached picture is shown what I would have expected ....

You'd expect that with an orthographic camera, or in the limit of FOV -> 
0 for a perspective camera.

  -Christian

Re: [Pipmak-Devel] Transition interrupts

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

Aidan Gauland wrote:
> Christian Walther wrote:
>> Aidan Gauland wrote:
>>>  Using your Lua code, I was able to make changes to Pipmak, so it will 
>>> now ignore a click during a transition, but will also ignore the button 
>>> up event ONLY if it is from a click DURING a transition.  It would 
>>> probably make more sense if you look at my changes.
>> Looks good, from the distance (I don't have time to really test it right 
>> now). I wonder, would any bad things happen if you'd check for "&& 
>> mouseButton != 0" instead of "&& clickDuringTransition == 0" in the 
>> SDL_MOUSEBUTTONUP case? Then you could get rid of the new 
>> clickDuringTransition variable.
> 
>   Wouldn't that just be, in English:  "If a mouse button is down"?

"If a mouse button is down from the point of view of Pipmak", yes. Not 
necessarily "if a mouse button is physically down", since you skip 
setting mouseButton to non-zero at SDL_MOUSEBUTTONDOWN if 
TRANSITION_RUNNING.

> If another button was still down when one comes up, how would that tell 
> us if the click was from before a transition or not?

"one mouse button coming up while another one is still down" is not a 
mouse-up event from the point of view of Pipmak. Mouse-up doesn't happen 
until *all* buttons are up. That's what made most sense to me when I 
decided to have Pipmak expose a one-button-mouse interface to projects.

>>>  Oh, I almost forgot, I'm also sending a patch to the file 
>>> build-linux/Makefile, which changes the path to look for the Lua, and 
>>> PhysFS libraries.  It changes the paths to where the Debain packages for 
>>> these libraries get installed, but I don't know if it would work for 
>>> non-Debain Linux systems.
>> This means that the instructions in Building.txt wouldn't work anymore. 
>> You'd need to change these instructions too. But even then I'm not sure 
>> if I want this. Can we rely on all distributions having packages for Lua 
>> and Physfs? Perhaps something could be done with automatically 
>> determining whether these libraries are present in the system, and 
>> otherwise use the ones installed in the build-linux folder according to 
>> the instructions? Would it be possible to use system-installed libraries 
>> without modifying the makefile by placing symlinks in build-linux?
> 
>   I tried that, and it didn't work, but it might, if I changed the make 
> file, in which case I might as well change it in the way that I did.

OK.

>> Also, you're linking Lua and Physfs dynamically now (assuming their 
>> Debian packages include dynamic libraries). That's fine when you're 
>> compiling from source, but for the distributed binary I'd rather move 
>> towards linking more libraries statically, not less, to avoid dependency 
>> problems.
>>
>> Is there a reason for the removal of two empty lines?
> 
>   I think Lua is pretty widely available on Linux distributions, but I 
> don't know about PhysFS.  And the removal of the two lines is just so 
> Emacs doesn't give ma a warning.

What does that warning say?

> What about adding an optional patch for the Makefile?

I think it would be easier to maintain if we could either autodetect the 
presence of system-installed libraries (do they include pkg-config files 
or anything?), or provide a command-line argument to switch to using 
them ("make use_system_lua=1 pipmak" or something).

  -Christian

Re: [Pipmak-Devel] Transition interrupts

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

Christian Walther wrote:
> Aidan Gauland wrote:
>>  Using your Lua code, I was able to make changes to Pipmak, so it will 
>> now ignore a click during a transition, but will also ignore the button 
>> up event ONLY if it is from a click DURING a transition.  It would 
>> probably make more sense if you look at my changes.
> 
> Looks good, from the distance (I don't have time to really test it right 
> now). I wonder, would any bad things happen if you'd check for "&& 
> mouseButton != 0" instead of "&& clickDuringTransition == 0" in the 
> SDL_MOUSEBUTTONUP case? Then you could get rid of the new 
> clickDuringTransition variable.

  Wouldn't that just be, in English:  "If a mouse button is down"?
If another button was still down when one comes up, how would that tell 
us if the click was from before a transition or not?

>>  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.
> 
>>  I have messed around with my text editor's settings, so it should only 
>> be using tabs now.  Please let me know if it isn't.
> 
> Looks good now. :)
> 
>>  Oh, I almost forgot, I'm also sending a patch to the file 
>> build-linux/Makefile, which changes the path to look for the Lua, and 
>> PhysFS libraries.  It changes the paths to where the Debain packages for 
>> these libraries get installed, but I don't know if it would work for 
>> non-Debain Linux systems.
> 
> This means that the instructions in Building.txt wouldn't work anymore. 
> You'd need to change these instructions too. But even then I'm not sure 
> if I want this. Can we rely on all distributions having packages for Lua 
> and Physfs? Perhaps something could be done with automatically 
> determining whether these libraries are present in the system, and 
> otherwise use the ones installed in the build-linux folder according to 
> the instructions? Would it be possible to use system-installed libraries 
> without modifying the makefile by placing symlinks in build-linux?

  I tried that, and it didn't work, but it might, if I changed the make 
file, in which case I might as well change it in the way that I did.

> Also, you're linking Lua and Physfs dynamically now (assuming their 
> Debian packages include dynamic libraries). That's fine when you're 
> compiling from source, but for the distributed binary I'd rather move 
> towards linking more libraries statically, not less, to avoid dependency 
> problems.
> 
> Is there a reason for the removal of two empty lines?

  I think Lua is pretty widely available on Linux distributions, but I 
don't know about PhysFS.  And the removal of the two lines is just so 
Emacs doesn't give ma a warning.  What about adding an optional patch 
for the Makefile?

>   -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] Transition interrupts

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

Aidan Gauland wrote:
>  Using your Lua code, I was able to make chamges to Pipmak, so it will 
> now ignore a click during a transition, but will also ignore the button 
> up event ONLY if it is from a click DURING a transition.  It would 
> probably make more sense if you look at my changes.

Looks good, from the distance (I don't have time to really test it right 
now). I wonder, would any bad things happen if you'd check for "&& 
mouseButton != 0" instead of "&& clickDuringTransition == 0" in the 
SDL_MOUSEBUTTONUP case? Then you could get rid of the new 
clickDuringTransition variable.

>  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.

>  I have messed around with my text editor's settings, so it should only 
> be using tabs now.  Please let me know if it isn't.

Looks good now. :)

>  Oh, I almost forgot, I'm also sending a patch to the file 
> build-linux/Makefile, which changes the path to look for the Lua, and 
> PhysFS libraries.  It changes the paths to where the Debain packages for 
> these libraries get installed, but I don't know if it would work for 
> non-Debain Linux systems.

This means that the instructions in Building.txt wouldn't work anymore. 
You'd need to change these instructions too. But even then I'm not sure 
if I want this. Can we rely on all distributions having packages for Lua 
and Physfs? Perhaps something could be done with automatically 
determining whether these libraries are present in the system, and 
otherwise use the ones installed in the build-linux folder according to 
the instructions? Would it be possible to use system-installed libraries 
without modifying the makefile by placing symlinks in build-linux?

Also, you're linking Lua and Physfs dynamically now (assuming their 
Debian packages include dynamic libraries). That's fine when you're 
compiling from source, but for the distributed binary I'd rather move 
towards linking more libraries statically, not less, to avoid dependency 
problems.

Is there a reason for the removal of two empty lines?

  -Christian

Re: [Pipmak-Devel] New to Pipmak development, could use some tips

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

shadowphile wrote:
> 1 - After looking around for an IDE I decided to try MinGW Developer Studio. 
> It seems a little stale (comes with no documentation (?!), is somewhat
> minimal, and includes MinGW 3.3.1 as it's latest version.)
> I've been able to compile many of the libraries for pipmak like ogg and
> vorbis using the default compiler.
> After some weirdness though I installed the latest MinGW compiler and tools
> but the IDE gives me an errror when I try to point it to the newer compiler.
> 
> Anybody recommend a better IDE?

 From the point of view of the compiler, MinGW doesn't seem like a bad 
choice, considering that I produce the official Windows build with MinGW 
(with a cross-compiler though, so the makefiles are written with a Unix 
shell environment in mind and probably won't work on MSYS). Andrea has 
done some work on compiling Pipmak with MSVC. So either of these two 
compilers should work without too many problems now.

Can't say much about IDEs for Windows, the only one I'm familiar with is 
MSVC 6 (and I've never tried to use it for Pipmak). There's also the 
cross-platform ones like Eclipse and Code Blocks that I assume should be 
able to work together with the Mingw GCC.

> 2 - I then installed TortoiseSVN, downloaded the latest trunk, started
> working on the compile (still using MinGW 3.3.1).  Haven't gotten to the
> linking yet, but I've been able to compile most of the pipmak files. 
> However, I've been stalled all night with a compiler error in the
> pipmak_windows.c file:  It doesn't seem to like 'DWORD (-1)'.  My C is a
> little rusty, but I'm not sure how I'm supposed to interpret that.  Could
> this be a Linux/Mac convention I need to change?  I'm still assessing the
> magnitude of the conversion process to a native Windows build.
> 
> Here's the total test.c file:
> ____________________________
> #include <windows.h>
> void test(void) {
> 	int attr = DWORD (-1);
> }
> _____________________________
> 
> and here's the error I get:
> "error: parse error before "DWORD"

I don't see the expression "DWORD (-1)" anywhere in pipmak_windows.c, 
but anyway: it looks like you're trying to compile C++ code as C. In 
C++, type(value) is a valid cast, while in C it needs to be (type)value. 
Can you try with (DWORD)(-1)?

  -Christian

[Pipmak-Devel] [pipmak-devel] New to Pipmak development, could use some tips

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

Hi all.  I decided to get my fingers wet with the development side and been
busy all night installing and stuff.
I'm developing on Windows, and I see the project could use a native-side
Windows approach.
I've had some partial luck but I'm running into some weirdness, so I'm just
gonna run several statements out and see what you people think of my setup..

1 - After looking around for an IDE I decided to try MinGW Developer Studio. 
It seems a little stale (comes with no documentation (?!), is somewhat
minimal, and includes MinGW 3.3.1 as it's latest version.)
I've been able to compile many of the libraries for pipmak like ogg and
vorbis using the default compiler.
After some weirdness though I installed the latest MinGW compiler and tools
but the IDE gives me an errror when I try to point it to the newer compiler.

Anybody recommend a better IDE?

2 - I then installed TortoiseSVN, downloaded the latest trunk, started
working on the compile (still using MinGW 3.3.1).  Haven't gotten to the
linking yet, but I've been able to compile most of the pipmak files. 
However, I've been stalled all night with a compiler error in the
pipmak_windows.c file:  It doesn't seem to like 'DWORD (-1)'.  My C is a
little rusty, but I'm not sure how I'm supposed to interpret that.  Could
this be a Linux/Mac convention I need to change?  I'm still assessing the
magnitude of the conversion process to a native Windows build.

Here's the total test.c file:
____________________________
#include <windows.h>
void test(void) {
	int attr = DWORD (-1);
}
_____________________________

and here's the error I get:
"error: parse error before "DWORD"

I was HOPING it was a compiler problem that I could fix by updating to a
much new version, but as I stated above I ran into problems.

I've done a lot more firmware coding than apps, so assume I've got giant
gaping holes in my basic knowledge of building PC-level code and the problem
might be obvious :)

Thanks, and any or all suggestions or comments about tools, approaches,
whatever will be much appreciated.  I'm looking forward to finally getting
to the editing part!
matt 
-- 
View this message in context: http://www.nabble.com/New-to-Pipmak-development%2C-could-use-some-tips-tp15663723p15663723.html
Sent from the pipmak-devel mailing list archive at Nabble.com.

Re: [Pipmak-Devel] Transition interrupts

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

  Using your Lua code, I was able to make chamges to Pipmak, so it will 
now ignore a click during a transition, but will also ignore the button 
up event ONLY if it is from a click DURING a transition.  It would 
probably make more sense if you look at my changes.

  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.

  I have messed around with my text editor's settings, so it should only 
be using tabs now.  Please let me know if it isn't.

  Oh, I almost forgot, I'm also sending a patch to the file 
build-linux/Makefile, which changes the path to look for the Lua, and 
PhysFS libraries.  It changes the paths to where the Debain packages for 
these libraries get installed, but I don't know if it would work for 
non-Debain Linux systems.


Christian Walther wrote:
> Aidan Gauland wrote:
>>  I've managed to do something to the code for handling mouse button 
>> up/down events, which SEEMS to fix the problem of starting a transition 
>> during a transition, but there might still be something more subtle I've 
>> overlooked.  I've attached a patch, generated against revision 179.
> 
> Thanks for looking into this! This solution seems a bit too simplistic, 
> however. Here is a test case where it causes incorrect behavior:
> 
> ---8<--- node.lua ------------------------------------------------------
> 
> slide (pipmak.newimage(640, 480):color(1.0, 0.95, .8):fill())
> 
> local btnimg = pipmak.newimage(100, 40):color(0.5, 0.5, 0.7):fill()
> local btnimgh = pipmak.newimage(100, 40):color(0.7, 0.3, 0.3):fill()
> 
> local indicator = patch { x = 200, y = 100, image = pipmak.newimage(40, 
> 40):color(0.5, 0.8, 0.3):fill() }
> 
> local btn = patch { x = 270, y = 300, image = btnimg }
> handle {
> 	x = 270, y = 300, w = 100, h = 40,
> 	onhilite = function(self, h)
> 		btn:setimage(h and btnimgh or btnimg)
> 	end,
> 	onmousedown = function()
> 		indicator:moveto(200, 100)
> 		pipmak.schedule(2, function()
> 			indicator:moveto(300, 100)
> 			pipmak.dissolve(1, 4)
> 			indicator:moveto(400, 100)
> 			pipmak.schedule(4, function()
> 				indicator:moveto(500, 100)			
> 			end)
> 		end)
> 	end
> }
> 
> ---8<-------------------------------------------------------------------
> 
> The blue rectangle is a button that highlights red when clicked. Mouse 
> down on this button starts the following sequence: The green square 
> resets to position 1. After 2 seconds, it jumps to position 2 and starts 
> fading to position 3. The transition takes 4 seconds, when it's done the 
> green square jumps to position 4.
> 
> When you press the mouse button on the blue button and hold it down 
> until the transition starts, then release it while the transition is 
> running, the button does not properly unhighlight (return from red to 
> blue) since the mouse-up event is suppressed.
> 
> Off the top of my head, here's the behavior I would propose:
> - When the mouse goes down during a transition, the entire click 
> (including mouse up, whether it happens before the end of the transition 
> or after) should be ignored.
> - Not sure if this is necessary: When the mouse is down at the beginning 
> of a transition and goes up during it, the mouse-up event should be 
> delayed until the transition has finished.
> 
> Does that make sense?
> 
> And two general comments:
> - It looks like you still generated the patch "by hand" using diff. If 
> you're using Subversion now (as I assume when you say "revision 179"), 
> it would probably be more convenient to use "svn diff".
> - You're again using a mixture of tabs and spaces for indentation. You 
> won't get commit access until you get this right (tabs only) ;)
> 
>>  And about the bug with grabbing the mouse after closing a dialog...
>> flashback:
>>  > Also, when I bring up the save game dialog with the 'S' key, Pipmak 
>>  >doesn't give me my mouse back, and I have to go to a virtual console 
>>  >and kill Pipmak.  If I add a call to SDL_WM_GrabInput() to ungrab the 
>>  >mouse in the Lua C function which is called when the 'S' key is 
>>  >pressed, that seems to solve this problem.
> 
> Hmm, I thought you fixed that in rev. 179? Or are you talking about the 
> other problem, the one you described as
> 
>> Ahhh, one other thing: If the user brings up a dialog, and then dismisses
>> it, Pipmak seems to do the same thing with grabbing the mouse, even if it's
>> not in the window, and then it is impossible to get the mouse out of the
>> window, until the user brings up another dialog, and closes it when it is
>> over the Pipmak window (so the mouse will be in the Pipmak window when it
>> regrabs the mouse).
> ?
> 
>> I think it might only show wiht GTK.  If I understand this properly, 
>> Pipmak uses GTK when built for Linux, and Aqua when built for Macintosh. 
>>  So that might be why Christian doesn't get this bug.
> 
> Well, it's true that I don't get it on Mac OS, but I don't even get it 
> with GTK on Linux.
> 
>>  If I add a call to the SDL warp mouse function, at the end Lua function 
>> for the save dialog (the one called when the 'S' key is pressed), that 
>> seems to work as a crude workaround, but I don't know how to find a 
>> better solution.
> 
> Just send us that workaround, I'll commit it if it doesn't break 
> anything. Maybe Urs can test it as well, and I'll make sure to test on 
> Ubuntu (where I assume I'll have the same behavior as you on Debian) 
> before the release anyway.
> 
>   -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] [pipmak-devel] Inactivity warning

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

Christian Walther wrote:
> 
> NigeC wrote:
>> Christian Walther wrote:
>>> I probably won't fix the problem with stacked cubic nodes 
>> thats a shame
> 
> Heh, now don't take my quote out of context! ;)
> 
> 
> 
i missed out "for this release" in my last post, so it made it kinda sounded
out of context lol.. sorry

I'm working on getting the rooms/models looking right, depth of field, room
scale etc so I'm a long way off needing any new features and fixes

I looked at Uru last night.. wow its amazing, its a shame its going, i don't
have much time to explore it right now tho :-(
Fingers crossed someone may step in and save it?

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

Re: [Pipmak-Devel] Inactivity warning

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

Urs Holzer wrote:
> Christian Walther wrote:
> 
>> Due to this
>> <http://support.mystonline.com/serverstatus/urulivelive.php>,
> 
> This is rather sad. I considered buying this game since long, but never
> did it. I guess it is possible to enjoy the different places even
> without a server, right?

Most of the ages are in the offline version from 2004 (Uru Complete 
Chronicles = Uru Ages Beyond Myst + To D'ni + Path of the Shell), but 
some new ones are only in the online version. And, of course, only the 
online version allows you to explore together with people from all over 
the world, which is surprisingly much fun even for a loner like me.

The current online version from GameTap ("Myst Online Uru Live", MOUL) 
is completely separate from the old offline version from Ubisoft, you 
don't need to buy the latter to try the former. Although, you're in 
Switzerland, like me, right? Unfortunately MOUL is only officially 
available in a limited range of countries, Switzerland not among them. I 
decided to make an account through the back door and enjoy it while it 
lasts when I heard of the cancellation.

> Pipmak will not walk away (since you have not implemented feet.)

Your turn to implement them ;)

  -Christian

Re: [Pipmak-Devel] Inactivity warning

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

NigeC wrote:
> Christian Walther wrote:
>> I probably won't fix the problem with stacked cubic nodes 
> thats a shame

Heh, now don't take my quote out of context! ;)

It's just too complex to cram into this release. It's a fundamental 
issue with how the hand and pan tools interact with overlaid nodes, it's 
not just a superficial bug. I need to spend some thought on how to solve 
this properly. The current behavior, where on overlays always the hand 
tool is used, indepentently of what tool is selected on the background 
node, makes sense when the overlay is e.g. a tools palette - clicking on 
the tools palette while having a paint tool selected shouldn't paint on 
the palette, but select a new tool. But of course this behavior is 
inapropriate when the overlay is part of the scenery. Perhaps we need to 
distinguish between "palette" overlays and "scenery" overlays, or 
perhaps the pan tool needs to be made a special case, or something.

  -Christian

Re: [Pipmak-Devel] [pipmak-devel] Inactivity warning

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

Christian Walther wrote:
> 
> I probably won't fix the problem with stacked cubic nodes 
thats a shame

I'm just having a look at Myst online before its to late!

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

Re: [Pipmak-Devel] Inactivity warning

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

Christian Walther wrote:

> Due to this
> <http://support.mystonline.com/serverstatus/urulivelive.php>,

This is rather sad. I considered buying this game since long, but never
did it. I guess it is possible to enjoy the different places even
without a server, right?

> I will 
> probably spend most of my free time in Uru rather than working on
> Pipmak until the beginning of April.

Enjoy it! Pipmak will not walk away (since you have not implemented
feet.)

[Pipmak-Devel] Inactivity warning

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

Due to this 
<http://support.mystonline.com/serverstatus/urulivelive.php>, I will 
probably spend most of my free time in Uru rather than working on Pipmak 
until the beginning of April.

This means that probably the 0.2.7 release will be delayed until then, 
too. What remains to be done, off the top of my head:

- update the demo project (almost done)
- restrict drawing operations to runtime-created images and implement 
copying from file-loaded images, to fix (or sidestep) some of the bugs 
found by Andrea
- check loadlib on all platforms
- work around rendering issues on iBook 16MB
- explain why I probably won't fix the problem with stacked cubic nodes 
for this release
- general cleanup of readmes, version numbers everywhere, etc.
- build and test on Linux and Windows

See you in the cavern (those who are there)!

  -Christian

Re: [Pipmak-Devel] Transition interrupts

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

Aidan Gauland wrote:
>  I've managed to do something to the code for handling mouse button 
> up/down events, which SEEMS to fix the problem of starting a transition 
> during a transition, but there might still be something more subtle I've 
> overlooked.  I've attached a patch, generated against revision 179.

Thanks for looking into this! This solution seems a bit too simplistic, 
however. Here is a test case where it causes incorrect behavior:

---8<--- node.lua ------------------------------------------------------

slide (pipmak.newimage(640, 480):color(1.0, 0.95, .8):fill())

local btnimg = pipmak.newimage(100, 40):color(0.5, 0.5, 0.7):fill()
local btnimgh = pipmak.newimage(100, 40):color(0.7, 0.3, 0.3):fill()

local indicator = patch { x = 200, y = 100, image = pipmak.newimage(40, 
40):color(0.5, 0.8, 0.3):fill() }

local btn = patch { x = 270, y = 300, image = btnimg }
handle {
	x = 270, y = 300, w = 100, h = 40,
	onhilite = function(self, h)
		btn:setimage(h and btnimgh or btnimg)
	end,
	onmousedown = function()
		indicator:moveto(200, 100)
		pipmak.schedule(2, function()
			indicator:moveto(300, 100)
			pipmak.dissolve(1, 4)
			indicator:moveto(400, 100)
			pipmak.schedule(4, function()
				indicator:moveto(500, 100)			
			end)
		end)
	end
}

---8<-------------------------------------------------------------------

The blue rectangle is a button that highlights red when clicked. Mouse 
down on this button starts the following sequence: The green square 
resets to position 1. After 2 seconds, it jumps to position 2 and starts 
fading to position 3. The transition takes 4 seconds, when it's done the 
green square jumps to position 4.

When you press the mouse button on the blue button and hold it down 
until the transition starts, then release it while the transition is 
running, the button does not properly unhighlight (return from red to 
blue) since the mouse-up event is suppressed.

Off the top of my head, here's the behavior I would propose:
- When the mouse goes down during a transition, the entire click 
(including mouse up, whether it happens before the end of the transition 
or after) should be ignored.
- Not sure if this is necessary: When the mouse is down at the beginning 
of a transition and goes up during it, the mouse-up event should be 
delayed until the transition has finished.

Does that make sense?

And two general comments:
- It looks like you still generated the patch "by hand" using diff. If 
you're using Subversion now (as I assume when you say "revision 179"), 
it would probably be more convenient to use "svn diff".
- You're again using a mixture of tabs and spaces for indentation. You 
won't get commit access until you get this right (tabs only) ;)

>  And about the bug with grabbing the mouse after closing a dialog...
> flashback:
>  > Also, when I bring up the save game dialog with the 'S' key, Pipmak 
>  >doesn't give me my mouse back, and I have to go to a virtual console 
>  >and kill Pipmak.  If I add a call to SDL_WM_GrabInput() to ungrab the 
>  >mouse in the Lua C function which is called when the 'S' key is 
>  >pressed, that seems to solve this problem.

Hmm, I thought you fixed that in rev. 179? Or are you talking about the 
other problem, the one you described as

> Ahhh, one other thing: If the user brings up a dialog, and then dismisses
> it, Pipmak seems to do the same thing with grabbing the mouse, even if it's
> not in the window, and then it is impossible to get the mouse out of the
> window, until the user brings up another dialog, and closes it when it is
> over the Pipmak window (so the mouse will be in the Pipmak window when it
> regrabs the mouse).
?

> I think it might only show wiht GTK.  If I understand this properly, 
> Pipmak uses GTK when built for Linux, and Aqua when built for Macintosh. 
>  So that might be why Christian doesn't get this bug.

Well, it's true that I don't get it on Mac OS, but I don't even get it 
with GTK on Linux.

>  If I add a call to the SDL warp mouse function, at the end Lua function 
> for the save dialog (the one called when the 'S' key is pressed), that 
> seems to work as a crude workaround, but I don't know how to find a 
> better solution.

Just send us that workaround, I'll commit it if it doesn't break 
anything. Maybe Urs can test it as well, and I'll make sure to test on 
Ubuntu (where I assume I'll have the same behavior as you on Debian) 
before the release anyway.

  -Christian

[Pipmak-Devel] Transition interrupts

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

Hello,

  I've managed to do something to the code for handling mouse button 
up/down events, which SEEMS to fix the problem of starting a transition 
during a transition, but there might still be something more subtle I've 
overlooked.  I've attached a patch, generated against revision 179.

  And about the bug with grabbing the mouse after closing a dialog...
flashback:
 > Also, when I bring up the save game dialog with the 'S' key, Pipmak 
 >doesn't give me my mouse back, and I have to go to a virtual console 
 >and kill Pipmak.  If I add a call to SDL_WM_GrabInput() to ungrab the 
 >mouse in the Lua C function which is called when the 'S' key is 
 >pressed, that seems to solve this problem.

I think it might only show wiht GTK.  If I understand this properly, 
Pipmak uses GTK when built for Linux, and Aqua when built for Macintosh. 
  So that might be why Christian doesn't get this bug.  However, I have 
no idea if the bug is in GTK, Pipmak's code for using GTK, or with SDL. 
  If I add a call to the SDL warp mouse function, at the end Lua 
function for the save dialog (the one called when the 'S' key is 
pressed), that seems to work as a crude workaround, but I don't know how 
to find a better solution.

  -Aidan

Re: [Pipmak-Devel] Two Bugs

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

> Ahhh, one other thing: If the user brings up a dialog, and then
> dismisses it, Pipmak seems to do the same thing with grabbing the
> mouse, even if it's not in the window, and then it is impossible to
> get the mouse out of the window, until the user brings up another
> dialog, and closes it when it is over the Pipmak window (so the mouse
> will be in the Pipmak window when it regrabs the mouse).<br>

I can reproduce this here on debian linux etch with SDL 1.2.11. The 
mouse gets locked in when I hit S while the mouse is _inside_ the 
pipmak window and then klick the cancel button with the mouse at a 
place that is _outside_ of pipmak's window.

Re: [Pipmak-Devel] Two Bugs

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

Aidan Gauland wrote:
>   Ahhh, one other thing: If the user brings up a dialog, and then 
> dismisses it, Pipmak seems to do the same thing with grabbing the mouse, 
> even if it's not in the window, and then it is impossible to get the 
> mouse out of the window, until the user brings up another dialog, and 
> closes it when it is over the Pipmak window (so the mouse will be in the 
> Pipmak window when it regrabs the mouse).

I can't reproduce this - everything seems to work correctly here on 
Fedora Core 4 with SDL 1.2.13 (perhaps I should try with a less ancient 
distro some time). So I'm afraid you're on your own with fixing this...

>  I did a case-insensitive search for a call to SDL_WMGrabInput(), but 
> only found the one in main.c for the mouse motion event, and two in 
> pipmakLuaLib.c before dialogs are opened.  So how is Pipmak grabbing the 
> mouse without calling that function?

I have 8 total occurences of SDL_WM_GrabInput (2 in pipmakLuaLib.c, 6 in 
main.c), but none that would explain your observation.

>  Oh, and I have the -Wall option set for GCC, because I'm still learning 
> about syntatical gotchas in C.  I don't think it gives warnings about 
> parentheses around logical operators normally.

I thought I had -Wall too, but it turns out I only had -Wmost, which 
explicitly excludes -Wparentheses. I'll change that to -Wall and see how 
far I get until it annoys me.

  -Christian

Re: [Pipmak-Devel] Two Bugs

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
&nbsp;
Ahhh, one other thing: If the user brings up a dialog, and then
dismisses it, Pipmak seems to do the same thing with grabbing the
mouse, even if it's not in the window, and then it is impossible to get
the mouse out of the window, until the user brings up another dialog,
and closes it when it is over the Pipmak window (so the mouse will be
in the Pipmak window when it regrabs the mouse).<br>
<br>
&nbsp;I did a case-insensitive search for a call to SDL_WMGrabInput(), but
only found the one in main.c for the mouse motion event, and two in
pipmakLuaLib.c before dialogs are opened.&nbsp; So how is Pipmak grabbing
the mouse without calling that function?<br>
<br>
&nbsp;Oh, and I have the -Wall option set for GCC, because I'm still
learning about syntatical gotchas in C.&nbsp; I don't think it gives
warnings about parentheses around logical operators normally.<br>
<br>
&nbsp;-Aidan<br>
<br>
Christian Walther wrote:
<blockquote cite="mid:fn4tcd$pdv$1...@ge..." type="cite">
  <pre wrap="">Aidan Gauland wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I have (I think) fixed the bug with the mouse grabbing.  If I remove the 
call to SDL_WM_GrabInput() that's right before the main for(;;) loop, 
then it seems to always be possible to get the mouse out of the window, 
even with edge resistance.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Thanks, I've committed that. That grab must have been a relic from the 
past, the automatic grab when the mouse moves inside the window is 
indeed sufficient.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Also, when I bring up the save game dialog with the 'S' key, Pipmak 
doesn't give me my mouse back, and I have to go to a virtual console and 
kill Pipmak.  If I add a call to SDL_WM_GrabInput() to ungrab the mouse 
in the Lua C function which is called when the 'S' key is pressed, that 
seems to solve this problem.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Right, that was an oversight. The other two dialogs (open project and 
open saved game) have the ungrab. For some reason it worked here on Mac 
OS X without it. This is committed, thanks!

  </pre>
  <blockquote type="cite">
    <pre wrap="">I also added parentheses around the tests for an if statement (you'll 
see where), just to suppress a complier warning.  No other reason.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
GCC doesn't trust us to know that 'and' is stronger than 'or'? Oh 
well... applied.

  -Christian


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
<a class="moz-txt-link-freetext"
 href="http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/">http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/</a>
_______________________________________________
Pipmak-Devel mailing list
<a class="moz-txt-link-abbreviated"
 href="mailto:Pip...@li...">Pip...@li...</a>
<a class="moz-txt-link-freetext"
 href="news://news.gmane.org/gmane.games.devel.pipmak.devel">news://news.gmane.org/gmane.games.devel.pipmak.devel</a>
<a class="moz-txt-link-freetext"
 href="https://lists.sourceforge.net/lists/listinfo/pipmak-devel">https://lists.sourceforge.net/lists/listinfo/pipmak-devel</a>

  </pre>
</blockquote>
</body>
</html>

Re: [Pipmak-Devel] Two Bugs

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

Aidan Gauland wrote:
> I have (I think) fixed the bug with the mouse grabbing.  If I remove the 
> call to SDL_WM_GrabInput() that's right before the main for(;;) loop, 
> then it seems to always be possible to get the mouse out of the window, 
> even with edge resistance.

Thanks, I've committed that. That grab must have been a relic from the 
past, the automatic grab when the mouse moves inside the window is 
indeed sufficient.

> Also, when I bring up the save game dialog with the 'S' key, Pipmak 
> doesn't give me my mouse back, and I have to go to a virtual console and 
> kill Pipmak.  If I add a call to SDL_WM_GrabInput() to ungrab the mouse 
> in the Lua C function which is called when the 'S' key is pressed, that 
> seems to solve this problem.

Right, that was an oversight. The other two dialogs (open project and 
open saved game) have the ungrab. For some reason it worked here on Mac 
OS X without it. This is committed, thanks!

> I also added parentheses around the tests for an if statement (you'll 
> see where), just to suppress a complier warning.  No other reason.

GCC doesn't trust us to know that 'and' is stronger than 'or'? Oh 
well... applied.

  -Christian

Re: [Pipmak-Devel] Two Bugs

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

Hi

Aidan Gauland wrote:
>  I have (I think) fixed the bug with the mouse grabbing.  If I remove
> the call to SDL_WM_GrabInput() that's right before the main for(;;)
> loop, then it seems to always be possible to get the mouse out of the
> window, even with edge resistance.

Yes, your patch fixes the problem on my machine: Debian linux etch
(using KDE). Good work! (I think that it is anyway better behaviour not
to grab the mouse when Pipmak starts and the mouse is outside the
window.)

>  Also, when I bring up the save game dialog with the 'S' key, Pipmak
> doesn't give me my mouse back, and I have to go to a virtual console
> and
> kill Pipmak.  If I add a call to SDL_WM_GrabInput() to ungrab the
> mouse in the Lua C function which is called when the 'S' key is
> pressed, that seems to solve this problem.

I experience the same problem and again, your patch fixes it.

[Pipmak-Devel] Two Bugs

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

Hello,

 I have (I think) fixed the bug with the mouse grabbing.  If I remove 
the call to SDL_WM_GrabInput() that's right before the main for(;;) 
loop, then it seems to always be possible to get the mouse out of the 
window, even with edge resistance.

 Also, when I bring up the save game dialog with the 'S' key, Pipmak 
doesn't give me my mouse back, and I have to go to a virtual console and 
kill Pipmak.  If I add a call to SDL_WM_GrabInput() to ungrab the mouse 
in the Lua C function which is called when the 'S' key is pressed, that 
seems to solve this problem.

 I can not be sure that I have fixed this bugs, and haven't simply 
masked them, nor can I be sure that I haven't broken something somewhere 
else.  But what the heck, here are the patches with my modifications, (I 
also added parentheses around the tests for an if statement (you'll see 
where), just to suppress a complier warning.  No other reason.) let me 
know what you think.

 -Aidan