try this:
halfbright = (rgb and $FEFEFE) shr 1
you can also (50:50) mix 2 pixles that way:
mix = ((rgb1 and $FEFEFE) shr 1) + ((rgb2 and $FEFEFE) shr 1)
I just tested the speed difference, out of curiosity. Unfortunately the most speed loss happens with the readpixelfast and the writepixelfast commands. THe reason why is their VRam location (machine dependent?) and the bus bottle neck, especially with continous read/write access that prevents good instruction caching on the machine level.
The RGB halfbright code is 40:300 faster with the SHR variant, but when Writepixelfast and Readpixelfast are involved, this speed gain becomes rather irrelevant. well, in the test it was still about 20% faster.
Here's the test code:
Graphics 640,480,32,2
SetBuffer BackBuffer()
img=CreateImage(128,128)
SetBuffer ImageBuffer(img)
LockBuffer
tt=MilliSecs()
For i=0 To 1000000
; rgb=ReadPixelFast(0,0)
rgb2=(rgb And $FEFEFE) Shr 1
; WritePixelFast 0,1, rgb2
Next
tt2=MilliSecs()
UnlockBuffer
SetBuffer BackBuffer()
Text 0,0, "SHR: "+(tt2-tt)
;------------
SetBuffer ImageBuffer(img)
LockBuffer
tt=MilliSecs()
For i=0 To 1000000
; rgb=ReadPixelFast(0,0) And $FFFFFF
r=(rgb Shl 16)*.5
g=((rgb Shl 8) And $FF)*.5
b=(rgb And $FF)*.5
rgb2=(r Shl 16)Or(g Shl 8)Or b
; WritePixelFast 0,1, rgb2
Next
tt2=MilliSecs()
UnlockBuffer
SetBuffer BackBuffer()
Text 0,16, "Multiplying: "+(tt2-tt)
WaitKey()
Simply unREM the 4 Pixel Commands to compare the speed. It may be that using a Vram resident Texture may be faster (Texture flag 256), and maybe the process can be optimized, if you first read the image to a bank and then write it back, because switching from read to write for every pixel does slow things down on the cpu-cache level, as I already mentioned.