Line Collision

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Line Collision

gabrielslomka
Hey, supose i have a Rect and a Line, i just want to see if the line intercepts the rect, is that possible somehow in a kind of optimized way ? Im having trouble implementing this.

Thanks in advance !
Reply | Threaded
Open this post in threaded view
|

Re: Line Collision

Martin Kühne
think about it this way:

if the line is fully left, fully right, fully above or fully beneath
the rectangle, it's not close to the rectangle.

to find the closest approach to the rectangle you usually equate the
rectangle's border lines with the line to be compared as a function:

with exception of vertical lines, a line always has a "rise", that is
a number of y pixels for any x pixel crossing the x axis at a vertical
offset, mathematically that's the classically linear function
expressed with f(x): y = ax + b. Equating that with the lowest and
highest x coordinates of the rectangle gives you two equations y = a *
left + b and y = a * right + b which, when solved for y can then be
compared with the rect's top and bottom coordinate. the rectangle is
obviously crossed if one of the variables is inside the vertical
interval or if they are on opposite sides of the vertical interval; in
code, that's roughly summarized with the following if line:

if ((a * left + b) < bottom and (a * right + b) > bottom) or ((a *
left + b) > top and (a * right + b) < top)):

Welcome to the world of linear algebra. from here onwards you only
need to get used to it enough to figure the case of a vertical line
too.

cheers!
mar77i
Reply | Threaded
Open this post in threaded view
|

Re: Line Collision

Martin Kühne
A central key in the whole task is gaining good control over which of
>, <, <=, >= you need to use to compare different intervals, so to say
whether either first's bottom is lower than second's top value or
whether first's top is lower than second's bottom value. But this kind
of interval comparison is only possible when you, as the second
exercise, are able to boil the problem down to actual interval
comparisons.

As I don't know how much linear algebra you need to catch up on here,
please ask away for any furhter clarification, maybe I or even
somebody else in this channel is able to take you through the task
from where you stand in a more specific manner.

cheers!
mar77i
bw
Reply | Threaded
Open this post in threaded view
|

Re: Line Collision

bw
In reply to this post by gabrielslomka
It seems so simple a problem to our eyes. But it's computationally a
non-trivial problem. You can find algorithms on the web mostly in other
languages and convert them to Python, like I did here.

https://bitbucket.org/gummbum/gummworld2/src/200e9350acca33d40b0c41c9e74c0eaeb6079061/gamelib/gummworld2/geometry.py?at=default&fileviewer=file-view-default#geometry.py-151

I would love to see this stuff in a native lib. I might do it myself
but...Windows.


On 11/18/2017 8:26 AM, [hidden email] wrote:
> Hey, supose i have a Rect and a Line, i just want to see if the line
> intercepts the rect, is that possible somehow in a kind of optimized
> way ? Im having trouble implementing this.
>
> Thanks in advance !

Reply | Threaded
Open this post in threaded view
|

Delay in MOUSEBUTTONUP after application start

Irv Kalb
I have been working on the development of a number of demonstration games using pygame.  I use these as demonstration pieces in classes that I teach.

I do my development on an older Mac using Mac OS X 10.12.6, with Python 3.6.1 and pygame (not sure how to check what version, but fairly recent).   I'm running these demo programs in IDLE.

I have built a library of user interface widgets that I use often.  One of these is a typical button widget.  My button widget code shows an "up" state', an "over" state, and a "down" state image.  I have used this code for years, and it works well.  However, I have seen an odd behavior at the start of the programs.  

I finally decided to do some debugging and found that the problem is in pygame sending the MOUSEBUTTONUP event.  If I click right away after starting the program, the MOUSEBUTTONDOWN event comes in followed quickly by a MOUSEBUTTONUP.  If I click again quickly, I get the MOUSEBUTTONDOWN event, BUT, there is a delay of about one to three second before my code gets the related MOUSEBUTTONUP event.  Other events work fine, and I can tell that the program is still running through the main loop (I can output a count of frames to the shell window, and that continues to increase).  The MOUSEBUTTONUP eventually does happen after the delay.  After that, all the MOUSEBUTTONUP events come in just fine, and my code works well.  Button clicks work perfectly.



Here is a minimal program (without using my interface widgets) that demonstrates the problem.  I just click on the background of the window, and the program outputs a message to the shell when it gets the MOUSEBUTTONDOWN and MOUSEBUTTONUP events:

import pygame
from pygame.locals import *
import sys

BACKGROUND_COLOR = (0, 180, 180)
WINDOW_WIDTH = 640
WINDOW_HEIGHT = 480
FRAMES_PER_SECOND = 30

pygame.init()
window = pygame.display.set_mode([WINDOW_WIDTH, WINDOW_HEIGHT])
clock = pygame.time.Clock()  # set the speed (frames per second)
counter = 0

while True:
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
            # if it is quit, the program
            pygame.quit()
            sys.exit()
           
        if event.type == MOUSEBUTTONUP:
            print('******* Got a MOUSEBUTTONUP *******')

        if event.type == MOUSEBUTTONDOWN:
            print('******* Got a MOUSEBUTTONDOWN *******')

    print(counter)
    counter = counter + 1

    window.fill(BACKGROUND_COLOR)
    pygame.display.update()
    clock.tick(FRAMES_PER_SECOND)  # make PyGame wait the correct amount


Here is a sample run:

I clicked the background right way (notice first matching MOUSEBUTTONDOWN and MOUSEBUTTONUP) work fine.

Then I clicked again (got a MOUSEBUTTONDOWN right away, but notice how many frames elapsed before the related MOUSEBUTTONUP).  

After the long delay, the MOUSEBUTTONDOWN and MOUSEBUTTONUP's all work fine and respond quickly.


Python 3.6.1 (v3.6.1:69c0db5050, Mar 21 2017, 01:21:04)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "copyright", "credits" or "license()" for more information.
>>>
 RESTART: /Users/irvkalb/Desktop/PygWidgets Dev/pygame MOUSEBUTTONDOWN bug.py
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
******* Got a MOUSEBUTTONDOWN *******
18
19
******* Got a MOUSEBUTTONUP *******
20
21
22
23
24
25
26
27
28
29
30
31
******* Got a MOUSEBUTTONDOWN *******
32
33
34
35
36
37
38
39
40
41
<------------------------   Snipped 42 to 137 to save space!    -------------->
138
139
140
141
142
143
144
******* Got a MOUSEBUTTONUP *******
145
146
147
148
149
150
151
152
153
******* Got a MOUSEBUTTONDOWN *******
154
******* Got a MOUSEBUTTONUP *******
155
156
157
158
159
160
161
162
163
164
165
******* Got a MOUSEBUTTONDOWN *******
166
167
168
******* Got a MOUSEBUTTONUP *******
169
170
171


I see this type of output consistently.

I am curious to know if anyone else has seen this behavior - or can reproduce it with this simple program (you can comment out the print statement that prints the loop counts).  More importantly, is there anything that can be done about it?  Not a big problem - just an annoyance.

Irv


Reply | Threaded
Open this post in threaded view
|

Re: Line Collision

Thomas Kluyver
In reply to this post by bw
Shapely (http://toblerity.org/shapely/manual.html ) is a Python library with functions for things like 'do these two shapes intersect?' I don't know if building the Shapely objects is quick enough to be done during a game, but it's worth a try.

On 18 November 2017 at 18:55, bw <[hidden email]> wrote:
It seems so simple a problem to our eyes. But it's computationally a non-trivial problem. You can find algorithms on the web mostly in other languages and convert them to Python, like I did here.

https://bitbucket.org/gummbum/gummworld2/src/200e9350acca33d40b0c41c9e74c0eaeb6079061/gamelib/gummworld2/geometry.py?at=default&fileviewer=file-view-default#geometry.py-151

I would love to see this stuff in a native lib. I might do it myself but...Windows.



On 11/18/2017 8:26 AM, [hidden email] wrote:
Hey, supose i have a Rect and a Line, i just want to see if the line intercepts the rect, is that possible somehow in a kind of optimized way ? Im having trouble implementing this.

Thanks in advance !


Reply | Threaded
Open this post in threaded view
|

Re: Line Collision

Greg Ewing
In reply to this post by gabrielslomka
[hidden email] wrote:
> Hey, supose i have a Rect and a Line, i just want to see if the line
> intercepts the rect, is that possible somehow in a kind of optimized way

For axis-aligned rectangles you probably want the Cohen-Sutherland
algorithm:

https://en.wikipedia.org/wiki/Cohen%E2%80%93Sutherland_algorithm

If all you want to know is whether they intersect or not, you can
just use the first part (calculating the outcodes and ANDing them
together).

--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: Delay in MOUSEBUTTONUP after application start

Ian Mallett-2
In reply to this post by Irv Kalb
​Hi,

FWIW I am unable to reproduce on Win 7 Pro, Py 3.5.1, PyGame 1.9.2a0 (to print the latter, `print(pygame.ver)`).

The event system, like everything else, is really just a thin layer over SDL's—so for platform-specific issues in PyGame it's commonly the underlying SDL that's at fault. Notwithstanding that SDL is fairly well-tested, but Mac tends to be a lower priority for testing, on account of Apple making game development on OS X difficult in a variety of ways. My guess is that it's a minor hiccup in older SDL on MacOS that no one ever noticed before, additionally because MOUSEBUTTONUP is often ignored—in which case you're most likely to get closure from the SDL community, unless someone here feels like C spelunking.

Maybe `pygame.event.clear()` would trick the event system into behaving better on startup?

Ian
bw
Reply | Threaded
Open this post in threaded view
|

Re: Delay in MOUSEBUTTONUP after application start

bw

Interesting notion, event.clear(). Or perhaps try an event.pump() in the game loop.


On 11/18/2017 11:28 PM, Ian Mallett wrote:
​Hi,

FWIW I am unable to reproduce on Win 7 Pro, Py 3.5.1, PyGame 1.9.2a0 (to print the latter, `print(pygame.ver)`).

The event system, like everything else, is really just a thin layer over SDL's—so for platform-specific issues in PyGame it's commonly the underlying SDL that's at fault. Notwithstanding that SDL is fairly well-tested, but Mac tends to be a lower priority for testing, on account of Apple making game development on OS X difficult in a variety of ways. My guess is that it's a minor hiccup in older SDL on MacOS that no one ever noticed before, additionally because MOUSEBUTTONUP is often ignored—in which case you're most likely to get closure from the SDL community, unless someone here feels like C spelunking.

Maybe `pygame.event.clear()` would trick the event system into behaving better on startup?

Ian

Reply | Threaded
Open this post in threaded view
|

Re: Delay in MOUSEBUTTONUP after application start

DiliupG
A serious computing device never gives such issues.

Virus-free. www.avast.com

On 20 November 2017 at 02:26, bw <[hidden email]> wrote:

Interesting notion, event.clear(). Or perhaps try an event.pump() in the game loop.


On 11/18/2017 11:28 PM, Ian Mallett wrote:
​Hi,

FWIW I am unable to reproduce on Win 7 Pro, Py 3.5.1, PyGame 1.9.2a0 (to print the latter, `print(pygame.ver)`).

The event system, like everything else, is really just a thin layer over SDL's—so for platform-specific issues in PyGame it's commonly the underlying SDL that's at fault. Notwithstanding that SDL is fairly well-tested, but Mac tends to be a lower priority for testing, on account of Apple making game development on OS X difficult in a variety of ways. My guess is that it's a minor hiccup in older SDL on MacOS that no one ever noticed before, additionally because MOUSEBUTTONUP is often ignored—in which case you're most likely to get closure from the SDL community, unless someone here feels like C spelunking.

Maybe `pygame.event.clear()` would trick the event system into behaving better on startup?

Ian




--
http://www.diliupg.com

**********************************************************************************************
This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.
**********************************************************************************************

Reply | Threaded
Open this post in threaded view
|

Re: Delay in MOUSEBUTTONUP after application start

Irv Kalb
In reply to this post by Ian Mallett-2

On Nov 18, 2017, at 11:28 PM, Ian Mallett <[hidden email]> wrote:

​Hi,

FWIW I am unable to reproduce on Win 7 Pro, Py 3.5.1, PyGame 1.9.2a0 (to print the latter, `print(pygame.ver)`).

The event system, like everything else, is really just a thin layer over SDL's—so for platform-specific issues in PyGame it's commonly the underlying SDL that's at fault. Notwithstanding that SDL is fairly well-tested, but Mac tends to be a lower priority for testing, on account of Apple making game development on OS X difficult in a variety of ways. My guess is that it's a minor hiccup in older SDL on MacOS that no one ever noticed before, additionally because MOUSEBUTTONUP is often ignored—in which case you're most likely to get closure from the SDL community, unless someone here feels like C spelunking.

Maybe `pygame.event.clear()` would trick the event system into behaving better on startup?

Ian


Thanks for the suggestion.  I did try adding a call to event.clear() after my for loop where I check for events, but there was no change.  I also tried event.pump(), and I'm still seeing the delay.

And thanks for letting me know how to check the version of pygmae.  I am running 1.9.3

I also checked in on my Windows system, and I cannot reproduce it there either.

One other thing I just found out.  Even if I start the program running (on my Mac), and wait for a while before the first click, (maybe 2 to 3 seconds), again the first click goes through just fine, but the second click shows the MOUSEBUTTONDOWN right away, but the matching MOUSEBUTTONUP still delays from 1 to 3 seconds.  Definitely strange.

Irv

Reply | Threaded
Open this post in threaded view
|

Re: Delay in MOUSEBUTTONUP after application start

Noel Garwick
If you tie it to something other than a print statement, are you still seeing a delay?

And maybe this is a dumb question, but are you using the same mouse when you test on Windows and OSX? Just to rule out anything physically different with the mouse...

On Sun, Nov 19, 2017 at 11:29 PM, Irv Kalb <[hidden email]> wrote:

On Nov 18, 2017, at 11:28 PM, Ian Mallett <[hidden email]> wrote:

​Hi,

FWIW I am unable to reproduce on Win 7 Pro, Py 3.5.1, PyGame 1.9.2a0 (to print the latter, `print(pygame.ver)`).

The event system, like everything else, is really just a thin layer over SDL's—so for platform-specific issues in PyGame it's commonly the underlying SDL that's at fault. Notwithstanding that SDL is fairly well-tested, but Mac tends to be a lower priority for testing, on account of Apple making game development on OS X difficult in a variety of ways. My guess is that it's a minor hiccup in older SDL on MacOS that no one ever noticed before, additionally because MOUSEBUTTONUP is often ignored—in which case you're most likely to get closure from the SDL community, unless someone here feels like C spelunking.

Maybe `pygame.event.clear()` would trick the event system into behaving better on startup?

Ian


Thanks for the suggestion.  I did try adding a call to event.clear() after my for loop where I check for events, but there was no change.  I also tried event.pump(), and I'm still seeing the delay.

And thanks for letting me know how to check the version of pygmae.  I am running 1.9.3

I also checked in on my Windows system, and I cannot reproduce it there either.

One other thing I just found out.  Even if I start the program running (on my Mac), and wait for a while before the first click, (maybe 2 to 3 seconds), again the first click goes through just fine, but the second click shows the MOUSEBUTTONDOWN right away, but the matching MOUSEBUTTONUP still delays from 1 to 3 seconds.  Definitely strange.

Irv


Reply | Threaded
Open this post in threaded view
|

Re: Delay in MOUSEBUTTONUP after application start

Irv Kalb

On Nov 19, 2017, at 8:44 PM, Noel Garwick <[hidden email]> wrote:

If you tie it to something other than a print statement, are you still seeing a delay?

Yes.  The print statement was a simplification.  I noticed this problem in code that I have written for a Button object which shows different states (images) of a button.  I noticed that the first click on a button worked fine, but the second click showed the down state (reacting to the MOUSEBUTTONDOWN event) for a long time before showing the up state (reacting to the MOUSEBUTTONUP event) again.


And maybe this is a dumb question, but are you using the same mouse when you test on Windows and OSX? Just to rule out anything physically different with the mouse...

Not a dumb question at all.  I just took the mouse off my PC (where I did not se the problem), and plugged into my Mac.  I still see the delay on the Mac,

Thanks for asking.

Irv


On Sun, Nov 19, 2017 at 11:29 PM, Irv Kalb <[hidden email]> wrote:

On Nov 18, 2017, at 11:28 PM, Ian Mallett <[hidden email]> wrote:

​Hi,

FWIW I am unable to reproduce on Win 7 Pro, Py 3.5.1, PyGame 1.9.2a0 (to print the latter, `print(pygame.ver)`).

The event system, like everything else, is really just a thin layer over SDL's—so for platform-specific issues in PyGame it's commonly the underlying SDL that's at fault. Notwithstanding that SDL is fairly well-tested, but Mac tends to be a lower priority for testing, on account of Apple making game development on OS X difficult in a variety of ways. My guess is that it's a minor hiccup in older SDL on MacOS that no one ever noticed before, additionally because MOUSEBUTTONUP is often ignored—in which case you're most likely to get closure from the SDL community, unless someone here feels like C spelunking.

Maybe `pygame.event.clear()` would trick the event system into behaving better on startup?

Ian


Thanks for the suggestion.  I did try adding a call to event.clear() after my for loop where I check for events, but there was no change.  I also tried event.pump(), and I'm still seeing the delay.

And thanks for letting me know how to check the version of pygmae.  I am running 1.9.3

I also checked in on my Windows system, and I cannot reproduce it there either.

One other thing I just found out.  Even if I start the program running (on my Mac), and wait for a while before the first click, (maybe 2 to 3 seconds), again the first click goes through just fine, but the second click shows the MOUSEBUTTONDOWN right away, but the matching MOUSEBUTTONUP still delays from 1 to 3 seconds.  Definitely strange.

Irv