I'm trying to fix the missing tacho band and needles in HUD. My change is in revision 1777. It's not working yet.
What I have done is added a function UTILITY:
raw2DRotation() to draw 2d texture with a rotation value. It's similar to UTILITY:
raw2D() with an additional parameter for rotation.
Code:
SCENENODE &rotatenode = parentnode->AddNode();
//rotate this scenenode
QUATERNION q;
q.Rotate(r, 0,1,0);
rotatenode.GetTransform().SetRotation(q);
I've only changed the tacho band drawing code to test this new function. But it seems the rotation has no effect at all. Is my use of scenenode and transformation correct?
Hmm... that looks correct to me. I'll have to take a look at this more later to figure out what's going on. Try rotating on the Z axis instead of the Y.
I've tried both Y and Z axis, same result.
Okay, I fixed this in R1778. Turns out I wasn't bothering to transform 2d scenegraph elements when they're drawn inside the GRAPHICS class. Note that if you want the rotation to be about a specific point (such as the center) you should build the 2d rectangle about 0,0,0 then add the rotation and translation.
Okay, R1779 should work as you'd expect. You can use the Draw2DRotation function like normal now. Be aware, though, that I removed the transform node, and instead just transform the vertices manually when the object is created. This should actually be faster, because the object is only created once (if you draw it every frame), but was kind of just an arbitrary design decision.
In R1780 I changed Draw2DRotation to be just another overload of Draw2D instead, so be aware.
Thanks Joe. I went ahead and fixed the tacho band, red band and all the needles in HUD now (r1781).
Nice thing. thanks!
Yay now i can drive manually! (kind of hard to do so with no visual or sound)(when is sound going to be fixed on PPC anyway?)
99 (one more to 100)
)
kidrock Wrote:Yay now i can drive manually! (kind of hard to do so with no visual or sound)(when is sound going to be fixed on PPC anyway?)
Interesting... you can use the application? PPC? OSX 10.4? What kind of video card do you have? Since the fix to the tacho needles, all my menus are offset in the y direction by half a screen. And the cursor won't move off the bottom edge of the screen. I'm not absolutely current, but by looking at the logs, this issue doesn't seem to be addressed.
Anyways, I was planning on investigating after I finished some build-system stuff, but I am trying to figure out why this behavior hasn't been reported yet.
Quote:all my menus are offset in the y direction by half a screen
If you don't figure it out, can you post a screenshot?
Well... I've got a fix, but I can't say I really "figured it out". It doesn't make much sense to me.
The problem is that on my machine, VERTEX::Set(const VERTEX&) doesn't seem to work reliably. The funny thing is when I tried to inject printfs to see exactly what was happening, the particular display I was investigating would magically correct itself. It doesn't matter what the printf was.
if I change the implementation from
Code:
memcpy(&x, &(other.x), sizeof(float) * 3 );
to a more mundane
Code:
x = other.x;
y = other.y;
z = other.z;
Then the offset problem I was seeing goes away. This also seems to fix problems with the needle rotation, track dispaly ( I was seeing many missing segments ), and crashes that were happening when I run off the road ( it happens a lot
).
The only thing that I can come up with is that many there is some bug in my memcpy implementation or it is configure to run asynchronously or something ( crazy talk, I know ).
Anyways, I was wondering if there is any objection to checking this in. I would conditionally compile it, but I can't think of what to switch on.
Maybe on your platform it wasn't putting x at the beginning of the data. The reason I use memcpy is because it's faster than three assignments, and this function gets called a LOT. Can you try changing it to something like this:
Code:
memcpy(this, &(other), sizeof(VERTEX) );
Does that fix things for you?
I had thought the order of members in the class might have been a cause, but that wouldn't explain the printf statements correcting the problem. In any case, your suggestion also seems to solve the issue.
I had figured the implementation was a performance enhancement and is why I did not check in my fix immediately. Anyways I got to wondering about which approach would actually be faster... surely, function call overhead would negate any performance benefits fancy assembly code in memcpy got you. However, I ran some tests, and over 1 billion iterations the memcpy is 2 seconds faster than the three assignments ( 23 vs 21 ) on my machine.
So... I was wrong. Anyways, I'll leave the code change in my local copy until the repository is updated.
Thanks!