Returning vector2D from C

#1 This should work fine. Returns 1 if the Vectors are equal, else 0.

function CompareVectors(%v1,%v2)
{
  return ( ( getWord(%v1,0) == getWord(%v2,0) ) &&
               ( getWord(%v1,1) == getWord(%v2,1) ) );
}

But it won't be very fast.

#2 I think if you pass in like:

CompareVectors("1.0000 1.0000", "1 1");

you will get 0 (since the string "1.0000" !$= "1")

(Also, in your function, I think you have to use the string comparitor $= instead of the numerical comparitor ==)

I was able to fix it on the C++ side by passing back ints instead of floats, like:

....
//format buffer   
U32 x = v.mX;
U32 y = v.mY;
dSprintf(pBuffer, 256, "%i %i", x, y);
...

so now, the C++ call returns "1 1" instead of "1.0000 1.0000". This is ok in this instance, since I'm passing back tile indexes which should be ints anyway.

#3 If you compare each element of the vector singly, you can use the numerical compare, since the scripting engine will auto convert for you. The reason you can't use it on "1.0 1.0", is because that can't be parsed as a valid number. If you use the getWord method to separate the vector into it's X and Y components, then you can numerically compare, and 1.0 will be equal to 1...

#4 Hmm, my bad. I thought I tried that and it didn't work, but I just tried it again, and it does. Thanks

#5 I'll add a call "t2dVectorCompare()" to the SDK.

In the meantime, you can use "t2dVectorDistance" to achieve the same comparison but alot quicker. if you create a function as below (which should do the same thing) then you can simply remove the function when you update the SDK.

function t2dVectorCompare( %v1, %v2 )
{
	return t2dVectorDistance( %v1, %v2 ) > 0.0001;
}

Hope this helps,

- Melv.

#6 ... or just add this to "t2dVector.cc"...

//-----------------------------------------------------------------------------
// Equality of two 2D Points.
//-----------------------------------------------------------------------------
ConsoleFunction( t2dVectorCompare, bool, 3, 4, "(t2dVector p1$, t2dVector p2$, [epsilon]) - Compares points p1 and p2 with optional difference (epsilon).")
{
    // Check Parameters.
    if ( t2dSceneObject::getStringElementCount(argv[1]) < 2 || t2dSceneObject::getStringElementCount(argv[2]) < 2 )
    {
        Con::warnf("t2dVectorCompare() - Invalid number of parameters!");
        return NULL;
    }

    // Input Vectors.
    t2dVector p1(0,0), p2(0,0);
    // Scan-in vectors.
    dSscanf(argv[1],"%f %f", &p1.mX, &p1.mY);
    dSscanf(argv[2],"%f %f", &p2.mX, &p2.mY);
    // Do Vector Operation.
    const F32 delta = (p2 - p1).len();
    // Calculate Epsilon.
    const F32 epsilon = (argc >= 4) ? dAtof(argv[3]) : T2D_CONST_EPSILON;
    // Return  epsilon delta.
    return mIsEqualRange( delta, 0.0f, epsilon );
}

- Melv.

#7 Heh, you and your fancy t2dSceneObject... us poor peons have to deal with the old-fashioned fxSceneObject2D's :)

Anyway, I retrofitted it, but still get errors:
1>c:\torque 2d\sdk\engine\t2d\fxvector2d.cc(290) : error C2065: 'T2D_CONST_EPSILON' : undeclared identifier
1>c:\torque 2d\sdk\engine\t2d\fxvector2d.cc(292) : error C3861: 'mIsEqualRange': identifier not found

The data member mIsEqualRange doesn't seem to be in fxVector2D.h, and I dont know what the constant is about....

If it's too much a pain to update all this, I can just wait for the real update :)

#8 Phil,

Yeah sorry, I'm really only posting what I put into the codebase which is obviously the alpha release (which you can get from your downloads) as it's far superior than the v1.0.2 release and it's not really useful for me to post relative to that codebase anyway.

Are you using v1.0.2 because you're working on a project with it?

You've got the alpha right? :)

- Melv.

#9 I do have access to the alpha, but I was under the impression that it might not be so stable. I was pretty content with 1.0.2, so I wasn't in a rush I guess... But I should get the alpha you're saying :)

#10 Absolutely Phil. :)

The call to port any of your code is ultimately yours of course but the downside to not doing so would be that you miss out on all the improvements and fixes. In terms of stability, I guess this depends on what stability means to you; it's always been stable in terms of infrequent 'crashing' but there's been alot of bugs that've now, hopefully, been fixed.

It might be worth at least downloading it and at least browsing the reference/image-map doco.

I guess another way to look at it would be the type of game you're developing; some will be safer to move over to the alpha than others maybe. So far, I've not had any show-stopper reports of crashing/not-working etc. Downside is that alpha#1 is officially only Windows but some smart folks have got the Mac/Linux running I believe.

You can also be sure that I'll smack any problems you may encounter quickly. :)

- Melv.

#11 I got the alpha and started playing with it tonight. I got one project converted (small :)... it took me a bit to figure out the new physics modes, but I got them going alright now.

I love some of the new methods, like setForwardMovementOnly() (or something like that). THe moveTo and RotateTo look promising also. Nice, nice stuff!

I sent you an email regarding an old bug, where a tileLayer mounted to a sprite would grow by one row and one column. I'll resend the sample file if it got lost, I'll convert it to 1_1 first though. Remember it?

Anyway, thanks again, this is good stuff!

#12 Phil,

Got your email yes. Too many emails today!!!! ;)

I do remember that one but I can't remember what the resolution, if any, was.

Either way, I've added this issue (#867) for me to investigate. All I can recall is that the number of tiles to render differed slightly due to float-precision issues but that this problem was irrelevant as there is now hardware clipping on non-rotated tile-layers only.

A simple working example in 1.1 alpha #1 would be very helpful, thanks.

- Melv.