Re: [pygame] Re: Hexagonal collision detection?
On Sep 15, 7:35 am, Ian Mallett geometr...@gmail.com wrote: As used in my projecthttp://www.pygame.org/project/649/. def pointtest(self,point): #drawpoints is a list containing points defining your polygon #point is the mouse position #if it doesn't work, list them in opposite order. #works for arbitrary convex geometry x = point[0] y = point[1] Lines = [] index = 0 for index in xrange(len(drawpoints)): p0 = drawpoints[index] try: p1 = drawpoints[index+1] except: p1 = drawpoints[0] Lines.append([p0,p1]) for l in Lines: p0 = l[0] p1 = l[1] x0 = p0[0]; y0 = p0[1] x1 = p1[0]; y1 = p1[1] test = (y - y0)*(x1 - x0) - (x - x0)*(y1 - y0) if test 0: return False return True Ian I usually use a list comprehension to generate the Lines variable: Lines = [[drawpoints[idx], drawpoints[idx + 1]] for idx in xrange(-1, len(drawpoints) - 1)] I just love the negative indexing capabilities of python! Actually, the double loop is pointless, since the list is just unpacked again the second time round. The above could be rewritten def pointtest(point, polygon): x, y = point for p0, p1 in zip(polygon, polygon[1:] + polygon[:1]): x0, y0 = p0 x1, y1 = p1 if (y - y0) * (x1 - x0) - (x - x0) * (y1 - y0) 0: return False return True though using indexes might be quicker than constructing the zip, in which case it would be better to use % rather than Ian's try-except. But if you take the odd case out of the loop, as well as speeding it up, you can also get rid of the if it doesn't work, list them in opposite order injunction. Like this: def pointtest2(point, polygon): x, y = point x0, y0 = polygon[-1] x1, y1 = polygon[0] side = cmp((y - y0) * (x1 - x0), (x - x0) * (y1 - y0)) for i in range(len(polygon) - 1): x0, y0 = polygon[i] x1, y1 = polygon[i + 1] if cmp((y - y0) * (x1 - x0), (x - x0) * (y1 - y0)) != side: return False return True Douglas
Re: [pygame] Pathfinding
Yanom Mobis wrote: I need to have an npc take a relatively short route from a to b. First priority isn't the shortest distance, it's getting there without getting stuck My game is in a futuristic setting, so taking the shortest path without exploring too much is reasonable because they would have GPS and the like. Ah, then you have two options, as I see it. a) make the game a little more futuristic and give them bionic armour so they can just walk in a straight line and the obstacles bounce out of the way. (teleport machines would also work). b) read some of the messages and links and code that people have sent you and realise that A* is not inherently tile based, and that A* is not the only solution that has been explained. Douglas
Re: [pygame] Good code for text wrapping?
The cookbook has this entry, but it doesn't work with new lines. http://www.pygame.org/wiki/TextWrapping Anyone have any code like this that supports new lines? Batteries are included: http://docs.python.org/lib/module-textwrap.html does that help? Douglas
Re: [pygame] Good code for text wrapping?
Ah no, sorry. I didn't see the font/width part. d 2008/9/16 Douglas Bagnall [EMAIL PROTECTED]: The cookbook has this entry, but it doesn't work with new lines. http://www.pygame.org/wiki/TextWrapping Anyone have any code like this that supports new lines? Batteries are included: http://docs.python.org/lib/module-textwrap.html does that help? Douglas
Re: is != == (Re: [pygame] Sticky Variables: Terrain Loading)
y = list(x) y = x[:] y = [z for z in x] I think of these, y = list(x) is probably the right way. Actually, x[:] has always been standard, and is faster, at least for short lists: [EMAIL PROTECTED]:~$ python -m timeit -s 'x=range(7)' 'x[:]' 100 loops, best of 3: 0.332 usec per loop [EMAIL PROTECTED]:~$ python -m timeit -s 'x=range(7)' 'list(x)' 100 loops, best of 3: 0.625 usec per loop douglas
Re: [pygame] Sticky Variables: Terrain Loading
Kris Schnee wrote: The problem is, the program decides that it's adding references to the same variable, terrain, rather than doing what I want: adding a string. The result is that every entry in the land ends up being not only identical, but the same entry. Even though I del terrain to make it plain that I want to create a new variable. This is how python works. Objects are reused if they can be, on an adhoc basis. Consider: 2 is 1+1 True 22 is 21+1 True 222 is 221+1 False There is no point deleting the terrain label. The trouble is you're trying to do things the wrong way. Perhaps you should explain why it matters, and we can show you a different way to deal with that. Douglas
Re: [pygame] Sound to String
Alistair Buxton wrote: On windows, you must open binary files as binary: f = open(sound.wav, rb) If you don't do this, windows will truncate the file and give no error, though it will work on linux. Aha! Pay attention, Mike. This is your problem. The attached script worksforme. douglas sound_to_string.py Description: application/python
Re: [pygame] Sound to String
PyMike wrote: I tried that out, and it got close to working. But I get an unrecognized file-type' error Code is below. What did I do wrong? f = open(shoot.wav) s = f.read() snd = repr(s) print snd Sorry, I wasn't clear. You don't need to repr() the string if you are using it directly. You would only do that if you were writing it to a file in the form of a string, like so: f = open(sound.py, w) f.write(snd = + repr(s)) Then sound.py becomes the basis of your decoding script. The string you pass to mixer.Sound should look like lots of these: \x00, not lots of these \\x00. BTW, if you are concerned about the length, as other threads would suggest, you would be better off using base64 encoding, possibly with a bz2 stage. import binascii #or base64 (same functions with different names) f = open(shoot.wav) snd = f.read() b64 = binascii.b2a_base64(snd) # save b64 to file like above, then snd = binascii.a2b_base64(b64) #etc To compress the wav before base64 encoding it, try bz2.compress(). douglas
Re: [pygame] Sound to String
hi Mike This is your main problem: print len(s) 217 Your wave file is broken. In 16 bit mono, 217 bytes leaves room for 94 samples when you take away the headers. That's about 1/500 of a second at 44.1 kHz. Your sound is not actually that short: the file is broken. Then later you wrote: f = open(shoot.wav) s = f.read() f.close() print len(s) print len(repr(s)) print len(eval(repr(s))) b64 = binascii.b2a_base64(snd) You mean binascii.b2a_base64(s). snd is not defined yet. f = open(sound2.py, wr).write(str(repr(b64))) repr() always returns a string -- there's no need for str(). Also, f here will always be None, because it is the result of open().write() not open(). Anyway, at this point sound2.py will contain a python representation of a sound, and nothing else, which incidentally makes it the module's __doc__ string. So then, if you modify sound2.py, adding the following lines: 'RIFFZB\x00\x00WAVEfmt \x10\x00[...]' #this is the existing line import binascii from cStringIO import StringIO from pygame import mixer snd = binascii.a2b_base64(__doc__) f = StringIO(snd) mixer.init() sound = mixer.Sound(f) sound.play() It will play. At least it would if you didn't have a corrupt wav file. I tried that out, and it got close to working. But I get an unrecognized file-type' error It always helps if you say where an exception occurs. Pasting the traceback is good. douglas
[pygame] sphere meets ground
Patrick Mullen wrote: But there IS an upward force, at least as far as my memory of the physics I learned. The whole every action has a reaction business. If the ground were mobile, that gravity force down would cause the earth to move down with that same force. Since the earth can't move, it pushes back with the force of gravity. Yes, though in fact the upward force ends up being much greater than the force of gravity, which is why the ball flies upwards. With a given mass, force is essentially the same as acceleration. The acceleration is known to be -1.8 * velocity in a single tick, but the issue is how it is distributed within that tick. The simplest way is probably to (as Matt does) have the ball pause until the end of the tick before bouncing at full pace. douglas
Re: [pygame] Why does my ball vibrate?
Greg Ewing wrote: Matt Smith wrote: I can't quite get my head around WHY the ball sinks into the ground if I don't set ypos back to 384 but it certainly works. It's probably because you're applying gravity to the ball even when it's touching the ground. So it repeatdly gets accelerated downwards for one time step, then moved back up to ground level. In real life, when the ball is touching the ground, the downward force of gravity is balanced by an upward force from the ground, so the net acceleration is zero. You can model that by only applying gravity if the ball is above ground level. I have a slightly different take on it: assuming an instantaneous bounce, the ball should have travelled up in proportion to the distance it would have sunk below, like so: FLOOR = 384 if ypos = FLOOR and velocity 0: overstep = ypos - FLOOR ypos = FLOOR - overstep * bounce velocity = -velocity * bounce This is unrealistic, of course, since a ball spends a period of time deforming before bouncing back up, but at least it is consistent, while just truncating gives you a different error each time. But, anyway, the reason it sinks is it always goes down further than it can come up, because bounce 1 and gravity points down, so the upward velocity is always less than the downward. For a period towards the end of the journey, the upward velocity will not be enough to lift the ball above the floor before it turns to drop again. Rounding might exacerbate this. douglas
