Having an odd time with this, for some reason.
It seems to be returning 0 for any input. Anyone got any ideas why this could be broken for me?
That’s nuts! It’s too small a function to go wrong! Have you debugged into it to see what happens?
I know, I have been ultra boggled by it. I stepped thru, but as you say, it’s so short there’s little to tell. The selected value from the union is just zero, and it is reTurned. Maybe there’s some craziness coming from the fact that it’s using our library too… I should perform some more tests.
Perhaps something has changed the compiler struct alignment, so that the union it uses is completely out-of-whack?
that’s quite possible; the library i’m using does a lot of alignment-related stuff [as it’s specifically designed for console targets]. Not sure how far it goes with that stuff on the PC branch, but it wouldn’t surprise me…
… [moments later]…
although, both the app project and the core library project in my solution have the struct member alignment set to ‘default’ in their properties.
I am lost! Not that it really matters too much; the only reason I noticed was that Colour::withMultipliedAlpha() was always returning a fully transparent colour, though i wouldn’t be surprised if it reared its ugly head somewhere else, seeing as it’s used inside juce where i cannot touch it.
hmm, turns out it only happens when it’s called from my special library thread. Mysterious! I guess I at least know what to look out for now…
BTW, just a stupid thought, but you can “emms” before the call (so the FPU control register isn’t “err’d”).
Also, you should try to set the FPU rounding mode by hand.
Did you try to debug int a = (int)value; and see if that worked ?
Well, casting to int worked (although without rounding). I can’t do anything specific to the call to solve in all cases, as it gets called within juce functions…
It’s only mildly frustrating at the moment, really I shouldn’t need to call many such juce functions from my other thread (plus the library does have it’s own round function I can Safely use).
It makes no sense at all! If it only happens on one thread, then it can’t be a problem with the structure packing or offsets… It sounds like it’s because some kind of weird floating point control flag has been flipped, but all the function does is to add two doubles - how could that fail?? Maybe it requires 80-bit precision to be turned on to avoid an overflow condition?
I know! It’s so crazy, i decided that i’ll only go insane if i worry about it any more 
If your other library has a rounding function that still works, what’s different inside that? I guess it’s not using the same numeric trick.
In fact, it does make sense still.
If the library used MMX code, the FPU registers are in an unknown state (meaning, that fp0 could be holding a NaN)
Usually, after MMX code, you should call asm(“emms”) to “release” the fpu registers.
You should just add a asm(“emms”) on top of your code, and magically, the code might work.