ARGB-values
BlitzPlus Forums/BlitzPlus Programming/ARGB-values
| ||
| How does one interpret that Argb-value returned by ReadPixelFast, so one can manipulate it (for a darkening effect or color tone change) and write it back with WritePixelFast? And, BTW, is it better to do all the reading in one loop (and store in an array) and all the writing in another (as in a blitzmanual example) or can one just as well write the pixel right after getting it (and changin the argb a bit)? Which one is faster? |
| ||
| A collection of stuff I have which might help. Get your head around this lot! ; ARGB ; Read and Write Pixel use 32-bit ARGB values. ; When read, the Most Significant Byte (the left-most) will always ; be 255 ($FF) if reading from an Image, but can be ; anything if reading from a texture. ; It's normally considered good practice to also write the Alpha Byte to an ImageBuffer. ; In 2D: ; ###### ARGB = $FF000000 Or R Shl 16 Or G Shl 8 or B ; In 3D: ; ###### ARGB = Alpha Shl 24 Or R Shl 16 Or G Shl 8 or B ; for converting colour to RGB values, for WritePixelFast / ReadPixelFast
Function GetRGB(r,g,b)
Return b Or (g Shl 8) Or (r Shl 16)
End Function
Function GetR(RGB)
Return RGB Shr 16 And %11111111
End Function
Function GetG(RGB)
Return RGB Shr 8 And %11111111
End Function
Function GetB(RGB)
Return RGB And %11111111
End Function; PRJ's Colour Mixing ;from a read... pix=ReadPixelFast( x,y ) r=(pix Shr 16) And $ff g=(pix Shr 8) And $ff b=pix And $ff ;to a write (assumes r,g,b are 0..255) pix=(r Shl 16) Or (g Shl 8) Or b WritePixelFast x,y,pix ;Half-bright: pix=(pix Shr 1) And $7f7f7f ;Quarter-bright: pix=(pix Shr 2) And $3f3f3f ;Blend 2 pixels: pix=( (pix1 Shr 1) And $7f7f7f ) + ( (pix2 Shr 1) And $7f7f7f ) ;So, a fast half-bright loop might be: WritePixelFast x,y,(ReadPixelFast( x,y ) Shr 1) And $7f7f7f |
| ||
| Could you do that again without hex-values and a "GetA" function for the alpha (which is transparancy,right?)? |
| ||
| Function GetAlpha(rgb) return rgb shr 24 end function but to be honest - I am not shure if readpixelfast will return correct Alpha-Values (?!?) At least in 2D it delivers Random Values afaik. BTW. yes, alpha is Transpraency, but only with Textures, and even then only when the textures are using the alpha Mode (defined in the flags of LoadTexture or CreateTexture) And the Hex Values: It's really simpler to handle them as Hex. An RGB Value of the color white is: 255 255 255 or FF FF FF So $FFFFFF is white and $000000 is black. if you shift the bits of a number to the right side then this is the same as if you divide it by 2 result = number shr 1 is equal result = number / 2 but its faster To make a RGB-Color halfbright we shift it right one digit, then we have to delete the new most significant Bits of each, R,G and B, because these Bits were the lowest significant Bits of Alpha, R and G before: result = number and $7F7F7F Note that $7F is 127 is %01111111 $80 is 128 is %10000000 $FF is 255 is %11111111 $7F + $80 = $FF |
| ||
| And writing alpha values (or attempting to) doesnt appear to have any effect whatsoever. I do have a question for the boffs though. Having fiddled around with a fully translucent heads-up-display I noticed there were 2 different values which ultimately contained the same red green and blue values. Why was this a problem? Simply put when I wrote these to a texture it LOST all of its transparency as it was originally loaded as a MASKED texture. I used the ol' Red, Green, Blue functions and they told me the same thing - it was indeed totally black. Any ideas on how this happened, why it happened and most importantly how to get around it? |
| ||
| The texture forgets the alpha information, if you modify it, sad and true. You can try if this happens as well when you use the Texture Flag 256. Once there was a work around for this Problem, I guess we used to copyrect a backup of the texture to the used one to reenable the Alpha. In the worst case you still could re-Mask the Texture manually, using Writepixelfast on the alphabyte. You could also think about to use a Blendmode like Multiply or Addition instead of AlphaMode. |
| ||
| So $FFFFFF is white and $000000 is black. Wrong, $00000000 is not black, $ff000000 is black, 0 as an ARGB value represents invisible. In Images in Blitz2D, Images in Blitz3D and with Textures in Blitz3D without alpha flag the alpha bits will ALWAYS be set to 1 by the readpixel operator to represent the color is solid without transparency. |
| ||
| So, I assume that Blitz loads in masked textures and internally applies an alpha of zero to the black areas. If so, this would explain why the details are lost. Thanks guys. |
| ||
| Skidracer - I was talking about RGB in general, not about ARGB. |
| ||
| Is there a fast way to do 75% bright? |
| ||
| 75% is 50% + 25% hence the following is possible: a=$ff000000+((a Shr 2) And $3f3f3f)+((a Shr 1) And $7f7f7f) |
| ||
| 75% = 100% - 25%, so you could use a = a - ( (a Shr 2) And $3f3f3f ) |
| ||
| And 'a' is the full (a)rgb-value?? For use in 2D? not setting the alpha byte for use in 3D? What about other 'even/fast' steps that are flexible enough to make a brightening shadow like the one under windows menus? But without involving decimal? Is it possible to create a decent shadow this way? I have noticed that already half-bright is quite dark, so 75% would be the innermost of the shadow.. |
| ||
| "75% = 100% - 25%, so you could use" I'm not sure if I'd trust that myself. What if A is a small value? Might that not cause the values to wrap below 0? |
| ||
| Btw, the reason people use Hex to represent RGB values is cause it makes it easy to write the whole value out in a way that is easily modified. 167345267 is not easy to seperate the R G and B values from, as no two digits represent only R, G, or B. In Hex, $0000FF is blue 255, $00FF00 is greeen 255, and $FF0000 is red 255. They each are represented by two numbers that only represent that color component. I use a calculater capable fo converting decimal to hex when I need a hex value. I think windows power toys has a calculator that can do hex. I'm sure someone could write a small program to convert the values too. |
| ||
| windows calculator(the one wich comes with all windows) has built-in scientific/standard mode, you can use hex, binary, etc. and display numbers in byte form in scientific mode. this is what I use because real scientific calculators are expensive. |
| ||
| Is it always possible to a darkening effect by calculating a fraction of the whole rgb or does it just work with things like /2 /4..? Does one need to calc the r,g,b:s individually if you want to do .8,.9 etc?? If I for the speed, should make the first line of shadow (the darkest one) be 0.75, the next 0.80, the next 0.9 can it be done without decimal/float? |
   |