[pygame] unsubscribe pygame-users
unsubscribe pygame-users
Re: [pygame] My solid tile detection doesn't work
Thanks to Scott and his question on rects, and Brian's tip on internal documentation - thanks guys - my little dude can run around and bump into bushes and things quite well. Yet there remains one problem... When he's positioned in between tiles, he can walk up or down onto part of a solid tile, because I used his rect.centerx, i.e. directly between his feet, as the point to check for collisions. I want to check everywhere under his little feet. Do I have to check twice, on his left and his right, or is there a simpler way to do the collision checking. Oh, and I don't have this problem going left and right because I set his feet (rect.bottom) as the point for collision checking, so it just looks like he has height, which he should. On 7/23/06, Adeola Bannis <[EMAIL PROTECTED]> wrote: Yes, playerpos and tilepos are supposed to be the same domain. I realised that the camera coordinates were not taken into consideration. When I did take them into consideration, it only reported the right tile when I moved horizontally. Vertical motion is still all wonky. I relabelled the player coordinates so I could walkthrough my algorithm more clearly. I'm still at a loss as to what I'm doing wrong... On 7/22/06, Brian Fisher <[EMAIL PROTECTED]> wrote: > I assume that the problem you have is that the player draws over > different tiles than the attached code is saying the player is moving > over? > > If that's the case the code you sent could be perfectly correct, or it > could be wrong, it really depends on how the coordinates in these > routines are interpreted by other parts of the system, like when you > blit... what I'm thinking of is that it's impossible to tell from this > code alone whether the player_x and player_y values you pull from > player_pos are supposed to be in the same domain as the computed > "truex" and "truey" for a tile - meaning are they both supposed to be > used in the exact same way & are they supposed to be comparable (i.e. > do you blit tiles at truex,truey and players at playerx,playery?) > > My general tip for doing stuff with coordinates is to always think of > different coordinates as being parts of different named coordinate > systems or domains, and always name variables with a suffix that makes > the coordinate system explicit. Like if coordinates can be blit to the > screen, they could be "player_screen_x", if they are supposed to be > map grid locations it might be "player_map_grid_x" if it's supposed to > be a pixel offset in the map it might be "player_map_pixel_x". It may > seem like a lot of typing at first, but it really makes you think > about coordinates more, and in the end you are typing lines that read > like English sentences, so it's easier for you to know if the line is > doing the right thing at a glance, and it's really easy for other > people to look at your code. > > So one thing I notice is that your mapping from a "tilepos" to a > "true" position for all your tiles depends on the values of starty and > startx and xoff and yoff, while the mapping from "playerpos" to a > "tilepos" doesn't use startx and starty or xoff and yoff at all - so > if both "true" coordinates and "player" coordinates are in the same > domain (like if you pass them directly to pygame to blit) then your > mappings aren't symmetric when any of startx, starty, xoff and yoff > are non-zero. > > And if playerpos and tilepos are not supposed to be the same domain > (i.e. there is some other mapping of playerpos and "truex, truey" > before they get blit), then there may be problems with that other > coordinate mapping code in addition to any problems that might exist > in this code. > > On 7/22/06, Adeola Bannis <[EMAIL PROTECTED]> wrote: > > In my little RPG engine-like thing that no one tested, *wink wink*, I > > tried implementing solid tiles. My algorithm doesn't work, and I don't > > know why. > > > > This is the code I use to place tiles onscreen, only the important > > half of the function: > > ---code--- > > for y in range(starty, endy): > > for x in range(startx, endx): > > tilepos = y*(self.mapw) + x; #The position in our array of tiles > > showx = x - startx; showy = y - starty #Adjust the position of map > > by blitting it to the top > > truex = (showx*tilesize-xoff); truey = (showy*tilesize-yoff) > > #print endy > > tilenum = self.tiles[tilepos] > > self.put_tile(tilenum,(truex,truey), screen) > > ---code--- > > > &g
Re: [pygame] Rects and they handle right and bottom borders
You know, this made me realise that the 'overlapping' of rects was part of the problem with my collision detection... I have a few - 1's to put in now... On 8/1/06, Nelson, Scott <[EMAIL PROTECTED]> wrote: Thanks all for the responses. They really solidified my understanding of Rects. Very helpful... -Scott
Re: [pygame] My solid tile detection doesn't work
Yes, playerpos and tilepos are supposed to be the same domain. I realised that the camera coordinates were not taken into consideration. When I did take them into consideration, it only reported the right tile when I moved horizontally. Vertical motion is still all wonky. I relabelled the player coordinates so I could walkthrough my algorithm more clearly. I'm still at a loss as to what I'm doing wrong... On 7/22/06, Brian Fisher <[EMAIL PROTECTED]> wrote: I assume that the problem you have is that the player draws over different tiles than the attached code is saying the player is moving over? If that's the case the code you sent could be perfectly correct, or it could be wrong, it really depends on how the coordinates in these routines are interpreted by other parts of the system, like when you blit... what I'm thinking of is that it's impossible to tell from this code alone whether the player_x and player_y values you pull from player_pos are supposed to be in the same domain as the computed "truex" and "truey" for a tile - meaning are they both supposed to be used in the exact same way & are they supposed to be comparable (i.e. do you blit tiles at truex,truey and players at playerx,playery?) My general tip for doing stuff with coordinates is to always think of different coordinates as being parts of different named coordinate systems or domains, and always name variables with a suffix that makes the coordinate system explicit. Like if coordinates can be blit to the screen, they could be "player_screen_x", if they are supposed to be map grid locations it might be "player_map_grid_x" if it's supposed to be a pixel offset in the map it might be "player_map_pixel_x". It may seem like a lot of typing at first, but it really makes you think about coordinates more, and in the end you are typing lines that read like English sentences, so it's easier for you to know if the line is doing the right thing at a glance, and it's really easy for other people to look at your code. So one thing I notice is that your mapping from a "tilepos" to a "true" position for all your tiles depends on the values of starty and startx and xoff and yoff, while the mapping from "playerpos" to a "tilepos" doesn't use startx and starty or xoff and yoff at all - so if both "true" coordinates and "player" coordinates are in the same domain (like if you pass them directly to pygame to blit) then your mappings aren't symmetric when any of startx, starty, xoff and yoff are non-zero. And if playerpos and tilepos are not supposed to be the same domain (i.e. there is some other mapping of playerpos and "truex, truey" before they get blit), then there may be problems with that other coordinate mapping code in addition to any problems that might exist in this code. On 7/22/06, Adeola Bannis <[EMAIL PROTECTED]> wrote: > In my little RPG engine-like thing that no one tested, *wink wink*, I > tried implementing solid tiles. My algorithm doesn't work, and I don't > know why. > > This is the code I use to place tiles onscreen, only the important > half of the function: > ---code--- > for y in range(starty, endy): > for x in range(startx, endx): > tilepos = y*(self.mapw) + x; #The position in our array of tiles > showx = x - startx; showy = y - starty #Adjust the position of map > by blitting it to the top > truex = (showx*tilesize-xoff); truey = (showy*tilesize-yoff) > #print endy > tilenum = self.tiles[tilepos] > self.put_tile(tilenum,(truex,truey), screen) > ---code--- > > and this is the code I used to look for a solid tile: > > ---code--- > player_x, player_y = player_pos > p_tilex = player_x//tilesize; p_tiley = player_y//tilesize > n_tilex = n_tiley = 0 > > if direction == 'left': > n_tilex = (player_x - speed)// tilesize > if direction == 'right': > n_tilex = (player_x + speed)//tilesize > if direction == 'up': > n_tiley = (player_y - speed)//tilesize > if direction == 'down': > n_tiley = (player_y + speed)//tilesize > > if (n_tiley == p_tiley) and (n_tilex == p_tilex): > return False > > if (p_tilex != n_tilex): # we are moving to a new tile horizontally > n_tilepos = p_tiley*self.mapw + n_tilex # the position in our array of tiles > > if (p_tiley != n_tiley): #we are moving to a new ti
[pygame] My solid tile detection doesn't work
In my little RPG engine-like thing that no one tested, *wink wink*, I tried implementing solid tiles. My algorithm doesn't work, and I don't know why. This is the code I use to place tiles onscreen, only the important half of the function: ---code--- for y in range(starty, endy): for x in range(startx, endx): tilepos = y*(self.mapw) + x; #The position in our array of tiles showx = x - startx; showy = y - starty #Adjust the position of map by blitting it to the top truex = (showx*tilesize-xoff); truey = (showy*tilesize-yoff) #print endy tilenum = self.tiles[tilepos] self.put_tile(tilenum,(truex,truey), screen) ---code--- and this is the code I used to look for a solid tile: ---code--- player_x, player_y = player_pos p_tilex = player_x//tilesize; p_tiley = player_y//tilesize n_tilex = n_tiley = 0 if direction == 'left': n_tilex = (player_x - speed)// tilesize if direction == 'right': n_tilex = (player_x + speed)//tilesize if direction == 'up': n_tiley = (player_y - speed)//tilesize if direction == 'down': n_tiley = (player_y + speed)//tilesize if (n_tiley == p_tiley) and (n_tilex == p_tilex): return False if (p_tilex != n_tilex): # we are moving to a new tile horizontally n_tilepos = p_tiley*self.mapw + n_tilex # the position in our array of tiles if (p_tiley != n_tiley): #we are moving to a new tile vertically n_tilepos = n_tiley*self.mapw + p_tilex # the position in our array of tiles tilenum = self.tiles[n_tilepos]; print tilenum return (tilenum in self.solid) ---code--- I didn't want to put all that in... what I basically wanted to point out was that I was getting the tile number the exact same way I did when I was drawing the map. Yet I usually get a completely different tile to the one the player is walking into. Can anybody help me out here? Adeola
Re: [pygame] My prototype - testers needed
Adam... test it... please that 166 sounds great. On 6/5/06, Adam <[EMAIL PROTECTED]> wrote: On 05/06/06, Adeola Bannis <[EMAIL PROTECTED]> wrote: > Okay.. > > Now, could people test this code for me please? Tell me if it runs > smoothly... no flicker, slowdown etc... and take out the clock in > game.py and tell me how many fps you get, if possible... > > I would especially like if someone runs it on the oldest machine [with > colour monitor :) ] possible. Looking for about 200Mhz > > Thanks If you can wait a week or twoish, I hope :p I should be able to test on a 166.
Re: [pygame] My prototype - testers needed
Okay.. Now, could people test this code for me please? Tell me if it runs smoothly... no flicker, slowdown etc... and take out the clock in game.py and tell me how many fps you get, if possible... I would especially like if someone runs it on the oldest machine [with colour monitor :) ] possible. Looking for about 200Mhz Thanks On 6/4/06, andrew baker <[EMAIL PROTECTED]> wrote: First off, congrats on your progress. Second off, why don't you use udp or tcp libs rather than sockets? Sockets can be an interesting challenge, but if you're just trying to get things done, I'd suggest going with a higher-level lib. On 6/4/06, Adeola Bannis <[EMAIL PROTECTED]> wrote: > I finally have some usable code. I want to start a sourceforge project > but I doubt I have enough original content to warrant it. Anybody have > a place where I can host my code? Awardspace won't let me. *pout* > > Yes I know it is VERY poorly commented... > > I am in the middle of doing the whole unpassable tiles thing, but what > I really need is a little help implementing sockets. I want to be able > to have my program send messages to another program about the player > position. Eventually I want to get a server-client thing going. > > When I tried to implement sockets in my program it didn't work. Does > my socket have to be defined globally? Isn't that messy? > > > -- Andrew Ulysses Baker "failrate"
[pygame] My prototype - need help with sockets
I finally have some usable code. I want to start a sourceforge project but I doubt I have enough original content to warrant it. Anybody have a place where I can host my code? Awardspace won't let me. *pout* Yes I know it is VERY poorly commented... I am in the middle of doing the whole unpassable tiles thing, but what I really need is a little help implementing sockets. I want to be able to have my program send messages to another program about the player position. Eventually I want to get a server-client thing going. When I tried to implement sockets in my program it didn't work. Does my socket have to be defined globally? Isn't that messy? AMBGame0.01.tar.gz Description: GNU Zip compressed data
