In einen, mittels Pointer, relativen, addressierten, Speicher schreiben
-
@wob sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
@Swordfish sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
da er technich ein vorzeichenloser Int ist ( beide sind 32bit Breit ).
Nein, das ist nichts was vom C Standart garantiert wird.
Genau, und bei modernen 64-Bit-Rechnern ist meist sizeof(int) = 4 und sizeof(int*) = 8. Es ist technisch gesehen also keineswegs immer dasselbe. Es darf allerdings dasselbe sein (der Standard verbietet nicht, dass beide dieselbe Größe haben)
aber das gilt doch nur, wenn ich mein Programm für 64bit compilieren würde.
Mein Programm zielt aber nur auf die 32bit Compilierung ab, da 32bit Programme auch auf älteren Computern lauffähig sind
-
@Swordfish sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
Standartmäßig davon auszugehen ist halt in jedem Fall falsch.
ok, das bedenken gebe ich zu, werde noch nen if einfügen, der die versehentliche compilierung auf 64bit unterbindet, sowas wie
if ( sizeof(int) != 4 ) { töte alles };
-
Wenn du ne feste breite haben willst, nutze uint8_t, int8_t, uint16_t etc.
Meines Wissens nach garantieren dir die, dass ein uint8_t z.B. ein vorzeichenloser 8-bit integer ist.
Wie viel bit ein int, short, long int usw. hat, ist system abhängig. Wenn es also darauf ankommt, nutze sie nicht.
-
@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
ok, das bedenken gebe ich zu, werde noch nen if einfügen, der die versehentliche compilierung auf 64bit unterbindet, sowas wie
if ( sizeof(int) != 4 ) { töte alles };
Auf den meisten 64-Bit Systemen ist
int
auch weiterhin 32 Bit groß.Und wenn du UB (undefiniertes Verhalten) in deinem Programm hast, dann kann das „töte alles“ sowieso passieren.
-
@DirkB sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
@WinSysCompany du solltest ImageMemory nicht als 2D-Array von
int
definieren.
Eher als Array von einerstruct
danke, dass du mich auf den rechten Weg geführt hasst. ^^
Ich muss zugeben, daran habe ich garnicht gedach:struct tex { int used; int width; int height; int *mem; int x; int y; }; struct tex ImageMemory[255]; int DummyTex(int tex, int size, int c1, int c2) { fprintf(stderr, "Create Texture ... "); ImageMemory[tex].used = 0; ImageMemory[tex].mem = malloc(size * size * sizeof(int)); if ( ImageMemory[tex].mem == NULL ) { fprintf(stderr, "failed\n"); return 0; } else { ImageMemory[tex].used = 1; ImageMemory[tex].width = size; ImageMemory[tex].height = size; for ( int y = 0; y < size/2; y++) { for ( int x = 0; x < size/2 ; x++) { int *address = ImageMemory[tex].mem; address + ( ImageMemory[tex].width * y * 4 ); address + ( x * 4 ); *address = c1; } } ImageMemory[tex].x = size/2; ImageMemory[tex].y = size; } return 1; };
jetzt funktioniert alles, danke nochmal
-
@WinSysCompany wenn du an DummyTex jetzt noch die Adresse der struct und nicht den Index der globalen Variablen übergibst, wirst du viel flexibler in der Anwendung.
(Du kannst auch erstmal weiterhin dein globales Array verwenden, übergibst jedoch die Adresse des Elements)
-
das Problem ist, die teile meines Programms außerhalb von texture.c sollen sich ja mit der Array nicht befassen müssen, wenn sie jedoch den Pointer liefern, mussen sie sich ja damit befassen.
ich arbeite hallt lieber mit dem Index, da sie später in der Map-Datenstruktur auch mit ihrem Index und nicht mit der Adresse adressiert werden. die können sie dan einfach an die Befehle wie GetTexPixel() LoadTex() etc. übergeben
-
@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
address + ( ImageMemory[tex].width * y * 4 ); address + ( x * 4 );
jetzt funktioniert alles, danke nochmal
lol
Da funktioniert überhaupt nichts.
-
@Wutz sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
@WinSysCompany sagte in In einen, mittels Pointer, relativen, addressierten, Speicher schreiben:
address + ( ImageMemory[tex].width * y * 4 ); address + ( x * 4 );
jetzt funktioniert alles, danke nochmal
lol
Da funktioniert überhaupt nichts.hab ich einen Denkfehler ?
- ich habe die Adresse
- ich erhöhe die Adresse
- ich schreibe c1 unter die Adresse
oder funktioniert die Implementierung nicht ?
der Compiler gibt mir grünes licht ...
-
@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.
-
@WinSysCompany was macht eigentlich das * 4 ?
-
@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!