X-Code Projekt | Mathe Syntax

[Pii]

Weder noch. Relevant ist der Maximalwert des verwendeten Wertebereiches. Wenn der 255 beträgt dann 255, wenn der 256 dann 256, wenn der 100 beträgt dann 100, u.s.w. - Bei Farben beträgt der üblicherweise 255. Insofern ist auch das Snippet vom Anfang korrekt.

 

[das_micha]

Weder noch. Relevant ist der Maximalwert des verwendeten Wertebereiches. Wenn der 255 beträgt dann 255, wenn der 256 dann 256, wenn der 100 beträgt dann 100, u.s.w.

bei der direkten verwendung der werte stimm ich dir zu, aber in diesem fall war es ja eine mathematische operation wo ich mit der gesamten anzahl rechnen muss. wie gesagt, ich habe es durchgerechnet und komme auf komplett andere farben wenn ich den multiplikator auf den höchsten "angabewert" also 255 setze statt dem mathematischen wert von 2^8 also 256.
naja letztendlich auch backe. wenn man sowas zusammenschraubt, dann prüft man ja eh gegen und wenn statt dem z.b. gewünschten 190-190-190 grau plötzlich ein türkis bei rauskommt hat man was falsch gemacht

 

[Pii]

Bei einer Operation sollte nicht 256 herauskommen, wenn der zulässige Maximalwert 255 beträgt.

 

[das_micha]

kommt es ja auch nicht.

der multiplikator (der jeweilige farbwert) liegt wird ja mit einem wert zwischen 0-255 angegeben. der mulitplikand muss aber 2^8 sein da sonst wie beschrieben ein fehler auftritt.

 

[Pii]

Doch, wenn man bspw. 2^8 *1 ausrechnet kommt man auf 256. Das ist 1 über dem zulässigen Maximalwert von 255.

 

[das_micha]

Doch, wenn man bspw. 2^8 *1 ausrechnet kommt man auf 256. Das ist 1 über dem zulässigen Maximalwert von 255.

was aber in dem von mir aufgeführten beispiel mit dem Bitshiftig, und nur darum geht es ja hier, keine rolle spielt! denn dann wäre jede multiplikation des Farbwertes (ausser 0) falsch! und auch das snippet arbeitet mit dem bitshifting nur halt mit dem falschen multiplikand welcher zu einem falschen ergebnis führt. das ich bei generellen mathematischen operationen nie über den maxwert kommen darf ist mir schon klar. aber hier bezieht sich das auf die gelieferten beispiele. und das in ein gefäß mit einem volumen von 1L nur 1L passt und der rest für ne Sauerei sorgt sollte klar sein

 

[Pii]

Du missverstehst da was. Die Bitshifts und die Multiplikation in dem Code machen zwei verschiedne Dinge.
Schau Dir das noch mal genau bei nur einer Komponente an.

 

[das_micha]

Hä???
ich geh jetzt einfach mal von weiß aus also 255 255 255

ich habe einen einen wert der aus der multiplikation von dem jeweiligen Farbwert von 255 für rot mit 2^8. dieses entspricht in der dezimalschreibweise 65280 = binär 1111 1111
je nachdem was ich final für einen binärwert haben will (24Bit oder 32Bit) shifte ich das ergebnis binär auf entweder << 16 oder <<8
damit habe ich den ersten 8er binärblock. die anderen blöcke die in diesem fall ja gleich wären werden durch vermindertes shiften angefügt so das sich am ende ein 24 bzw 32 stelliger binärcode ergibt. weiß jetzt nicht wo ich da verständnisprobleme habe.

 

[Pii]

Die Multiplikation ist Teilschritt zum Umwandeln des float in ein byte. (Vom Wertebereich 0,0 - 1,0 nach 0 - 255)
Das hat aber nichts damit zu tun, dass man die Bitshifts die zur Positionierung sind, auch als Multiplikation umsetzen kann.

 

[das_micha]

Die Multiplikation ist Teilschritt zum Umwandeln des float in ein byte. (Vom Wertebereich 0,0 - 1,0 nach 0 - 255)
Das hat aber nichts damit zu tun, dass man die Bitshifts die zur Positionierung sind, auch als Multiplikation umsetzen kann.

das wurde ja auch nicht gemacht sondern nur das ergebnis der multiplikation geshiftet und zusammengesetzt.

((190*256)<<16)|((190*256)<<8)|((190*256)) (für 32Bit die letzten 8 bit sind 0 für alpha)

egal, ich denke wir beide meinen unterm strick das gleiche bekommen es nur nicht in verständliche worte.

 

[Pii]

Nein, das glaube ich nicht.


Letzter Versuch:
[bgColor redComponent] gibt einen float.
Daher sieht das Beispiel mit dem Code-Snippet (ohne casts) ausgeschrieben so aus.
((0.745099*255)<<16)|((0.745099*255)<<8)|(0.745099*255)

Die Multiplikation mit dem Maximalwert 255 konvertiert nur den float.
Man könnte der Verständlichkeit wegen auch mit 0xFF multiplizieren.
(0.745099*0xFF)<<16|(0.745099*0xFF)<<8|(0.745099*0xFF)

Wenn aber bereits valide bytewerte existieren braucht man das gar nicht, und es würde schon das reichen:
190<<16|190<<8|190


Weil das (int)([bgColor redComponent]*255) nur zum Konvertieren des float ist.
Und das (... << 16) | (... << 8) | (...) nur zum Positionieren ist.

 

[MacApple]

das wurde ja auch nicht gemacht sondern nur das ergebnis der multiplikation geshiftet und zusammengesetzt.

((190*256)<<16)|((190*256)<<8)|((190*256)) (für 32Bit die letzten 8 bit sind 0 für alpha)

Das ist doch umständlich. Genau das gleich erreichst Du mit

(190<<24) | (190<<16) | (190<<8)

Denn eine Multiplikation von Integern mit 256 ist identisch mit 8 Bits nach links schieben.

MacApple

 

[das_micha]

Das ist doch umständlich. Genau das gleich erreichst Du mit

(190<<24) | (190<<16) | (190<<8)

Denn eine Multiplikation von Integern mit 256 ist identisch mit 8 Bits nach links schieben.

MacApple

LOOOOOOOOOOOL
Jetzt wo du es sagst war die ganze zeit auf das snippet vom TS fixiert
Tja manchmal hat man ein brett vorm kopp

 

[das_micha]

Nein, das glaube ich nicht.


Letzter Versuch:
[bgColor redComponent] gibt einen float.
Daher sieht das Beispiel mit dem Code-Snippet (ohne casts) ausgeschrieben so aus.
((0.745099*255)<<16)|((0.745099*255)<<8)|(0.745099*255)

Die Multiplikation mit dem Maximalwert 255 konvertiert nur den float.
Man könnte der Verständlichkeit wegen auch mit 0xFF multiplizieren.
(0.745099*0xFF)<<16|(0.745099*0xFF)<<8|(0.745099*0xFF)

Wenn aber bereits valide bytewerte existieren braucht man das gar nicht, und es würde schon das reichen:
190<<16|190<<8|190


Weil das (int)([bgColor redComponent]*255) nur zum Konvertieren des float ist.
Und das (... << 16) | (... << 8) | (...) nur zum Positionieren ist.

Danke! das war die alles aufklärende antwort auf eine frage die ich ganz ganz am anfang gestellt habe (direkt nachdem karol seinen beitrag abgegeben hat)! da fragte ich was das für floatwerte sind und wo die herkommen. jetzt macht der ganze spaß auch für mich sinn. und wie schon zum beitrag macapple gesagt, hab ich die 256 als 8er shift konsequent ignoriert. dann kann sind wir ja hier durch

danke euch beiden für die finale erleuchtung und noch nen entspannten!