In einen, mittels Pointer, relativen, addressierten, Speicher schreiben
-
@DirkB sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
@WinSysCompany was macht eigentlich das * 4 ?
ein Int ist 32bit breit also 4(!) x 8 bit = 4 Byte daher muss ich je Pixel ( RGBA als Int gespeichert ) den Pointer um 4 Byte bewegen
-
@WinSysCompany sagte in [In einen, mittels Pointer, relativen, addressierten, Speicher schreiben]
ein Int ist 32bit breit also 4(!) x 8 bit = 4 Byte daher muss ich je Pixel ( RGBA als Int gespeichert ) den Pointer um 4 Byte bewegen
Du weißt aber schon, dass +1 bei einem int*-Pointer den Pointer um die Breite eines ints weiterbewegt und nicht um ein Byte?
-
@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
ein Int ist 32bit breit
Das ist eine Annahme, die oft, aber nicht immer Stimmt. Daher solltest du das in C nie so machen.
Mal abgesehen, dass dies von der Pointerarithmetik ganz automatisch erledigt wird, würde man statt der 4 sizeof(int) oder sizeof(*adresse) nehmen.
-
for (size_t i = 0; i < size * size; ++i) ImageMemory[tex].mem[i] = c1;
oder wenn du es unbedingt "händisch" haben willst:
for (size_t i = 0; i < size * size; ++i) *(ImageMemory[tex].mem + i) = c1;
Was aber beides dasselbe ist.
foo[index]
ist nur eine andere Schreibweise für*(foo + index)
macht aber ein und dasselbe.@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
ImageMemory[tex].x = size/2; ImageMemory[tex].y = size;
size / 2
...size
... wie denn nu?Nebenbei frag' ich mich, warum man vorzeichenbehaftete Typen für RGBA-Pixel haben wollen würde.
uint32_t
oder wenn voriges nicht vorhandenuint_least32_t
ftw.
-
@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
ein Int ist 32bit breit also 4(!) x 8 bit = 4 Byte daher muss ich je Pixel ( RGBA als Int gespeichert ) den Pointer um 4 Byte bewegen
Ein int ist mindestens 16Bit breit, mehr garantiert die ISO Norm von C nicht. Es gibt real existierende Implementationen mit 16Bit, 32Bit und 64Bit Ints.
Und man sollte und kann Programmcode so schreiben, dass er unabhängig vom Adressmodell ist. D.h. für die RGBA Werte sollte ein uint32_t verwendet werden, und man addiert nicht die Größe eines Datentyps auf die Zeigeradresse das ist so ziemlich dass wofür C in Verruf geraten ist. Es gibt den Indexoperator [] mit dem unnötige Fehler vermieden werden können.
-
@DirkB sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
@WinSysCompany schalte mal die Warnungen vom Campiler an bzw. auf höchste Stufe.
Da kommt dann eine Warnung etwa „Ausdruck hat keinen Effekt“
Da, wo du 2. vermutest.
jip hast recht, hab jetzt ´nen
*(address + ( ImageMemory[tex].width * y * 4 ) + ( x * 4 )) = c1;
d´raus gemacht
-
@wob sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
@WinSysCompany sagte in [In einen, mittels Pointer, relativen, addressierten, Speicher schreiben]
ein Int ist 32bit breit also 4(!) x 8 bit = 4 Byte daher muss ich je Pixel ( RGBA als Int gespeichert ) den Pointer um 4 Byte bewegen
Du weißt aber schon, dass +1 bei einem int*-Pointer den Pointer um die Breite eines ints weiterbewegt und nicht um ein Byte?
nein wusste ich nicht ...
also muss überal wo ich pointer benutze das "*4" weg !??
-
@Swordfish sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
for (size_t i = 0; i < size * size; ++i) ImageMemory[tex].mem[i] = c1;
oder wenn du es unbedingt "händisch" haben willst:
for (size_t i = 0; i < size * size; ++i) *(ImageMemory[tex].mem + i) = c1;
Was aber beides dasselbe ist.
foo[index]
ist nur eine andere Schreibweise für*(foo + index)
macht aber ein und dasselbe.@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
ImageMemory[tex].x = size/2; ImageMemory[tex].y = size;
size / 2
...size
... wie denn nu?sorry aber das ist Engine-intern das macht so für sich keinen Sinn, daher kann ich es auch nicht erklären
nur soviel: der Punkt mit dem eine Textur standertmäßig in der Welt positioniert werden so ist bei der Textur unten mittig > also UNTEN ( x = height = size ), MITTIG ( y = widht/2 = size/2 )
Nebenbei frag' ich mich, warum man vorzeichenbehaftete Typen für RGBA-Pixel haben wollen würde.
uint32_t
oder wenn voriges nicht vorhandenuint_least32_t
ftw.das ist ne Angewohnheit von mir, ich betrachte Farbwerte NIE als Zahl, daher ist mir die Interpretierung ( Vorzeichenlos oder nicht ) egal, da ich auf die Komponenten ( R, G, B und Alpha ) ehr immer durch Binäroperationen ( wie "<<" ">>" "|" oder "&" ) zugreife
-
Dieser Beitrag wurde gelöscht!
-
@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
also muss überal wo ich pointer benutze das "*4" weg !??
@Swordfish sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
foo[index]
ist nur eine andere Schreibweise für*(foo + index)
Wo ist da das * 4?
Dort, wo du
*(foo + index)
her hast, sollte dieses Verhalten aber erklärt sein.
-
@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
immer durch Binäroperationen ( wie "<<" ">>" "|" oder "&" ) zugreife
Das solltest du aber nicht machen, da es zu Überraschungen kommen kann.
Bsp: Rotkanal wird Blau (edit: bzw. in deinem Fall der Grünkanal, aber egal), Alphawert 0x40int i=0x80000000; i>>=24; int clr=i; clr<<=16; clr|=0x40; assert(clr==0x00800040);
Ob das Vorzeichen erhalten bleibt oder nicht und somit die Annahme zutrifft (oder nicht) ist implementierungsspezifisch.
-
@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
jip hast recht, hab jetzt ´nen
*(address + ( ImageMemory[tex].width * y * 4 ) + ( x * 4 )) = c1;
d´raus gemacht
Mhm. Und das ist mit deinen zwei
for
-schleifen (wenn ich mir* 4
jeweils vegdenke) genau dasselbe in unleserlich wie mein einefor
-schleife oben.@yahendrik sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
Und das ist eben undefiniert.
Rechtsshift auf
signed
Typen ist implementation-definedwenn ich nicht irre.Bitwise shift operators (§6.5.7/5):
The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 / 2E2 . If E1 has a signed type and a negative value, the resulting value is implementation-defined.
Schlimmer für Linkshifts:
Bitwise shift operators (§6.5.7/4):
The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1 x 2E2 , reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1 x 2E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.
@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
[...] daher ist mir die Interpretierung (Vorzeichenlos oder nicht ) egal, da ich auf die Komponenten (R, G, B und Alpha) ehr immer durch Binäroperationen ( wie "<<" ">>" "|" oder "&" ) zugreife
Ist eben nicht egal.
@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
for ( int y = 0; y < size/2; y++) { for ( int x = 0; x < size/2 ; x++) { /* ... */ } }
Willst Du eigentlich nur den linken oberen Quadranten füllen (und die anderen Pixel haben unbestimmte Werte) oder die gesamte "Textur"?