I wondered about that as well Jorge. Valve's way is effective, but potentially inefficient.
One thing that really bothers me about it is the whole bias thing. It makes me wonder how much it could influence a distribution of points. Also, the bias will be applied in a cartesian coordinate space, not polar coordinate space - which would then lead to unequal distributions of points given the while loop filtering. BTW - feel free to use/post/modify this code. I was tempted to put it on the Wiki - but if someone beats me to it that's ok by me :^) Tim Quoting Jorge Rodriguez <[EMAIL PROTECTED]>: > Tim Holt wrote: > > >I coded up a new version of shot_manipulator.h this morning which some > people > >might be intersted in using. What it does is replace the calculation method > >for random shot point generation with a biased calculation that > statistically > >puts more bullets in the middle of the circle than on the edges. It's > probably > >closer to what a real gun does in terms of bullet spread, plus gives players > >more accuracy while at the same time allowing for "off" bullets at times. > >"Nerfing" a gun by just increasing the shot spread using a pure random shot > >pattern is too... shall we say random in the eyes of some :^) > > > >The calculation is done by generating a random polar coordinate and > converting > >it to X, Y - which introduces an interesting bias in the shots. Links to > two > >articles that describe why at the end of email. Check out > >http://mathworld.wolfram.com/images/eps-gif/CircularDistribution_1000.gif > for a > >picture that's representative of what it can do. The pattern on left is > like > >what this code does, the pattern on right what Valve's default code does. > > > >The source code is available at > >http://www.orst.edu/~holtt/shot_manipulator.h > > > >You'll see that it has two versions of ApplySpread - one named > ApplySpreadBIAS > >and the other ApplySpreadVALVE. ApplySpreadBIAS returns the biased shot > >pattern and ApplySpreadVALVE is the default purely random distribution one. > >ApplySpread is also defined, and just in turn calls either ApplySpreadBIAS > or > >ApplySpreadVALVE. > > > >Check out > >http://home.wlu.edu/~mcraea/GeometricProbabilityFolder/ApplicationsConvexSets/Problem16/Problem16.html > >for an article describing methods of calculating random points in/on a > circle > >which goes over how the bias can be introduced. Also see > >http://mathworld.wolfram.com/DiskPointPicking.html as well. > > > >_______________________________________________ > >To unsubscribe, edit your list preferences, or view the list archives, > please visit: > >http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > What about a version that replaces Valve's version with a x = sqrt(r) * > cos(t); y = sqrt(r) * sin(t); etc version? Valve's code has > approximately 1/4 chance of falling outside the circle, and if this > happens, Valve code loops until it falls inside. Doing a sqrt and a cos > may be slower then Valve's way if the the 3/4 chance occurs, but this > could theoretically take an infinite amount of time if the player is > unlucky enough to have all his shots fall within the 1/4 chance. I would > prefer the sqrt/cos way. > > -- > Jorge "Vino" Rodriguez > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
