i hate math.
Blitz3D Forums/Blitz3D Programming/i hate math.
| ||
Graphics 640,480,0,2 r=50 g=201 b=156 rgb = r + (g*256) + (b*256*256) Text 1,1,"RGB ="+rgb nb= (rgb / (256*256)) ng= ((rgb - nb * 256 * 256) / 256) nr= rgb - ((rgb - nb * 256 * 256) / 256) Text 1,20,"r "+nr Text 1,40,"g "+ng Text 1,60,"b "+nb Flip WaitKey What am I doing wrong with that nr line, cant seem to figure out , oh and i hate math I suck at it clearly lol. |
| ||
| What am I doing wrong ...to be blunt? Using +, -, * and / for filtering subvalues. This is much, much easier if you just use And, Or, Shl and Shr, as the gods intended. If you don't yet understand these operators fully, see this thread for explanation: http://www.blitzbasic.com/Community/posts.php?topic=95654 (TL;DR: "And" is a filter operator that extracts bit sequences, such as one of the colours; "Or" is a combination operator that glues them together; "Shl" and "Shr" do as the names suggest, moving bits left and right so they don't collide. "Math" is not required for this.) |
| ||
| I dont, and thanks for the link. |
| ||
| nb = (rgb Shr 16) Mod 256 ng = (rgb Shr 8) Mod 256 nr = rgb Mod 256 thanks m8, that link didnt help but the docs on Shl and Shr did. wouldnt have noticed them otherwise. TA! |
| ||
| Bit shifting is your friend. |
| ||
| I'm wondering where else I could use it now lol. |
| ||
| I had problems using Int sized numbers. I was trying to use all 32 bits to compress a dictionary, and, in a way, encrypt it. But the 2^31st bit used as a positive/negative sign bit really screwed my code up. shl and shr helped but didn't solve my problem until I stopped using Int. |
| ||
| But the 2^31st bit used as a positive/negative sign bit really screwed my code up. shl and shr helped but didn't solve my problem I don't really understand the nature of your problem (which I guess you didn't explain anyway), but if you use Sar instead of Shr it will fill the "blank" bits on the left with copies of the sign bit, which will make it work as you might expect if you were using it as a fast-divide operator (e.g. -8 Shr 1 = 2147483644, but -8 Sar 1 = -4). For most binary operations (e.g. colour values) the values can be considered unsigned anyway, though. In these cases, Shr is much more useful. Last edited 2011 |
| ||
| Just as an additional tip, I noticed in your example, you used Mod 256 at the end. Whilst this should suffice for the actual situation, I would recommend, when considering bit flags to use binary operators to ensure restrictions keep the values are within boundaries: i.e: An example: n=-8 n Mod 256 = -8 n And 255 = 248 The difference may not be significant in many cases, since -8 and 248 are equivalent as Bytes, but if you are performing other aroithmetic on values, the sign may be critical. Also: Whilst the particular RGB components may be suitable for reading certain file data, (in fact, I believe Windows uses this 32-Bit format for pixels), but, it might help to be aware that by default, Blitz' own RGB(a) values for WritePixelFast and ReadPixelFast are comprised of bytes in the opposite order to the above. I always get confused personally with wich is which, but essentially, one way around is "BigEndian" the other is "LittleEndian" which refers to whether the Least Signifficant Byte (i.e 1-255 ) or Most Significant Byte (16777217...)is to the LEFT To simplify: If you wish to ue WritePixelFast or ReadPixelFast, you should use the following to obtain the Colour value from components: (The a = Alpha channel) |
   |