Position of rect

  • (3 Pages)
  • +
  • 1
  • 2
  • 3

31 Replies - 929 Views - Last Post: 07 February 2014 - 12:57 PM Rate Topic: -----

#16 modi123_1  Icon User is offline

  • Suitor #2
  • member icon



Reputation: 8964
  • View blog
  • Posts: 33,624
  • Joined: 12-June 08

Re: Position of rect

Posted 04 February 2014 - 03:41 PM

I am not forcing you to do any of the tutorials outside of telling you that having the blueprints and foundation first then using that to build upon is a substantially better way about learning how to program than fumbling around for concepts you are unclear - or unable- to even articulate.

I am certain there are a few tutorials out on the internet (probably like.. two or five) that teach python without couching the whole deal in RPG game making.
Was This Post Helpful? 1
  • +
  • -

#17 Mekire  Icon User is offline

  • D.I.C Head

Reputation: 116
  • View blog
  • Posts: 212
  • Joined: 11-January 13

Re: Position of rect

Posted 04 February 2014 - 04:42 PM

Documentation.clamp_ip

View Postproject21124, on 04 February 2014 - 07:51 PM, said:

You said to ask you questions about your version of the problem.
Here they are:
What does clamp_ip() do, and why did you use it?
What does line 56 do, and why do you use it?
Why would you use the whole fps/Clock thing(I know how it works, I just don't know what the point of it is)?
What in the world does line 87 do!?


Firstly, yes, I could have made some minor changes to your program and made it run. I deemed this a bad choice because there were so many things that needed addressing.

For most of your questions I was hoping you would have done a search before asking. If you were learning a new language and hit a word you didn't know, would you bug your teacher, or pick up a dictionary:

clamp_ip keeps our rect inside the screen_rect. It checks if our rect is inside the argument rect, and if not it moves it inside. This eliminates the need for messy inequalities to keep us on the screen.
Documentation.

Line 56 just sets an SDL environment variable telling the window to be created centered on the screen. There is no requirement to use it; it is just boiler plate. It eliminates the chance of half the window appearing off screen.

All pygame programs require a clock. This should not be considered voluntary. Without a clock a program will run as fast as computation allows. This is bad for the obvious reason that you are using far too much processor power to do nothing. The other very important reason is that it makes the program run differently on different machines. Something that might run fine for you, might fly off the screen in a tenth of a second for someone else, and vice-versa.

if __name__ == "__main__": Tells our program to only run the code in this block if the program is executed directly. This means that if we want to import the code and use the classes in another module we can, without unwanted side-effects. Again, easily searchable:
What does `if __name__ == __main__:` do?


Regarding other things. Basic, basics. Imports go first; next GLOBAL_CONSTANTS (these should be capitalized); next functions and classes; then if necessary code that executes when run as main (in an if __name__ == "__main__": block).

Next coordinates. You don't need to keep track of your coordinates seperately from your rect (unless you have floating points). Rects are probably the most useful construct in pygame; use them to your full advantage.

And classes. You said Zed spent too much time on classes? Well, you need to spend some more time.
This demonstrates a lack of understanding, as I said:
def drawHero(self):
    Screen.blit(self.hero, (self.x, self.y))
    if hero_sprite.x <= 0:
        hero_sprite.x += 2
    if hero_sprite.y <= 0:
        hero_sprite.y += 2
    if collide(hero_sprite, object_c):
        print "COLLIDE"
        Screen.blit(self.hero, (self.x, self.y))
    else: 
        print "NOT_COLLIDING"
        Screen.blit(self.hero, (self.x, self.y))
hero_sprite is a global instance of Hero_Sprite. It should not be referenced inside the Hero_Sprite definition. Those should all be self instead. The point of classes is they are factories. You have, by doing this made it impossible to create more than one instance of your class (and even make it so that instance better be given a specific name in the global scope). All this is bad (even if you have no intent of making more than one hero, it is still wrong).

If you are interested in learning more, ask more questions. If you aren't interested in listening to anything I have to say, don't.

-Mek

This post has been edited by Mekire: 04 February 2014 - 11:04 PM

Was This Post Helpful? 2
  • +
  • -

#18 project21124  Icon User is offline

  • New D.I.C Head

Reputation: 4
  • View blog
  • Posts: 40
  • Joined: 02-February 14

Re: Position of rect

Posted 04 February 2014 - 05:56 PM

Thank you for answering my questions, but I said that "he spent 15 exercises on printing, and only(Note, I said ONLY), 2 exercises on classes".
I understand that using global instances is bad, I really do. I just needed to get collide_rect() to work correctly.
Thank you for your time.
Was This Post Helpful? 0
  • +
  • -

#19 Mekire  Icon User is offline

  • D.I.C Head

Reputation: 116
  • View blog
  • Posts: 212
  • Joined: 11-January 13

Re: Position of rect

Posted 04 February 2014 - 06:41 PM

View Postproject21124, on 04 February 2014 - 10:24 PM, said:

I read through "Learn Python the Hard Way", but he spent like 15 exercises on printing, and like 2 on classes...

Ah, sorry. I misinterpreted the "like". I haven't looked closely at LPTHW. I hear that Zed does some things that don't help to make the subject very clear (and has ignored a lot of critical advice from peers on the matter).

Anyway, here is my repo of samples if you are interested:
https://github.com/M...-pygame-samples
They range from introductory (to pygame, not python) with:
https://github.com/M...color_change.py
To fairly advanced with:
https://github.com/M...ng_platforms.py

-Mek

This post has been edited by Mekire: 04 February 2014 - 06:43 PM

Was This Post Helpful? 0
  • +
  • -

#20 project21124  Icon User is offline

  • New D.I.C Head

Reputation: 4
  • View blog
  • Posts: 40
  • Joined: 02-February 14

Re: Position of rect

Posted 04 February 2014 - 09:53 PM

So...say I want to check if a rect is colliding with another rect, I would do basically this:

pygame.sprite.collide_rect(RectOne, RectTwo)



But...that just checks if they are colliding, not which side is colliding with which side.
I need to know how to formulate the (x,y) values of the side of a square. I have no idea how to do that, any suggestions?
I'll be googling this, but if you guys answer before I find it online, then way to go!
Thanks :bigsmile:
Was This Post Helpful? 0
  • +
  • -

#21 modi123_1  Icon User is offline

  • Suitor #2
  • member icon



Reputation: 8964
  • View blog
  • Posts: 33,624
  • Joined: 12-June 08

Re: Position of rect

Posted 04 February 2014 - 10:00 PM

Just think about it.

If square1 is standing there.. and square2 is coming in from the right to the left.. hitting square1 on its right side then that means square2's left edge is farther left than square1's right edge. Knowing the moving square's left side is more left than the right hand side of square1 you can deduce it came in from that direction.

Seems like a basic set of if statements.
Was This Post Helpful? 0
  • +
  • -

#22 project21124  Icon User is offline

  • New D.I.C Head

Reputation: 4
  • View blog
  • Posts: 40
  • Joined: 02-February 14

Re: Position of rect

Posted 04 February 2014 - 10:32 PM

....exactly, what was I thinking!?
Was This Post Helpful? 0
  • +
  • -

#23 macosxnerd101  Icon User is offline

  • Self-Trained Economist
  • member icon




Reputation: 10397
  • View blog
  • Posts: 38,479
  • Joined: 27-December 08

Re: Position of rect

Posted 04 February 2014 - 10:34 PM

Merged related threads.
Was This Post Helpful? 0
  • +
  • -

#24 project21124  Icon User is offline

  • New D.I.C Head

Reputation: 4
  • View blog
  • Posts: 40
  • Joined: 02-February 14

Re: Position of rect

Posted 04 February 2014 - 10:35 PM

View Postmacosxnerd101, on 05 February 2014 - 05:34 AM, said:

Merged related threads.

Thanks :)
Was This Post Helpful? 0
  • +
  • -

#25 Mekire  Icon User is offline

  • D.I.C Head

Reputation: 116
  • View blog
  • Posts: 212
  • Joined: 11-January 13

Re: Position of rect

Posted 04 February 2014 - 10:48 PM

Well I would say it is slightly more complicated than that. In 1D determining the direction of collision is simple and is just as modi123_1 says. In two dimensions it is a bit trickier. One fairly simple to implement technique is stepping the square in the x and y axis in seperate phases. Step it in x, then check collisions (you can find direction of collision as per the 1d method). Then adjust, and step in y doing the same.

If you want an actual vector for the direction of collision (normal vector) it is more tricky still, but can be done by calculating a finite difference between colliding surfaces (probably too much to go into right now).

As for finding exact locations of corners/side/points on a rectangle, familiarize yourself with all the "attributes" which can be used with rects.

These include:
x,y
top, left, bottom, right
topleft, bottomleft, topright, bottomright
midtop, midleft, midbottom, midright
center, centerx, centery
size, width, height
w,h


You can always find out the location of a specific part of a rectangle this way and can even assign directly to them.
>>> import pygame
>>> a = pygame.Rect(25, 30, 50, 75)
>>> a.topleft
(25, 30)
>>> a.bottomright
(75, 105)
>>> a.midtop
(50, 30)
>>> a.center
(50, 67)
>>> a.centery
67
>>> a.center = 0,0
>>> a
<rect(-25, -37, 50, 75)>
>>> 

-Mek
Was This Post Helpful? 1
  • +
  • -

#26 project21124  Icon User is offline

  • New D.I.C Head

Reputation: 4
  • View blog
  • Posts: 40
  • Joined: 02-February 14

Re: Position of rect

Posted 04 February 2014 - 11:12 PM

Thanks Mekire, that will be useful. i don't have access to a computer right now, so I'll just ask you guys.
Is something like this viable?
class Box1(pygame.sprite.Sprite):
#normal box w/ image stuff
self.topline = pygame.draw.line(displayScreen, color, (self.x, self.y), self.x+self.image.get_width(), self. y)
#etc, etc

class Box2(pygame.sprite.Sprite):
#normal box w/ image stuff
self.topline = pygame.draw.line(displayScreen, color, (self.x, self.y), self.x+self.image.get_width(), self. y)
#etc, etc



And then I could just see if Box1's right line collided with Box2's left line, or whatever. Problem is, I don't see any "collide_line()" functions in pygame.
I'll just do what you suggested Mekire, as that makes sense, but I wish there was a collide_line() function in pygame, it would simplify things so much!
Was This Post Helpful? 0
  • +
  • -

#27 Mekire  Icon User is offline

  • D.I.C Head

Reputation: 116
  • View blog
  • Posts: 212
  • Joined: 11-January 13

Re: Position of rect

Posted 04 February 2014 - 11:30 PM

Well you can always do collision detection with a single pixel thick rect. No issues there, and has its uses, though maybe not for this. Of course that would only work for straight lines.

For your psuedo classes though I really encourage you to experiment with rect attributes immediately.

No need for this:
(self.x, self.y), (self.x+self.image.get_width(), self. y)
You should make a rect from your image with get_rect and then do this:
self.rect.topleft, self.rect.topright

-Mek

This post has been edited by Mekire: 04 February 2014 - 11:36 PM

Was This Post Helpful? 1
  • +
  • -

#28 project21124  Icon User is offline

  • New D.I.C Head

Reputation: 4
  • View blog
  • Posts: 40
  • Joined: 02-February 14

Re: Position of rect

Posted 05 February 2014 - 10:32 AM

View PostMekire, on 05 February 2014 - 06:30 AM, said:

Well you can always do collision detection with a single pixel thick rect. No issues there, and has its uses, though maybe not for this. Of course that would only work for straight lines.

For your psuedo classes though I really encourage you to experiment with rect attributes immediately.

No need for this:
(self.x, self.y), (self.x+self.image.get_width(), self. y)
You should make a rect from your image with get_rect and then do this:
self.rect.topleft, self.rect.topright

-Mek

The funny thing is, I didn't even know about those rect attributes, and it will simplify things so much more, now that I know they exist. Thank you for your help, it is appreciated. I hope to someday be able to help people on this forum as much as you have helped me.
Was This Post Helpful? 0
  • +
  • -

#29 project21124  Icon User is offline

  • New D.I.C Head

Reputation: 4
  • View blog
  • Posts: 40
  • Joined: 02-February 14

Re: Position of rect

Posted 06 February 2014 - 09:22 AM

It just hit me.
Like a brick wall.
Why don't I use a conjunction? I mean, it makes perfect sense, that is what a conjunction is on the Cartesian plane(A line, if done correctly), it will just take a little fiddling to get the right algorithm.
Think it will work?
Was This Post Helpful? 0
  • +
  • -

#30 Mekire  Icon User is offline

  • D.I.C Head

Reputation: 116
  • View blog
  • Posts: 212
  • Joined: 11-January 13

Re: Position of rect

Posted 06 February 2014 - 11:33 PM

View Postproject21124, on 06 February 2014 - 04:22 PM, said:

Why don't I use a conjunction? I mean, it makes perfect sense, that is what a conjunction is on the Cartesian plane(A line, if done correctly)
Are you sure that is the word you are looking for?
If it is, then I don't know what we are talking about here.

If on the other hand you mean a function (in the mathematical sense), then yes, you can calculate collisions with functions (y = mx + b for a straight line).

Slightly confused,
-Mek
Was This Post Helpful? 0
  • +
  • -

  • (3 Pages)
  • +
  • 1
  • 2
  • 3