Distance3DSquared, LengthSquared
Moderator: GZDoom Developers
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: Distance3DSquared, LengthSquared
Summoning that first actor, which calls dot 1M times per tic, takes me down to forty-something ~57 FPS.
Summoning that second actor, which calls length 1M times per tic, takes me down to <2 FPS (around 560 580-something ms per frame).
EDIT: Just tried it again.
Summoning that second actor, which calls length 1M times per tic, takes me down to <2 FPS (around 560 580-something ms per frame).
EDIT: Just tried it again.
- Major Cooke
- Posts: 8170
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: Distance3DSquared, LengthSquared
To clarify: A Length() vs LengthSquared() test is not what he's looking for. That's an apple to orange case because Length has square root and obviously it'll be a lot slower.
What he wants to know (correct me if I'm wrong) is if doing "x dot x" is faster than doing a "LengthSquared" and/or the "Distance3DSquared". But we can't really test that out since we don't have functions for it on the native side.
What he wants to know (correct me if I'm wrong) is if doing "x dot x" is faster than doing a "LengthSquared" and/or the "Distance3DSquared". But we can't really test that out since we don't have functions for it on the native side.
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: Distance3DSquared, LengthSquared
Got it. (your point, anyway, not the code required to test that...)
A Distance3DSquared would be helpful for this anyway since AFAIK the portable-sensitive relative position is not available to ZScript (and I'm assuming from looking at the Distance3D code that adding that would be less complicated than making that relative position available).
A Distance3DSquared would be helpful for this anyway since AFAIK the portable-sensitive relative position is not available to ZScript (and I'm assuming from looking at the Distance3D code that adding that would be less complicated than making that relative position available).
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: Distance3DSquared, LengthSquared
It just occurred to me:
Any mod that tried to calculate damage based on e=mv^2 would now either:
1. take a bunch of extra steps in the virtual machine adding the squares of vel.x/y/z; or
2. take an extra step calculating a square root before squaring that square root in the virtual machine.
Would be nice to avoid that with a native lengthsquared.
Any mod that tried to calculate damage based on e=mv^2 would now either:
1. take a bunch of extra steps in the virtual machine adding the squares of vel.x/y/z; or
2. take an extra step calculating a square root before squaring that square root in the virtual machine.
Would be nice to avoid that with a native lengthsquared.
- Major Cooke
- Posts: 8170
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: Distance3DSquared, LengthSquared
Agreed. Currently D4D runs this calculation every tic on the player in order to check for certain features like ledge grabbing (or more like ledge warping now...)
Re: Distance3DSquared, LengthSquared
Any mod trying to do that would be wrong, since e = 1/2(mv^2) .Vaecrius wrote: Any mod that tried to calculate damage based on e=mv^2 would now either:
But regardless, I agree on the idea of Distance3D/LengthSquared. Sometimes the sqrt just wastes time, and many maths libraries/game engines implement this for that reason (for example, glm's length2(), and Unity's Vector3/2.sqrMagnitude()).
- Major Cooke
- Posts: 8170
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: Distance3DSquared, LengthSquared
So would this still be better having a LengthSquared or does the dot multiplier work?
If so I'll try doing it.
Also, Matt:
If so I'll try doing it.
Also, Matt:
Graf Zahl wrote:How does dot compare to length?
Re: Distance3DSquared, LengthSquared
Extension of vector types is not so trivial because there are no wrapper structures for them on scripting side at the moment.
For this reason string type is easy to extend but vectors are not.
For this reason string type is easy to extend but vectors are not.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Distance3DSquared, LengthSquared
A bigger problem is that vectors are not objects. In the VM they occupy 3 consecutive float registers when not part of a class or struct. I think the only viable option would be to create a Vector struct and add static functions to them
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: Distance3DSquared, LengthSquared
I have no idea what is to be tested to answer that question.Major Cooke wrote:Also, Matt:
Graf Zahl wrote:How does dot compare to length?
Is this supposed to be a comparison of scripts, or a comparison of changes to native functions?
Re: Distance3DSquared, LengthSquared
It may be easier and better rewrite root founding functions!?
Since there are A LOT of ways to found root, any degree, not just square root, using pen and papper, it can be found such, which provide highest performance in gzdoom.
Or solve it in rude way, just create table with all root of whole numbers from 1 to, say, 10000, and return it from table, as with sine/cosine functions. All intermediate numbers just round off to nearst whole. Yes, its hacky hack of the hackerman from hackyntown, but we here kill demons in darkness of hell, not build LHC or launch rockets to star with three cucumbers aboard(this was KSP if some one dont understand), so error in 0.00000000000000000000000000000001 will, and should, not be critical.
And root of higher numbers found like now, using some formula.
Or rewrite positioning system to use imagine numbers, which in square gives real number. But this silly.
Since there are A LOT of ways to found root, any degree, not just square root, using pen and papper, it can be found such, which provide highest performance in gzdoom.
Or solve it in rude way, just create table with all root of whole numbers from 1 to, say, 10000, and return it from table, as with sine/cosine functions. All intermediate numbers just round off to nearst whole. Yes, its hacky hack of the hackerman from hackyntown, but we here kill demons in darkness of hell, not build LHC or launch rockets to star with three cucumbers aboard(this was KSP if some one dont understand), so error in 0.00000000000000000000000000000001 will, and should, not be critical.
And root of higher numbers found like now, using some formula.
Or rewrite positioning system to use imagine numbers, which in square gives real number. But this silly.
- Major Cooke
- Posts: 8170
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: Distance3DSquared, LengthSquared
Square root is already fully optimized. Graf took care of that a long time ago.
The original suggestions still stand, and I fully agree with them.
The original suggestions still stand, and I fully agree with them.
Re: Distance3DSquared, LengthSquared
Then google translate dont translate OP post correctly to me, because I dont understand why someone need squared distance between two actors, if current root calculating function optimizated to limit.
Re: Distance3DSquared, LengthSquared
Try Bing translate for a second opinion.
- Chris
- Posts: 2940
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: Distance3DSquared, LengthSquared
Just because it's optimized doesn't mean it's free. The best way to optimize a function is to avoid calling it, so if it's possible to check something like x*x + y*y > l*l instead of sqrt(x*x + y*y) > l, the former will almost always be faster regardless of how optimized sqrt is (unless it's somehow cheaper than a multiply, and you aren't checking against a constant).Apeirogon wrote:Then google translate dont translate OP post correctly to me, because I dont understand why someone need squared distance between two actors, if current root calculating function optimizated to limit.