Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

11

27.08.2010, 11:24

@dot: ja vielleicht wärs wirklich einfacher, das ganze bild zu kopieren und das texturemapping anzupassen.

Es wäre nicht nur einfacher sondern sicherlich auch um Größenordnungen effizienter.

12

27.08.2010, 12:03

Hi!

Ich wollte nur mal kurz fragen wieso dein Array so angelegt wird?

C-/C++-Quelltext

1
unsigned int *pixelBuffer = new unsigned int[width*height*sizeof(unsigned int)];


Für was benötigst du das sizeof(unsigned int)? Falls du das eingebaut hast weil du ja RGBA Werte speichern musst, dann kannst du das getrost weg lassen. Ich gehe nun mal von einem Betriebssystem aus bei dem ein int 32Bit hat. Damit kannst du dann ja einen Pixel komplett in einem unsigned int unterbringen -> 0x00000000(HEX). Für R, B, G und A stehen nun je 8 Bit zur Verfügung, welche reichen um jede Farbkombination und Alphawerte für einen Pixel zu erstellen.

Falls das sizeof(unsigned int) doch eine andere Bedeutung hat oder ich grad einen Denkfehler habe, dann bitte ich darum meinen Post einfach zu ignorieren :-) .

So long,
Chris

Beiträge: 774

Beruf: Student

  • Private Nachricht senden

13

27.08.2010, 12:11

Prinzipiell wärs besser, hier unsigned char einzusetzen und das *4 zu nehmen. Klar muss man dann bei den Indices des Buffers das auch wieder beachten, aber es ist einiges übersichtlicher und eindeutig auf allen Systemen. Außerdem ists mit unsigned int ziemlich knifflig wieder auf die Farbwerte zuzugreifen.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

14

27.08.2010, 12:27

Außerdem ists mit unsigned int ziemlich knifflig wieder auf die Farbwerte zuzugreifen.

Dafür aber potentiell schneller ;)

Beiträge: 774

Beruf: Student

  • Private Nachricht senden

15

27.08.2010, 13:56

Hm stimmt.. naja alles hat seine Vor- und Nachteile :D
Wenn man jetzt aber die einzelnen Farbwerte lesen wollte - was denkst du, was dann noch schneller ist? Also ein Array von unsigned int durchgehen und jeden Pixel in 4 unsigned char casten oder aber die Variante mit 4x so vielen unsigned char?

16

27.08.2010, 13:58

ja das *sizeof(unsigned int) hab ich mir eingebildet... das war eh blödsinn...
weil ich speicher ja eh schon pro int alle werte und nicht pro int einen wert oder so.

jedenfalls is es nicht nötig, wenn man es so macht wie ich.
und ja kompliziert... nicht so wirklich

ich hab ja 8888 bit... und shifte mir einfach den rot wert ganz vor hin und so weiter...
ist ein einzeiler der spass...

lg

17

27.08.2010, 14:04

Dann probiere mal nicht unsigned int sonern unsigned char, als Typ deines Arrays.
Und dann fällt auch das shiften weg. Vlt. liegt dort der Fehler.
Vlt. mal des gesamten Code posten?

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

18

27.08.2010, 14:05

Wenn man jetzt aber die einzelnen Farbwerte lesen wollte - was denkst du, was dann noch schneller ist? Also ein Array von unsigned int durchgehen und jeden Pixel in 4 unsigned char casten oder aber die Variante mit 4x so vielen unsigned char?

Ein Array von unsigned int durchgehen und auf die Farbwerte mit Bitoperationen zugreifen ist sicherlich das schnellste. Auf deine unsigned ints hast du, wenn nicht ganz grob was schiefgegangen ist, einen aligned memory access pro Pixel. Bei einzelnen chars (natürlich auch wenn du den uint in einzelne chars "castest") hast du dagegen einen aligned und zwangsweise 3 unanligned Zugriffe wobei letztere signifikant langsamer sind als erstere. Was schnelleres als Bitoperationen gibts sowieso nichtmehr, ein Speicherzugriff is dagegen extrem langsam wobei man in deinem Fall davon ausgehen kann dass die Dinger vermutlich schon im Cache liegen werden was das ganze weniger schlimm macht. Natürlich besteht auch die Chance dass ein sehr sehr schlauer Compiler von selber Bitoperationen auf DWORDs statt Pointerschubserei macht und dann beides im Endeffekt gleich schnell ist, das müsste man aber mal testen ob der Compiler das wirklich tut.

Natürlich kann ich nur wiederholen dass es vermutlich am effizientesten wäre sich das ganze überhaupt zu sparen und stattdessen die Texturkoordinaten anzupassen.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »dot« (27.08.2010, 14:15)


Werbeanzeige