Never mind, I found it. The result is very small, but not quite 0 due to Python's standard floating point numbers not having the precision to go further. I'll just check for this sort of thing and assume 0 if the result is too low.
On 11/2/11, Alex Hall <mehg...@gmail.com> wrote: > I am wanting arbitrary positioning. The grid squares are for > positioning objects on the map and reporting the user's location to > give them an idea of where they are. > I think I can do this in Python, using sound_lib > (http://hg.qwitter-client.net), so I am back on familiar ground as far > as the language goes. However, I tried using the equations you guys > gave me and odd things happened. First, here is my move() function, > stored in the Object class, where Object is something on a map. > self.stepLength is how long each step is and is currently at 1 > (meter). I use x and z instead of x and y because of how the bass > audio library, on which sound_lib is based, works; y is height, not > forward/backward movement as one would expect. > > def move(self, direction=None, steps=1): > #move the specified number of steps in the specified direction (in > radians) > if direction is None: direction=self.angle #currently set to 0 degrees) > print "Moving "+str(steps)+" steps, facing "+str(direction)+" > degrees. Starting at "+str((self.x, self.z)) > for i in range(steps): > self.x+=self.stepLength*math.sin(math.radians(direction)) > self.z+=self.stepLength*math.cos(math.radians(direction)) > print "Now at "+str((self.x, self.z)) > > Starting at (0, 0), you would expect the new position to be (0, 2) > since two steps were taken straight ahead, and this does indeed > happen. However, when you turn to 90 degrees, you would expect 2 steps > to get you to (2, 0), but instead you get this: > > Moving 2 steps, facing 90 degrees. Starting at (0.0, 0.0) > Now at (2.0, 1.2246468525851679e-16) > > What happened to make the second coordinate so far off? TIA. > > > > On 10/30/11, DR0ID <dr...@bluewin.ch> wrote: >> On 30.10.2011 04:29, Alex Hall wrote: >>> It is real-time. I don't want it as accurate as movement acceleration >>> for stepping, at least not yet, but I am not sure how I would manage a >>> map without a grid. How, for instance, will the computer know where >>> the player is in relation to objects? If the player fires a weapon, >>> how can the computer calculate if the projectile will hit a target? >>> Currently I am planning to manage targeting by getting the slope of >>> the line and the point of the player, then extending the line to the >>> weapon's range and seeing if it intersects a point on which there is >>> an object. >>> For my game creation I am using the Blastbay Game Toolkit, which is a >>> subset of C++ but written specifically for use with audio games and >>> run sort of as a scripting language through an interpreter. For >>> instance, there is a sound class, a tts class for speaking text, >>> sound_pool (sort of like a "world" that manages sound positioning >>> relative to the player), a timer, and so on. Sound_pool, which I >>> subclass for my Map class, relies on a grid to properly position >>> sounds, which is the other reason I am using grid-based positioning. I >>> can't imagine how it would work with no grid. Is there a way? >>> >>> On 10/29/11, René Dudfield<ren...@gmail.com> wrote: >>>> Hi, >>>> >>>> a few notes, and questions... >>>> >>>> Is your game turn based? Or is it real time? >>>> >>>> If you don't have realistic 3d sound, then using a grid is probably >>>> easier >>>> for players. >>>> >>>> Instead of frame rate, think about it like the update rate of your main >>>> loop. >>>> >>>> Before the player takes a step they are standing. When standing, speed >>>> is >>>> zero. When stepping, the person gets some acceleration and moves. >>>> Then >>>> they get some deceleration and stop. >>>> >>>> It's more complicated than that, but the more physically accurate you >>>> want >>>> it, then more complex your code will be. If you're more interested in >>>> making the game, than a physics engine, you might want to consider >>>> looking >>>> at one of the physics engines available. >>>> >>>> Keeping the game movement to grids might make it easier to play as well >>>> as >>>> program. >>>> >>>> >>>> cheers, >>>> >>> >> >> Hi Alex >> >> Do you know about coordinates and vectors (vector math)? This is how it >> is done in most games. If you make your game grid based, I have not >> understand if you want just go from one grid cell to another or if you >> want to allow arbitrary positions in between cells. According to your >> example it looks to me as if you want to go from one cell to another, so >> going diagonal would just move you to the next cell diagonally. Of >> course this means you travel faster because you cover a longer distance >> (diagonal is sqrt(2) longer) than moving orthogonal. You could restrict >> movement to just up/down and left/right and not allow diagonal movement >> at all. If you want to allow diagonal movement then you need to decide >> if you want to move from cell to cell (where diagonal movement is faster >> then) or if you want to allow arbitrary positions. >> >> I hope it helps. >> >> ~DR0ID >> > > > -- > Have a great day, > Alex (msg sent from GMail website) > mehg...@gmail.com; http://www.facebook.com/mehgcap > -- Have a great day, Alex (msg sent from GMail website) mehg...@gmail.com; http://www.facebook.com/mehgcap
