pipmak-devel Mailing List for Pipmak Game Engine (Page 5)
Status: Alpha
Brought to you by:
cwalther
Menu
▾
▴
pipmak-devel — Development of the Pipmak Game Engine
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(6) |
| 2006 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(3) |
Sep
(4) |
Oct
(5) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(31) |
Aug
(11) |
Sep
(3) |
Oct
(3) |
Nov
|
Dec
(1) |
| 2008 |
Jan
(38) |
Feb
(19) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(16) |
Nov
(5) |
Dec
|
| 2009 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
|
Sep
|
Oct
(4) |
Nov
(10) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christian W. <cwa...@gm...> - 2008-01-20 07:53:31
|
Aidan Gauland wrote: > I see it does the same on my system, now that I look more closely. > But, I have NO IDEA where to start looking in the source code for > this one. Maybe, not grabbing the mouse as soon as Pipamk starts, > but grabbing the mouse when it is moved into the window, just as > would be done for the rest of the session, would remove this > problem. But when in the code does Pipmak grab the mouse for the > first time? The first grab happens on main.c line 484, just before entering the main loop. I have no idea why that would prevent later ungrabbing when the mouse was outside of the window at that time. Let me know what you find out. > And what do you all mean when you say "revision 170". I'm using > the source tarball I got from a link on this page: > http://pipmak.sourceforge.net/downloads.php > I'm sorry if this seems like a silly question, but I haven't been > involved with an open source project before. Not a silly question. Welcome to the world of revision control, a very useful tool in collaborative (and even solitary) software development! A revision control tool stores the whole history of the source code of the project, it lets you go back and forth in time and review who did what, when, and why. It also makes it easy to review (and undo) the changes to the code you have made in your personal copy. Pipmak uses Subversion (SVN) for revision control, like many other projects nowadays (Side node: I've played with the idea of setting up a Bazaar branch mirroring our Subversion repository at launchpad.net. Would anyone be interested in this?). A very good resource for learning about Subversion is the SVN Book ("Version Control with Subversion") at <http://svnbook.red-bean.com>. To get started, you need to install a Subversion client. On Linux, you will probably want to use the command line client. You're on Debian, right? Try "apt-get install subversion". Run "svn checkout https://pipmak.svn.sourceforge.net/svnroot/pipmak/trunk/pipmak " to download a copy of the current Pipmak source code. This will get you approximately what you have in your source tarball, but with the addition that you can run "svn status" to see your local changes, "svn update" to update to the latest code from the repository, "svn diff" to generate patches, and many more. You can't currently do "svn commit" to send your changes back to the repository (only I can do that), but I will give you that privilege if I come to the conclusion that your contributions are of sufficient frequency and quality that it would be more work for me to apply your patches than to let you commit them yourself. -Christian |
|
From: Christian W. <cwa...@gm...> - 2008-01-20 07:50:17
|
Aidan Gauland wrote:
> I applied the patch, and it works perfectly fine on my system. I
> also added a printf() just after each call to SDL_WM_GrabInput, so I
> could confirm that Pipmak was grabbing and releasing the mouse when
> it should. And yes, I do like that behaviour.
Fine, then I'll commit that. I'm sorry you had to do all the hard work
with timing and stuff before we found that simple solution.
> Is anyone working on the bug with mouse clicks during transitions?
Not that I know of. I expect that to be a simple one. One thing you
should double-check is if there are any hidden assumptions in the code
along the lines of "there's exactly one mouse up event for every mouse
down event", which you could violate by ignoring some events. Off the
top of my head, I'd say this is already taken care of by the code that
does things like coalescing multiple mouse buttons into one, but it
can't hurt to check that nothing unexpected happens when e.g. the
mouse goes down during a transition and up after it, or down before
and up during.
> If not, then where could I start on that one? I know where the
> event handling case statement is for mouse clicks (at least, I think
> it's near the one for mouse motion events), but where is the code
> for display transitions?
Check the switch statement in the last few lines of main.c. Depending
on whether a transition is in progress, redrawGL() is called there
either with an argument of 1.0 ("render normally") or with an argument
between 0.0 and 1.0 ("render a transition effect").
A case-insensitive search for "transition" in the whole source code
may help you get an overview too.
-Christian
|
|
From: Andrea V. <and...@gm...> - 2008-01-17 08:57:23
|
Hello! You wrote: And what do you all mean when you say "revision 170". I'm using the > source tarball I got from a link on this page: > http://pipmak.sourceforge.net/downloads.php > I'm sorry if this seems like a silly question, but I haven't been involved > with an open source project before. > The source tarball that you have downloaded Corresponds approximately at "revision 144", the official release,but you can found a newer version (of-course, still in a development stage), in the subversion repository, check at http://pipmak.svn.sourceforge.net/viewvc/pipmak/trunk/?view=log Actually th last revision is the 172, which have a lot of improvement respect official 0.2.6, like: - patches 3D placement - image manipulation methods (newimage, color, fill,...) - possibility to write text into image (drawtext,....) - new Lua Command line tool - new Lua Table inspector - error traceback - new methods to manage full screen - program icons association (hust for Windows...) - some bugs corrections if you want to get the last revision, you need a subversion client, check my tutorial in the wiki, sorry it's only for Windows, but in Linux, the operations are similar, http://pipmak.sourceforge.net/wiki/index.php/MSVC8_Build#Get_pipmak_SVN Tortoise is a client just for Windows, you have to download another SVN-client (check at http://sourceforge.net/docs/B01/en/#svn_client ) You can try with this: http://subversion.tigris.org/ Once the program is installed, you need to pass to the svn-client, just these informations: Repository: https://pipmak.svn.sourceforge.net/svnroot/pipmak/trunk/pipmak Revision number: put HEAD or 172 Bye Andrea |
|
From: Aidan G. <wgs...@ih...> - 2008-01-17 00:13:35
|
<!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"> I see it does the same on my system, now that I look more closely. But, I have NO IDEA where to start looking in the source code for this one. Maybe, not grabbing the mouse as soon as Pipamk starts, but grabbing the mouse when it is moved into the window, just as would be done for the rest of the session, would remove this problem. But when in the code does Pipmak grab the mouse for the first time?<br> <br> And what do you all mean when you say "revision 170". I'm using the source tarball I got from a link on this page:<br> <a class="moz-txt-link-freetext" href="http://pipmak.sourceforge.net/downloads.php">http://pipmak.sourceforge.net/downloads.php</a><br> I'm sorry if this seems like a silly question, but I haven't been involved with an open source project before.<br> <br> Urs Holzer wrote: <blockquote cite="mid:fmkfbs$d11$1...@ge..." type="cite"> <blockquote type="cite"> <pre wrap="">Hmmm, I've just discovered a... well, bug really, which I didn't notice when I wrote this last message. If I move the mouse when Pipmak is launching, then for the rest of that Pipmak session, it is impossible to get the mouse out of the window, even WITH the zero threshold. I have no idea where to start looking for the cause of this one. Do you? </pre> </blockquote> <pre wrap=""><!----> Ha! You are great. I checked that, and here is what happens on my system: If the mouse is outside of the window of pipmak when pipmak starts, pipmak grabs the mouse and puts it inside its window. Then, it is impossible to free the mouse during the whole pipmak session. On the other hand, if the mouse is already where pipmak's window will appear, and I start pipmak, then the mouse can be freed during the whole session. (I am working on Linux, using revision 170. I didn't test with zero threshold) ------------------------------------------------------------------------- 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> |
|
From: Urs H. <ur...@an...> - 2008-01-16 08:30:57
|
> Hmmm, I've just discovered a... well, bug really, which I didn't > notice when I wrote this last message. If I move the mouse when > Pipmak is launching, then for the rest of that Pipmak session, it is > impossible to get the mouse out of the window, even WITH the zero > threshold. I have no idea where to start looking for the cause > of this one. Do you? Ha! You are great. I checked that, and here is what happens on my system: If the mouse is outside of the window of pipmak when pipmak starts, pipmak grabs the mouse and puts it inside its window. Then, it is impossible to free the mouse during the whole pipmak session. On the other hand, if the mouse is already where pipmak's window will appear, and I start pipmak, then the mouse can be freed during the whole session. (I am working on Linux, using revision 170. I didn't test with zero threshold) |
|
From: Aidan G. <wgs...@ih...> - 2008-01-16 03:55:24
|
<!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">
Hmmm, I've just discovered a... well, bug really, which I didn't
notice when I wrote this last message. If I move the mouse when Pipmak
is launching, then for the rest of that Pipmak session, it is
impossible to get the mouse out of the window, even WITH the zero
threshold. I have no idea where to start looking for the cause of this
one. Do you?<br>
<br>
-Aidan<br>
<br>
I wrote:
<blockquote cite="mid:478...@ih..." type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
I applied the patch, and it works perfectly fine on my system. I also
added a printf() just after each call to SDL_WM_GrabInput, so I could
confirm that Pipmak was grabbing and releasing the mouse when it
should. And yes, I do like that behaviour. So if that's that, then...<br>
<br>
Is anyone working on the bug with mouse clicks during transitions? If
not, then where could I start on that one? I know where the event
handling case statement is for mouse clicks (at least, I think it's
near the one for mouse motion events), but where is the code for
display transitions?<br>
<br>
-Aidan<br>
<br>
Christian Walther wrote:
<blockquote cite="mid:fmdq2i$n1m$2...@ge..." type="cite">I
wrote: <br>
<blockquote type="cite">Come to think of it, we could probably use
a
threshold of 0. After all, the goal is not "reach the edge without
triggering an ungrab", but "reach the edge, period". If we can make the
grabbing transparent to the user, all the better. Have to try that on
Windows and Linux... <br>
</blockquote>
<br>
OK, I just checked: <br>
<br>
- I don't have any problems ungrabbing with the existing code on Linux
(that doesn't mean that there is no problem, of course, but it explains
why I haven't noticed and fixed it before). <br>
<br>
- The zero threshold solution seems to work quite well on Windows and
Linux. You can't slide the Pipmak cursor along the window edge anymore,
but I'm not sure that's necessary. Can you try the attached patch and
see if you like that behavior? <br>
<br>
-Christian <br>
<pre wrap=""><pre wrap=""><hr size="4" width="90%">
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace">http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace</a></pre><pre
wrap=""><hr size="4" width="90%">
_______________________________________________
Pipmak-Devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Pip...@li...">Pip...@li...</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.sourceforge.net/lists/listinfo/pipmak-devel">https://lists.sourceforge.net/lists/listinfo/pipmak-devel</a></pre></pre>
</blockquote>
<pre wrap="">
<hr size="4" width="90%">
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
<a class="moz-txt-link-freetext" href="http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace">http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace</a></pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
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>
|
|
From: Aidan G. <wgs...@ih...> - 2008-01-15 03:01:54
|
<!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"> I applied the patch, and it works perfectly fine on my system. I also added a printf() just after each call to SDL_WM_GrabInput, so I could confirm that Pipmak was grabbing and releasing the mouse when it should. And yes, I do like that behaviour. So if that's that, then...<br> <br> Is anyone working on the bug with mouse clicks during transitions? If not, then where could I start on that one? I know where the event handling case statement is for mouse clicks (at least, I think it's near the one for mouse motion events), but where is the code for display transitions?<br> <br> -Aidan<br> <br> Christian Walther wrote: <blockquote cite="mid:fmdq2i$n1m$2...@ge..." type="cite">I wrote: <br> <blockquote type="cite">Come to think of it, we could probably use a threshold of 0. After all, the goal is not "reach the edge without triggering an ungrab", but "reach the edge, period". If we can make the grabbing transparent to the user, all the better. Have to try that on Windows and Linux... <br> </blockquote> <br> OK, I just checked: <br> <br> - I don't have any problems ungrabbing with the existing code on Linux (that doesn't mean that there is no problem, of course, but it explains why I haven't noticed and fixed it before). <br> <br> - The zero threshold solution seems to work quite well on Windows and Linux. You can't slide the Pipmak cursor along the window edge anymore, but I'm not sure that's necessary. Can you try the attached patch and see if you like that behavior? <br> <br> -Christian <br> <pre wrap=""><pre wrap=""><hr size="4" width="90%"> ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. <a class="moz-txt-link-freetext" href="http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace">http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace</a></pre><pre wrap=""><hr size="4" width="90%"> _______________________________________________ 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></pre> </blockquote> </body> </html> |
|
From: Christian W. <cwa...@gm...> - 2008-01-13 19:55:03
|
I wrote: > Come to think of it, we could probably use a threshold of 0. After all, > the goal is not "reach the edge without triggering an ungrab", but > "reach the edge, period". If we can make the grabbing transparent to the > user, all the better. Have to try that on Windows and Linux... OK, I just checked: - I don't have any problems ungrabbing with the existing code on Linux (that doesn't mean that there is no problem, of course, but it explains why I haven't noticed and fixed it before). - The zero threshold solution seems to work quite well on Windows and Linux. You can't slide the Pipmak cursor along the window edge anymore, but I'm not sure that's necessary. Can you try the attached patch and see if you like that behavior? -Christian |
|
From: Christian W. <cwa...@gm...> - 2008-01-12 15:09:41
|
Aidan Gauland wrote:
> Okay, here is the patch (as an attachment) generated with the -u option,
> as requested. I hope it will work better across different systems.
Thanks!
Applied as-is, it makes it completely impossible to get the mouse
ungrabbed here on Mac OS X. I don't understand what you're doing here:
// Calculate the elapsed time since we last did this,
int elapsedTime = thisRedrawTime - lastMouseMoveTime;
// and don't bother with these next steps if no time has passed.
if (elapsedTime != 0)
{ ...
That basically means, "don't bother if the mouse has moved in this main
loop iteration". When the mouse moves fast, it usually does move in
every iteration (here), so you're skipping the potential ungrabbing
exactly in the situation where it would be needed. (Perhaps you meant to
use lastTime instead of lastMouseMoveTime, in which case the test would
only serve to guard against a division by 0 in the case of several mouse
events per main loop iteration?)
When I comment that test out, it works quite well. However, the
threshold of 3.18 px/ms seems a bit high to me, to reproduce the
previous behavior I subjectively have to set it to about 1.0, though I
can go as far down as about 0.1 while still being able to easily reach
the edge without triggering an ungrab. (In fact, the previous threshold
of 20 px per mouse event, combined with the assumptions of mouse events
in every iteration (which I get, you apparently don't) and a refresh
rate of 60 Hz would lead to a value of 1.2 px/ms.)
Why exactly 3.18, anyway (just out of curiosity)? Is that somehow
distinguishable from, say, 3.0?
Have you thought about using the unclamped mouse delta from the event
(event.motion.xrel) instead of a clamped one (mouseX - lastX)? The
difference would be that you could also ungrab with a swift mouse motion
when you're already at the edge, you wouldn't have to step back first.
I'm undecided which behavior is better.
Come to think of it, we could probably use a threshold of 0. After all,
the goal is not "reach the edge without triggering an ungrab", but
"reach the edge, period". If we can make the grabbing transparent to the
user, all the better. Have to try that on Windows and Linux...
-Christian
|
|
From: Christian W. <cwa...@gm...> - 2008-01-12 13:24:21
|
I wrote:
> - I specify -br, but it still changes
>
> int func() {
> return 5;
> }
>
> to
>
> int func()
> {
> return 5;
> }
Ah, got that one too, with the help of the bug-indent mailing list
archives. That's the undocumented -brf option.
-Christian
|
|
From: Christian W. <cwa...@gm...> - 2008-01-12 13:08:37
|
I wrote: > - I specify -ut, but it still changes my indenting tabs into spaces OK, I fixed that one, by using -ut -i2 -ts2. I hadn't realized that there were separate -i and -ts options. -Christian |
|
From: Christian W. <cwa...@gm...> - 2008-01-12 12:56:05
|
I wrote:
> I can see if I can come up with a set of rules that approximately match my coding style.
So far I haven't had much success with GNU indent 2.2.9 - I have come up
with the options
-br -brs -npsl -l1000 -npcs -ncs -ut -c0 -cd0 -cp0
(plus a whole bunch of '-T xyz' to make it recognize casts and tell
pointer * from multiplication) but there are still several things wrong:
- I specify -br, but it still changes
int func() {
return 5;
}
to
int func()
{
return 5;
}
- I specify -ut, but it still changes my indenting tabs into spaces
(but, curiously, it changes spaces between code and comments into tabs).
- I haven't found a way of stopping it from changing
if (a) b();
to
if (a)
b();
(if anything, it should change it to
if (a) {
b();
}
)
Unless you can help me with these, I fear we have to give up the idea of
using indent.
-Christian
|
|
From: Aidan G. <wgs...@ih...> - 2008-01-12 09:16:05
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Okay, here is the patch (as an attachment) generated with the -u
option, as requested. I hope it will work better across different
systems.<br>
<br>
Christian Walther wrote:
<blockquote cite="mid:fm5v2i$28r$1...@ge..." type="cite">
<pre wrap="">Aidan Gauland wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> My father (who is much more experienced in C, and programming in
general than I am), and I have come up with another way of measuring the
rate at which the mouse hits the edge of the window in Pipmak.
</pre>
</blockquote>
<pre wrap=""><!---->
Cool!
</pre>
<blockquote type="cite">
<pre wrap=""> But before I generate a patch, I want to know if you have a set of
rules for indentation of the Pipmak code, that I could use with the
program "indent" to make sure the indentation in the patch is consistent
with the existing code.
</pre>
</blockquote>
<pre wrap=""><!---->
To date no such rules exist. I have never used indent on Pipmak. But I
can see if I can come up with a set of rules that approximately match my
coding style. That would obviously be useful for contributors. I don't
insist that everyone use exactly my style, but it would still be nice to
keep a certain consistency.
</pre>
<blockquote type="cite">
<pre wrap=""> And by the way, where did Pipmak get its name from?
</pre>
</blockquote>
<pre wrap=""><!---->
The name comes from the pipmak, which is the thing depicted in Pipmak's
logo. I made up the word "pipmak" for that when I was a child (or maybe
my father or my sister did, don't remember). Now what's a pipmak? A
movie and a picture say more than a thousand words:
<a class="moz-txt-link-rfc2396E" href="http://pipmak.sourceforge.net/temp/pipmak.mov"><http://pipmak.sourceforge.net/temp/pipmak.mov></a>
<a class="moz-txt-link-rfc2396E" href="http://pipmak.sourceforge.net/temp/pipmak.jpeg"><http://pipmak.sourceforge.net/temp/pipmak.jpeg></a>
-Christian
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
<a class="moz-txt-link-freetext" href="http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace">http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace</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>
|
|
From: Christian W. <cwa...@gm...> - 2008-01-10 20:27:02
|
Aidan Gauland wrote: > My father (who is much more experienced in C, and programming in > general than I am), and I have come up with another way of measuring the > rate at which the mouse hits the edge of the window in Pipmak. Cool! > But before I generate a patch, I want to know if you have a set of > rules for indentation of the Pipmak code, that I could use with the > program "indent" to make sure the indentation in the patch is consistent > with the existing code. To date no such rules exist. I have never used indent on Pipmak. But I can see if I can come up with a set of rules that approximately match my coding style. That would obviously be useful for contributors. I don't insist that everyone use exactly my style, but it would still be nice to keep a certain consistency. > And by the way, where did Pipmak get its name from? The name comes from the pipmak, which is the thing depicted in Pipmak's logo. I made up the word "pipmak" for that when I was a child (or maybe my father or my sister did, don't remember). Now what's a pipmak? A movie and a picture say more than a thousand words: <http://pipmak.sourceforge.net/temp/pipmak.mov> <http://pipmak.sourceforge.net/temp/pipmak.jpeg> -Christian |
|
From: Aidan G. <wgs...@ih...> - 2008-01-10 03:15:26
|
Hello again, My father (who is much more experienced in C, and programming in general than I am), and I have come up with another way of measuring the rate at which the mouse hits the edge of the window in Pipmak. I won't bore you with all the details, but we measure the time between mouse events, and then use that to calculate the speed of the mouse, and use THAT to decide if the mouse should be ungrabbed. The code for regrabbing the mouse is still the same though. This will, of course, need to be tested on at least one other system, before it could be considered for the next official release of Pipmak. But before I generate a patch, I want to know if you have a set of rules for indentation of the Pipmak code, that I could use with the program "indent" to make sure the indentation in the patch is consistent with the existing code. If emacs (the text editor I use) had a pre-defined indentation style that matched the Pipmak source, then I would have used that when editing the code, but, unfortunately, it didn't. And by the way, where did Pipmak get its name from? Regards, Aidan |
|
From: Christian W. <cwa...@gm...> - 2008-01-04 20:29:42
|
Andrea Viarengo wrote: > 2) I would like to create a transparent hole (alpha=0) in a png image, I > need this for doors and windows, so I have operated in this manner: > > img=pipmak.loadimage(texture.."/front.png") > w,h=img:size() > img:color(0,0,0,0) > img:fill(w/3,h/3,w/3,2*h/3) > > but I get only a black shape and not a transparent hole: this is a bug? image:fill() doesn't add an alpha channel to an image that doesn't already have one. Whether that's a bug or not is debatable, it's certainly a limitation that needs to be documented at least. Fixing it is probably going to be non-trivial. Depending on how we decide to solve the loadimage-returns-existing-object problem, it may go away entirely. Thanks for finding this! -Christian |
|
From: Christian W. <cwa...@gm...> - 2008-01-04 20:22:11
|
Andrea Viarengo wrote: > Why the patches in the pics attached are rendered in a different way? > > You can see a white line around the first patch, but I have used exactly > the same image with the same resolution, the difference is that in the > first case I have drawn the door inside the wall (using photoshop), so > the first is a transparent png and the second is a normal opaque png. > ... > 3) Transparent PNG and opaque PNG are rendered in a different way (with > a different gap around..see point 1) I can't reproduce this in r170, at least with the specific location in autocubic v8 that I've tried. I get the same gap for PNGs with or without alpha (texture/31/front.png, front1.png). If this still occurs for you, can you prepare a minimal reproducing example? -Christian |
|
From: Christian W. <cwa...@gm...> - 2008-01-04 15:24:13
|
Andrea Viarengo wrote: > inspect the sub-table "coroutine", and after click on the back arrow to > return to _G table, in this case I get the error, and you? Nope, no error here. Maybe try this modification to bypass the extended error handling from r162: --- source/misc.c (revision 170) +++ source/misc.c (working copy) @@ -107,7 +107,7 @@ lua_pushliteral(L, "_TRACEBACK"); lua_rawget(L, LUA_GLOBALSINDEX); /* get traceback function (from debug library) */ lua_insert(L, base); /* put it under chunk and args */ - status = lua_pcall(L, nargs, nresults, base); + status = lua_pcall(L, nargs, nresults, 0); lua_remove(L, base); /* remove traceback function */ return status; } -Christian |
|
From: Christian W. <cwa...@gm...> - 2008-01-04 14:30:05
|
Andrea Viarengo wrote: > I read that you have improved error handling, adding a traceback, but > with build 170 on every error I get always the message: > > Error running lua file error in error handling > > What I am wrong? No idea. Are you still using Lua 5.1? If so, maybe that's the problem. -Christian |
|
From: Christian W. <cwa...@gm...> - 2008-01-04 14:28:55
|
Andrea Viarengo wrote:
> There are still a little bug, when you inspect a table contained in
> another table, you cannot return to the first table pressing the arrow
> at top of the window, and you get the error:
>
> Error running onmouseup handle of handle 3:
> error in error handler
Works for me, unless I'm misunderstanding you. Can you describe the
exact steps you use to reproduce this?
> An interesting hidden features: if you write "_G" in Command Line you
> get the list of all Global variable defined....
I wouldn't call this "hidden", it's plainly documented in the Lua
reference manual...
> Some ideas on evolution of table inspector:
>
> 1) Click on a line in the table inspector, should write the
> variable/function/table name in the command line, for further analisys,
> for example, I inspect the table "pipmak", click on line containing
> "gotonode", and I get "pipmak.gotonode(" in the command line...
> a useful shortcut for lazy people....
Good idea. I have briefly though of this, but haven't followed it any
further because it's not that simple - given just a table (like the
pipmak table in the pipmak.gotonode example), you can't derive an
expression that results in it (i.e. "pipmak" in this example). The
command line and table inspector would have to work together to keep
track of how you arrived at the current table.
> 2) Resizable columns in the table inspector (long name are truncated)
Or, more fundamentally, resizable panels. The command line panel should
be resizable too.
> 3) Taking into consideration a tree structure for sub-table inspecting,
Personally, I like the column view better than the tree view for this
application, so that's basically what I've implemented (just that only
the rightmost column is visible at any time).
> and/or possibility to open subtable in another window.
At the moment that's not possible because nodes are designed as
singletons. We'll see whether it makes sense to revise that decision.
> 4) What you think about integration of my menu.lua in your gui.lua? (I
> added submenus and long menu manager to my last version)
Well, at the moment there just are no menus in the Pipmak user
interface, so the question is moot. If and when they appear, I'll
consider it, so thanks for the offer.
> Just a curiosity: do you think to add an embedded lua editor in pipmak
> (maybe with step by step debug), using texteditor functionalities?
No. First, because implementing a full text editor is a lot of work
(implementing the current text edit fields was enough already, and
they're still not complete), and I don't see a lot of value in it. Even
the debugger is probably best implemented as a separate application that
has access to the platform's full set of user interface components (I
don't know if there's an existing remote debugging solution for Lua
(like Winpdb for Python), but even writing our own would probably be
easier (and more useful) than doing it inside Pipmak with its limited
capabilities). Second, I don't think users would be happy with a text
editor that doesn't follow their platform's conventions. I'm hoping to
get away with that for the few single-line text fields, but even they
probably already have a distinct Mac-like feel to them.
> But what about different rendering of not-trasparent and trasparent PNG
> (see http://article.gmane.org/gmane.games.devel.pipmak.devel/76 )?
That's the next thing on my to-do list.
-Christian
|
|
From: Andrea V. <and...@gm...> - 2008-01-04 14:17:37
|
Hi, I read that you have improved error handling, adding a traceback, but with build 170 on every error I get always the message: Error running lua file error in error handling What I am wrong? Have I forgot something in building? Bye Andrea |
|
From: Andrea V. <and...@gm...> - 2008-01-04 12:06:00
|
Hello Christian!
First of all: Happy 2008!!
I have tried your last build 170: Nice work!!
The new Lua command line and the table inspector are very useful,
There are still a little bug, when you inspect a table contained in another
table, you cannot return to the first table pressing the arrow at top of the
window, and you get the error:
Error running onmouseup handle of handle 3:
error in error handler
this non appear if you inspect a table two level down (i.e: table inside a
table inside to another table), from the more depth table, you can return to
the father table, but next, you cannot return to the root table.
Perhaps, you know this, and you are working to fix.
An interesting hidden features: if you write "_G" in Command Line you get
the list of all Global variable defined....
The list includes also tables pipmak,math,string,.... a mode to view all the
function/method defined
debug.getinfo(func_name) return some information about the function,
including the lua file where is defined...useful!
Some ideas on evolution of table inspector:
1) Click on a line in the table inspector, should write the
variable/function/table name in the command line, for further analisys,
for example, I inspect the table "pipmak", click on line containing
"gotonode", and I get "pipmak.gotonode(" in the command line...
a useful shortcut for lazy people....
2) Resizable columns in the table inspector (long name are truncated)
3) Taking into consideration a tree structure for sub-table inspecting,
and/or possibility to open subtable in another window.
4) What you think about integration of my menu.lua in your gui.lua? (I
added submenus and long menu manager to my last version)
I have not tried to see if the bug about cached patches is disappear (but
I'm sure of that), but
I saw that the bug concerned patch dimensions is remained (using patch
without 3d positioning - see the visual difference in my autocubic project
in 0.2.6 and in build 168), you are working on it?
Just a curiosity: do you think to add an embedded lua editor in pipmak
(maybe with step by step debug), using texteditor functionalities?
Thank you for your work.
Bye
Andrea
|
|
From: Christian W. <cwa...@gm...> - 2008-01-02 17:26:28
|
Andrea Viarengo wrote:
> -- draw a BLACK square at the left of red square
>=20
> img2=3Dpipmak.loadimage("black.png")
> draw{distance=3D4,lateral=3D2,height=3D0,image=3Dimg2}
>=20
> -- draw a BLACK square at the right of red square
>=20
> img3=3Dpipmak.loadimage("black.png")
> draw{distance=3D4,lateral=3D-2,height=3D0,image=3Dimg3}
>=20
> -- draw a RED square above the first red square
>=20
> img4=3Dpipmak.loadimage("black.png")=20
> -- next statement show the bug:
> -- all the square become red!!!! Why?????
> img4:color(1,0.5,0.5,1):fill()
> draw{distance=3D4,lateral=3D0,height=3D2,image=3Dimg4}
I've just had a look at this, and I've come to the conclusion that it=20
works as designed - though admittedly the design is flawed.
What trips you up is this (from section 3.12 "Image Manipulation" of the =
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."
So what happens is that img2, img3, and img4 all refer to the same=20
object, and when you modify that object in the second-to-last line, the=20
change reflects in all three patches that use it.
(img1 is not involved because you modify it before loading img2, so at=20
that point loadimage knows that it really needs to reload the file and=20
give you a new image object.)
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, =
as I rely on it in many places. I'll try to think of something better,=20
but in the meantime I just wanted to let you know this much (I've kept=20
you waiting long enough...).
Thinking out loud: The fundamental issue is that the caching behavior of =
pipmak.loadimage, which was good for immutable objects, clashes with the =
fact that images have now become mutable. Perhaps some kind of=20
copy-on-write scheme could reunite the two.
-Christian
|
|
From: Christian W. <cwa...@gm...> - 2008-01-02 10:12:41
|
Aidan Gauland wrote: >> Hmm. I'm not too happy with that solution, to be honest. How are users >> supposed to find that out? >> > Well, I knew that the node with the list of key-bindings would have to > be updated. Sure, but that's not enough IMHO. I don't think people will go and check the preferences screen to find out how to get their mouse back. And what about that point in the future when the preliminary key bindings are gone and there's a real GUI preferences screen? Your solution just seems like an unacceptable regression in user experience to me (compared to a working auto-ungrab - of course the bug that prevents you and Urs from ungrabbing needs to be fixed). I'd rather fix this right than incorporate a workaround, even temporarily, that makes it worse where it worked before. Perhaps I need to explain why we grab the mouse at all in joystick mode - here's what I wrote about it in the commit message of rev. 123: Reworked mouse motion handling once more: The new seamless switching between mouse modes (see demo r124) made SDL's deficiencies (jumps in mouse position when grabbing or ungrabbing) really apparent. Now, the mouse is always grabbed in both mouse modes; in windowed mode, it can be ungrabbed by moving it out of the window against a slight edge resistance (which has the added benefit of making it easier to reach the edges of the window, e.g. for the inventory, on Windows and X11, where SDL sends no mouse events when the mouse is outside of the window). > could you please point me in the direction of a detailed SDL reference The most up-to-date SDL documentation is here: <http://www.libsdl.org/cgi/docwiki.cgi/SDL_20API>. It's probably not much more elaborate than the man pages, though. > or tell me how to get the coordinates for the unclamped mouse from within Pipmak. You can't get these directly from SDL, you need to keep track of them in your own variables by adding up the deltas from SDL_MOUSEMOTION events (these are unclamped when the mouse is grabbed). How to best keep this in sync with mouseX/mouseY is another question. > I will attach the patch I have made, to this message, as a quick fix for > people having this problem Thanks! As I alluded above, I won't apply it in its current form until I'm convinced that there's no better way to fix the problem. Some general comments nonetheless: - If you don't mind, please use unified diff format next time ('diff -u' if you use diff, 'svn diff' produces it by default). It's what most people are most familiar with. - Please use only tabs for indentation (you replaced some of them with spaces). > Sorry, I forgot to say this in my last message: you will need to pass > the -p 1 option to patch when you apply the patch I sent. That's apparent from the paths in the patch. > I would like to continue working on improving Pipmak's current behaviour. Very welcome! Don't hesitate to come here for help. If you're quick (or if I'm slow), we might get your changes into the 0.2.7 release I'm currently working on. (I originally planned to have it done this week, but I'm starting to doubt it. I'm currently putting the final touches on the Lua command line, next up are Andrea's bugs, and the demo project also needs expansion to include the new features.) -Christian |
|
From: Aidan G. <wgs...@ih...> - 2008-01-02 01:55:32
|
Sorry, I forgot to say this in my last message: you will need to pass the -p 1 option to patch when you apply the patch I sent. Sorry about that, Aidan |
12 messages has been excluded from this view by a project administrator.
![http://pipmak.sourceforge.net/temp/pipmak.jpeg"><http://pipmak.sourceforge.net/temp/pipmak.jpeg></a>](http://pipmak.sourceforge.net/temp/pipmak.jpeg"><http://pipmak.sourceforge.net/temp/pipmak.jpeg></a>){kind=link}
