[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: <pygame-users@seul.org>*Subject*: RE: [pygame] How to rotate a rect*From*: "Michael Robin" <vimakefile@yahoo.com>*Date*: Sat, 30 Jun 2001 11:16:19 -0700*Delivery-Date*: Sat, 30 Jun 2001 14:14:20 -0400*Importance*: Normal*In-Reply-To*: <JOECIDMGKPDFPAELHDDMKEAJCEAA.bob@redivi.com>*Reply-To*: pygame-users@seul.org*Sender*: owner-pygame-users@seul.org

>Manhattan distance is actually useful to solve certain types of problems >(i.e, a problem where moving at an angle is not possible).. I wouldn't say >it's inferior, but it's not equivalent to euclidean distance and shouldn't >ever really be used in lieu of it. I've used it too in a genetic algol for an optimization problem a while back. >another thing I've noticed is that >distsquared=(i-j)*(k-l) + (i-j)*(k-l) >is ~4% faster with integers, and ~3% faster with floats on a p3-800 in >win2000.. while playing mp3s in winamp and having wincvs, pythonwin, and >outlook running. Another thing of note, ints were faster than floats by >~16%.. this could be due to the fact that winamp is probably using a bunch >of flops, but then again, I have dual cpus so chances are winamp and python >weren't even on the same cpu. >this might be a bit different with objects in the picture.. I don't how well >python caches/compiles that sort of thing, I haven't been using it long >enough to tell and I definitely haven't looked at python bytecode yet. I have a feeling that int/float and even generalized exp vs x^2 won't make much difference with Python were you're looking things up in dictionaries, (un)packing tuples and blitting all day. Anyway, on the Pentium, we'd expect FP to be at least as fast as integer, seeing the interpreter will have the integer unit busy already, the FP unit could be working in parallel, if instructions were given in an order the scheduler could do something with. (Like that's gonna happen... there'll be hundreds of overhead instructions in the way.) Let's see what happens for me: ------------------------------------------------------------------- def mtest(s,e,inc): i = s while i < e: j = s i+=inc while j < e: t = s*s*s*3.14 t = s*s*s*3.14 t = s*s*s/inc t = s*s*s/inc j+=inc def dtest(s,e,inc): from math import sqrt i = s while i < e: j = s i+=inc while j < e: d = sqrt((i-j)**2 + (j-i)**2) d = sqrt((i-j)**2 + (j-i)**2) d = sqrt((i-j)**2 + (j-i)**2) d = sqrt((i-j)**2 + (j-i)**2) j+=inc def fnoverhead(a,b): return [a[0], b[1]] def dtest2(s,e,inc): from math import sqrt class C: pass c = C() c.a, c.b, c.c, c.d = s, s, e-s, e+s def fnoverhead2(a,b): return ( a[0], b[1] ) i = s while i < e: j = s i+=inc while j < e: t = ( sqrt((c.a-c.b)**2 + (c.c-c.d)**2), sqrt((c.a-c.b)**2 + (c.c-c.d)**2) ) t2 = ( sqrt((c.a-c.b)**2 + (c.c-c.d)**2), sqrt((c.a-c.b)**2 + (c.c-c.d)**2) ) fnoverhead(t, t2) fnoverhead2(t, t2) j+=inc import time as pytime def time(f,msg, s,e,inc): timeStart = pytime.time() f(s,e,inc) timeEnd = pytime.time() - timeStart print 'done (%s): %f' % (msg, timeEnd) if __name__ == '__main__': time(mtest, 'mtest int', 1, 1000,1) time(mtest, 'mtest float', 1.0, 100.0,0.1) time(dtest, 'dtest int', 1, 1000,1) time(dtest, 'dtest float', 1.0, 100,0.1) time(dtest2, 'dtest2 int', 1, 1000,1) time(dtest2, 'dtest2 float', 1.0, 100.0,0.1) --------------------------------------------------------------------- Here's what I get on my Dell laptop (PIII 850): done (mtest int): 4.366000 done (mtest float): 4.386000 done (dtest int): 11.667000 done (dtest float): 14.531000 done (dtest2 int): 22.703000 done (dtest2 float): 25.286000 So FP still seems to be a little slower - but in the basic case, not by much. (Intersting that dest&dtest2 int/float look like a constant overhead, not a percentage...) Although dtest2 tries to do some other work, this is still *very* math intensive and made to accent the math code. (In this case 40,000 distance measures per call.) If you put your draw loop in there, you probably won't see any difference at all :) (Plus you don't have to worry about fixed-point scaling issues, which are a real pain. Of course, you get a different set of problems with floats, but not usually the kind that's bad for games where relative measures a used and extact reprs are not needed.) mike -----Original Message----- From: owner-pygame-users@seul.org [mailto:owner-pygame-users@seul.org]On Behalf Of Michael Robin Sent: Saturday, June 30, 2001 3:02 AM To: pygame-users@seul.org Subject: RE: [pygame] How to rotate a rect This is what I get for not reading your post (and my own) carefully - nothing's worse than an overly-pedantic post that's also wrong... The line I proposed with "*" in place of your "+" is garbage. The Euclidian solution should be: limitsize = object1.size1 + object2.size2 # /2 depends on radius vs. diameter... limitsize *= limitsize distsquared = (object2.x - object1.x)**2 + (object2.y - object1.y)**2 if distsquared <= limitsize: # Boom! (Of course, remove line 2 and add a sqrt to distsquared if you really want to know how many pixels the centers are from each other.) This gives the "real" (spherical) distance, and also takes care of abs(), which I beleive you'd need to add to the Manhatan equation. The Manhattan version (useful in the days when you couldn't mult/div/sqrt very fast, but now inferior) would be: limitsize = object1.size1 + object2.size2 # /2 depends on radius vs. diameter... # optional inflation fudge-factor to average out shrunken corners # (there's probably a real # that can be found by someone smarter than me) # limitsize *= 1.1 distsquared = abs(object2.x - object1.x) + abs(object2.y - object1.y) if distsquared <= limitsize: # Boom! Of course, I'm sure you all know all this basic crap already - but I thought better to correct my own screw-up. (And now I see that given that you named the variable "distsquared" and you squard limitsize, it was probably just a typo in the first place to omit the **2, so Manhattan nor any other bourough of NYC was ever intended... Arg.) m -----Original Message----- From: owner-pygame-users@seul.org [mailto:owner-pygame-users@seul.org]On Behalf Of Michael Robin Sent: Friday, June 29, 2001 9:02 PM To: pygame-users@seul.org Subject: RE: [pygame] How to rotate a rect I think what you described is usually called the Manhattan distance. (Basically because your measuring the "number of blocks" between objects.) You're right that you don't necessarily need a Sqrt at the end as you would for a real Euclidean distance, seeing we just want a relative measure, but I think you want: ... distsquared = (object2.x - object1.x) * (object2.y - object1.y) # times instead of plus ... for your "squared distance". Manhattan distance may work okay too, but the bounding box for collisions will be kind of like a round diamond shape. (It will be smaller at the diagnals.) Adding the "*" will make the collision area circular as you suggest. In all cases above your just picking a point in your box and not really looking at the orientation of the rotated rect. One way to do that would be to write similar fn's to Rect's collision detection methods, but for generalized polygons. mike -----Original Message----- From: owner-pygame-users@seul.org [mailto:owner-pygame-users@seul.org]On Behalf Of Paul Sidorsky Sent: Friday, June 29, 2001 8:43 PM To: pygame-users@seul.org Subject: Re: [pygame] How to rotate a rect Leonardo Santagada wrote: > Making the box is not the problem but how to make fast collision detection? This may not be suitable for your situation but I'll describe it anyhow since I haven't seen it mentioned yet: Give each object a radius or size and then use the distance formula. If the distance between two objects is less than the combined radiuses (or half the combined sizes) of the objects, they collide. To avoid floating point, use the squared distance. Here's pseudo code: limitsize = (object1.size1 + object2.size2) / 2 limitsize *= limitsize distsquared = (object2.x - object1.x) + (object2.y - object1.y) if distsquared <= limitsize: # Boom! This works great for spherical objects and can work for others if you don't need 100% precision. The inaccuracy increases as the sizes get larger. I'm not sure how practical this method is in "real" games since I've only tried it on a small scale, but it might be worth a shot. -- ====================================================================== Paul Sidorsky Calgary, Canada paulsid@home.com http://members.home.net/paulsid/ ____________________________________ pygame mailing list pygame-users@seul.org http://pygame.seul.org _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ____________________________________ pygame mailing list pygame-users@seul.org http://pygame.seul.org

**References**:**RE: [pygame] How to rotate a rect***From:*"\(::\) Bob Ippolito" <bob@redivi.com>

- Prev by Date:
**[pygame] keyboard refresh** - Next by Date:
**[pygame] Typo in docs?** - Prev by thread:
**RE: [pygame] How to rotate a rect** - Next by thread:
**[pygame] Introducing Pyzzle** - Index(es):