3) 16bit in der Praxis
oder:
Das Abenteuer beginnt!
dann wollen wir mal die farbdarstellung und ihre übertragung durch die funktionen im 16bit-mode ausprobieren.
wir nehmen den obenstehenden ersten code für der rot-kanal, und ändern lediglich Zeile 3:
wenn wir dieses beispiel jetzt laufen lassen, bekommen wir folgende ausgabe:
Code: Alles auswählen
0 , 0
1 , 0
...
7 , 0
8 , 8
9 , 8
...
127 , 123
128 , 132
129 , 132
...
254 , 255
255 , 255
die werte um 0 und die werte um 255 verhalten sich wie erwartet. aber was ist mit den werten um 128?
fehlanzeige, wir bekommen hier ganz abstruse ergebnisse, anscheinend verhalten sich die unteren 3 'unwichtigen' bit nicht still.
wir überprüfen dieses ergebniss anhand der anderen farbkanäle.
aus taktischen gründen zunächst blau (den ganzen code nochmal, um veränderungen zu vereinfachen):
Code: Alles auswählen
InitSprite()
InitKeyboard()
OpenScreen(800,600,16,"x")
For n=0 To 255
StartDrawing(ScreenOutput())
Plot(n, 0, RGB(0,0,n))
f = Point(n,0)
a$ = Str(n)+" , "+Str(f)+" , "+Str(f/65536)
Debug a$
StopDrawing()
Next
FlipBuffers()
Repeat:ExamineKeyboard():Until KeyboardPushed(#PB_Key_Escape)
hier ist der vorgang exakt analog, lediglich die mittlere spalte zeigt den 65536fachen wert.
um die 128 herum sehen wir folgendes:
Code: Alles auswählen
...
127 , 8060928 , 123
128 , 8650752 , 132
129 , 8650752 , 132
...
also völlig analog zu rot.
wirklich spannend wird es jetzt bei grün (deshalb dieses beispiel an dritter stelle):
Code: Alles auswählen
InitSprite()
InitKeyboard()
OpenScreen(800,600,16,"x")
For n=0 To 255
StartDrawing(ScreenOutput())
Plot(n, 0, RGB(0,n,0))
f = Point(n,0)
a$ = Str(n)+" , "+Str(f)+" , "+Str(f/256)
Debug a$
StopDrawing()
Next
FlipBuffers()
Repeat:ExamineKeyboard():Until KeyboardPushed(#PB_Key_Escape)
der code ist absolut analog, es wurden lediglich wieder die zeilen 7 und 9 angepasst.
dennoch kommt das ergebniss gänzlich unerwartet:
Code: Alles auswählen
...
3 , 0 , 0
4 , 1024 , 4
...
127 , 32000 , 125
128 , 33280 , 130
...
251 , 64256 , 251
252 , 65280 , 255
...
255 , 65280 , 255
was ist denn hier jetzt passiert?
anscheinend fliesst das sonst insignifikante 3.bit plötzlich in die berechnungen mit ein, da sich der wert nicht alle 8, sondern alle 4 zeilen ändert.
[edit] die ursache hierfür liegt in der 565 codierung, die lebostein unten beschrieben hat.[/edit]
anhand dieser beispiele wird klar, warum der ausgabewert der Point(x,y)-funktion im 16bit-mode anscheinend unvorhersehbar ist.