Official PyGG2 Development thread

[notajf]

gitref.org

[Orpheon]

Oh, we're literally porting the whole game graphics and all. Interesting.

Also, anyone want to teach me how to GIT? lol

http://book.git-scm.com/

Also, who suggested changing graphics? Because I hadn't planned doing that.

And I still need help for the collision problem.

[Liam]

I've been looking at collision.py and I'm wondering what the logic behind lengthdir()

Code:

def lengthdir(x, y):

    x = x**2
    y = y**2

    return math.sqrt(x+y)

acting on the hspeed and vspeed at line 40. And in the next few lines at 49-51

Code:

# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/length
vs = character.vspeed/length

What is a normalized vector?
I see...

Then shouldn't you take the absolute value of the length there?

Like

Code:

# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/abs(length)
vs = character.vspeed/abs(length)

That seems to make the sprite less sticky and I get a bounceback effect off of walls.
But when landing on a surface you'll fall through slowly after a bit

[Orpheon]

I've been looking at collision.py and I'm wondering what the logic behind lengthdir()

Code:

def lengthdir(x, y):

    x = x**2
    y = y**2

    return math.sqrt(x+y)

acting on the hspeed and vspeed at line 40. And in the next few lines at 49-51

Code:

# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/length
vs = character.vspeed/length

What is a normalized vector?
I see...

Then shouldn't you take the absolute value of the length there?

Like

Code:

# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/abs(length)
vs = character.vspeed/abs(length)

That seems to make the sprite less sticky and I get a bounceback effect off of walls.
But when landing on a surface you'll fall through slowly after a bit

Well...

After staring at the code for a while, I found out that objectCheckCollision is based off rects, which aren't updated during the testing.  

Code: (What I'm working on right now)

def characterHitObstacle(character, wallmask):



newX = character.x
newY = character.y

oldX = character.x-character.hspeed
oldY = character.y-character.vspeed

hspeed = character.hspeed
vspeed = character.vspeed


length = lengthdir(hspeed, vspeed)

if length == 0:# You haven't moved; if this happens something went wrong

return False


# hs and vs is the normalized vector of hspeed and vspeed.
hs = character.hspeed/length
vs = character.vspeed/length

i = 0
while objectCheckCollision(character, wallmask) and i < length:

character.rect.centerx -= hs
character.rect.centery -= vs
i += 1


# The character got pushed out, but now we need to let him move in the directions he's allowed to move.

character.rect.centerx += sign(character.hspeed)

if not objectCheckCollision(character, wallmask):

# There's empty space on the left/right

# Kill all vertical movement
character.vspeed = 0

while True:

character.rect.centerx += sign(character.hspeed)

# If the new position has met a wall too:
if objectCheckCollision(character, wallmask):
character.rect.centerx -= sign(character.hspeed)
break

else:
character.rect.centerx -= sign(character.hspeed)
character.rect.centery += sign(character.vspeed)

if not objectCheckCollision(character, wallmask):

# There's empty space on the left/right

# Kill all vertical movement
character.hspeed = 0

i = 0
while i <= vspeed:

character.rect.centery += sign(character.vspeed)

# If the new position has met a wall too:
if objectCheckCollision(character, wallmask):
character.rect.centery -= sign(character.vspeed)
break

character.rect.centery -= sign(character.vspeed)


character.x = character.rect.left-character.xImageOffset
character.y = character.rect.top-character.yImageOffset
# character.hspeed = 0
# character.vspeed = 0

# character.hspeed = oldX-character.x
# character.vspeed = oldY-character.y

return True

This is still buggy.

EDIT: Actually, damn that code, I'll just make objectCheckCollision update the rects itself.


As for those vectors, it's basically just moving the character exactly one step in a certain direction. Length 1. I'm using the term unit vectors since they work on the same principle.

The point of that loop is to move the character at the last place during movement before any collision.

[MedO]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

[Psychopath]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

This is the part where they realize that there was an easy way already in existence and a few people hit themselves on the forehead for not noticing it sooner

[notajf]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

This is the part where they realize that there was an easy way already in existence and a few people hit themselves on the forehead for not noticing it sooner

Yep, like when I discovered Python actually had a TCP Server wrapper and there was no reason to use sockets directly.

[Orpheon]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

[Psychopath]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

[notajf]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

Collision checking is quicker with rects

[Orpheon]

Rect collision checking:

Code:

if range(left1, right1) in range(left2, right2):
{
    if range(top1, bottom1) in range(top2, bottom2):
    {
        return True
    }
}
return False

Mask collision checking involves checking each pixel individually.

[Psychopath]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

Collision checking is quicker with rects

I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.

[Orpheon]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

Collision checking is quicker with rects

I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.

The point is we'd have to do the raster-rect collision-ing ourselves. Which I have very little idea how. Also, most rects don't even get considered, they have to be close enough.

[Psychopath]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

Collision checking is quicker with rects

I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.

The point is we'd have to do the raster-rect collision-ing ourselves. Which I have very little idea how. Also, most rects don't even get considered, they have to be close enough.

You still have to technically parse through all existing rects just to identify which ones are near enough :v

[Orpheon]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

Collision checking is quicker with rects

I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.

The point is we'd have to do the raster-rect collision-ing ourselves. Which I have very little idea how. Also, most rects don't even get considered, they have to be close enough.

You still have to technically parse through all existing rects just to identify which ones are near enough :v

Of course. But you have to that too with masks, you know. Only you have 6 times more pixels than I have rects, and actually even more because I made the wallmask hollow shells. And it's one if loop to test the x, and if that's correct it's another if loop to test the y.