i'm reading from a bmap that is not displayed on screen, therefore the mouse co-ordinates have to be converted to co-ordinates on the bmap. the bmap i am reading from is 744x600 pixels, the mouse position x (lets say the video_mode is 8 and the screen size therefore 1024x768) is between 0 and 1024 and the mouse position y is between 0 and 768. Dividing bmap_width(my_bmap) by screen_size.x gives me the ratio i need to convert the mouse pos_x to the equivalent x co-ordinate on the bmap. lets say the mouse is halfway across the screen - mouse_pos.x = 512.

x_coord = integer(mouse_pos.x*(bmap_width(my_bmap)/screen_size.x));
x_coord = integer(512*(744/1024));
x_coord = integer(512*0.727);
x_coord = 372;

mouse_pos.x of 512 = bitmap_pos.x of 372. Even when this formula generates a number outside the bounds of the bitmap i am still boundary checking and force an early return in this instance. (if(x_coord>bmap_width(my_bmap)||x_coord<0) { return(-1); }). The same is for y_coord.

I know that x_coord and y_coord are giving me the numbers im expecting. I know that bmap_lock is sucessful - it returns 8888. I know that the pixel for bmap is returning the pixel read from the bmap....well, i know it is returing *A* value...perhaps the value returned by pixel_for_bmap is the problem? or perhaps the format returned by bmap_lock is the problem?

I mentioned before that the bmap was made in photoshop and saved as a 24 bit tga file with no alpha channel - a return code of 8888 means it is reading the bmap as a 32 bit tga file with an alpha channel. I recall reading that the bmap_lock "upconverts" a bmap to the next compatible mode if its native mode isnt compatible or something like that.

I notice you save the return value of bmap_lock to format and pass format to the pixel_to_vec function instead of passing 8888. I will try that and see if that solves the problem