Java to LSL code conversion problem, bit manipulation??

Hello everyone! I recently decided to convert the method my image-transfer device sends data to its pixels from a java-parsed-and-constructed rotation to a direct integer transfer.

Java represents pixel color (alpha, red, green and blue) using a large int in the form 0xAARRGGBB. In the previous versions, I extracted color information like this in Java:

int alpha = (pixel >> 24) & 0xff;
int red   = (pixel >> 16) & 0xff;
int green = (pixel >>  8) & 0xff;
int blue  = (pixel      ) & 0xff;

These integers had a range of 0 to 255. I then made it construct a quaternion of these values and send it over the xml-rpc connection. Eggy turned me on to the idea of sending the pure int (named "pixel" in the above code) and doing the conversion at the LSL end of the connection, to reduce the overhead of sending seperate values and the rotation syntax characters ('<', ',' etc). The system converted over quite readily. I made it scalable in the previous few updates, so it was pretty much a breeze.

The only problems I'm having are converting this color int into a rotation in LSL. I believe to have successfully duplicated the bit-shift right operator ('>>'), but for some reason its still not working like I expect it to.

Here's the code I'm using:

integer bitShiftRight(integer bitField, integer places) {
    return (integer) (bitField / llPow(2, places));
}

rotation int2AppearenceRot(integer int) {
    integer alpha   = bitShiftRight(int, 24) & 255;
    integer red     = bitShiftRight(int, 16) & 255;
    integer green   = bitShiftRight(int,  8) & 255;
    integer blue    =                    int & 255;
    
    // Scale the integers from a range of 0 to 255 to a range from 0.0 to 1.0
    rotation ret;
    ret.x = (float) red     / 255.0;
    ret.y = (float) green   / 255.0;
    ret.z = (float) blue    / 255.0;
    
    // I used the following code to kludge together protection from 
    // Image anomolies on the Java-end. (sometimes it sent -1 as alpha)
    if (alpha > 0) {
        ret.s = (float) alpha / 255.0;
    } else {
        ret.s = llFabs(alpha);
    }
    
    return ret;
}

setAppearence(integer appearence, integer side) {
    rotation appearence = int2AppearenceRot(appearence);
    
    vector color    = <appearence.x, appearence.y, appearence.z>;
    float alpha     = appearence.s;
    
    llSetPrimitiveParams([PRIM_COLOR, side, color, alpha]);
    llSetTexture(BLANK_TEXTURE, side);
}

Please help
==Chris

EDIT: Grammatical correction.

How is it working and how are you expecting it to work? I see no obvious errors but perhaps if you gave some example of a color passed in and the vector you generated, and what you think you should have generated, it may help.

Edited to add:
It might have to do with the floats in your bitshift function. Try this one:

integer bitShiftRight(integer bitfield, integer places)
{
   if (places == 1) return bitfield / 2;
   else return bitShiftRight(bitfield / 2, places - 1);
}

Ooooh, recursive! Ama, I lurve j00!
Today I taught Chris about the wonders of RLE and we are recoding it. It's about half done, will let you know how it goes later

If you could (if they still existed) look at a lot of my old responses to 'how do you do X' you would see that many of them are recursive. :/

I luvs the recursion.

Chris, the problem is that integers in SL are signed. If the number is negative, then your function will not work correctly =/. What I do is strip off the sign bit before doing a right shift, divide as you are doing, then put back in the bit (if i need it) afterwards.

Xylor

This help any?

integer bitShiftRight(integer bitField, integer places) {
    return ( llAbs( bitField ) / (integer)llPow(2, places));
}

Recursion adds a lot of overhead... The local stack needs to be saved and a new one created, more steps need to be executed, etc. If you can do the same thing directly or with a simple loop, that's MUCH better. Especially in a tiny memory workspace such as LSL!

In Ama's example above this is correct, there would be a decent amount of overhead as you are creating a new call frame for each recursion. I'm adding my two cents in because the above statement is slightly misleading. Only deep recursion introduces any real overhead. If you have a recursive function that never goes more than two levels deep it's the same as calling another function repeatedly. The only difference is it's harder for optimizing compilers to create inline functions with recursion, but I don't think that's happening with the LSL compiler. Also you aren't creating a new call stack every recursion, only a new frame that goes on top of the stack. Still unnecessary a lot of times but nothing like creating an entire new stack would be.

Sorry to nitpick, but I teach entry level programmers and it's important to start out with accurate information.