Tag Info

New answers tagged

0

You can use pygame.Rect.collidepoint() to get that the text was clicked on. The documentation on the function is here. Here is an example of how you can use the function to your desired effect: mpos = pygame.mouse.get_pos() # Get mouse position if spRect.collidepoint(mpos): # Check if position is in the rect # Code for what you wish the click to do ...


1

You should take a look at some vector math stuff, here's an example of a Vector class that will help you quite a bit in implementing this sort of logic. I think this is without bugs, but who knows. class Vector: def __init__(self, x, y): self.x = x self.y = y def __add__(self, other): return Vector(self.x + other.x, self.y + ...


0

So it looks to me like you want to move all of the sprites in the sprite Group initialization.platform_list by the same amount. It should not matter that the sprites in the group are not ordered or indexed. delta_x, delta_y = 0, 0 if (loadterrain.character.direction == self.left): delta_x += self.movementspeed #... for sprite in ...


0

You're currently checking if i.y == 0 and only creating the new road section if this is true. If you accelerate and the roads stop lining up perfectly with the bounds of the world, this statement will never be true because the y value will jump from positive to negative without hitting exactly zero. Try i.y<=0; this way, even if the road stops lining up ...


0

The problem happens because when you are pressing both the up key and either the left or right key, lets use right in this case, your player.move_y is negative, and that moved the player.rect.top to the wall.rect.bottom as you want, but the player.move_x is also possative, or negative if moving left, so the function not only moves your player to the bottom ...


0

I managed to find a commit on the Pygame BitBucket page here that explains the issue and gives an example on how to fix it. What is happening is that some display environments can be configured to stretch windows so they don't look small on high PPI (Pixels Per Inch) displays. This stretching is what causes displays on larger resolutions to display larger ...


0

I see you are running a 64bit version of Python. I tested this, and the version of Pygame you need runs on 32bit Python. You can go to the Python download page for Python 3.4.3 fromhttps://www.python.org/downloads/release/python-343/ Make sure to download Windows x86 MSI installer. Then you can download "pygame-1.9.2a0-hg_5974ff8dae3c+.win32-py3.4.msi" ...


0

Code: import pygame pygame.init() # ### class Player: def __init__(self): self.image = pygame.Surface((16,16)) # Create Player Image self.image.fill(colors["RED"]) # Fill Player Red self.rect = pygame.Rect((50,50),(16,16)) # Create Player Rect def move(self,camera_pos): pos_x,pos_y = camera_pos # Split camara_pos ...


0

The trick is I think you misunderstood my original answer to your previous question. The camera's position should only be taken into account when drawing (using blit). You're offsetting all drawn objects in the screen by the camera's position. So two specific problems with the code you have shown: The blit that does use the camera position should subtract ...


0

This may, or may not, be the correct answer for you, BUT In your code, when you draw the platforms images to the screen, you add the camera's position to their x/y positions. This would not be necessary because you would then have problems with colliding, because your adding the cameras scroll to it so you wouldn't see them in their colliding positions. ...


0

Take a look at this post. Basically you can keep the camera position around, and decide where to draw things based on that. I couldn't quite make sense of your game but here are some brief changes I made: ... total_level_width = len(level[0])*32 total_level_height = len(level)*32 map_size = pygame.Rect(0, 0, total_level_width, total_level_height) ...


0

To simply fix your error: after the line self.dx,self.dy = self.mouse try adding self.dx -= offsetx self.dy -= offsety Note this is not an ideal solution. In general though to avoid similar future problems I would further separate the concept of screen space and world space, possibly by the addition of something like a "camera" class. You could even add ...



Top 50 recent answers are included