Fixing tacho band and needles in HUD

[joevenzon]

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.

I know, it seems weird! I think it's because the compiler ends up inlining the memcpy and just spits out assembly for a block memory copy instead of assembly for 3 memory copies for the assignments... but who knows. I profiled VDrift quite a bit with the new "scenegraph branch" code (which is now merged in the trunk); that's where this came from.

[kidrock]

I didnt have any problems at all with the main menu or driving. I also updated the data at the same time... could that be it? :?: :?: :?: :?:

[bugsyv]

Like I said... it's a truly bizarre situation.
I don't think the data in question has anything to do with it.

[thelusiv]

kidrock, bugsyv is on a PPC machine, so things are a little different for him (he eats the egg from the big end first - weird I know! ).

The memcpy statement in question should be separated out by a ifdef with the version that works for bugsyv only compiled in for PPC versions, and the regular version compiled in otherwise.

[joevenzon]

The corrected "regular" version works for bugsy (memcpy but with this as the first argument).