Hallo Leute,

ich habe folgendes Problem: Ich zeige eine Art Landschaft (ich nenn das mal Map) mit SDL und OpenGL an, die verschiedene Texturen hat.

Meine Variable "groundTextures" ist ein Array vom Typ "TglBitmap2D".

In meinem Programm läuft nun folgendes ab:

Zunächst setze ich die Größe des Arrays (anhand dessen, wieviele verschiedenen Texturen in der Map vorkommen - nicht sehr performant, aber darum geht's im Moment auch noch nicht). Dann laufe ich in einer Schleife die gesamte Array-Größe durch und mache dabei folgendes:



In der Render-Prozedur gehe ich dann jedes zu zeichnende Feld (der Map) durch und führe vor dem jeweiligen Quad immer


auf. An "glEnable(GL_TEXTURE_2D);" habe ich gedacht.

Das ganze könnte man statt des TBitmap namens bitmap_cache natürlich über Pointer machen. Aber das habe ich bereits versucht und das Ergebnis ist dasselbe.

Die einzelnen Texturen werden nicht so dargestellt, wie sie aussehen sollen, sondern merkwürdig bunt gemixt (als wäre eine komische Palette verwendet worden oder alle Farben irgendwie invertiert).
Das Problem scheint zu ein, dass ich mehr als eine Textur benutze. DENN, wenn ich eine Map habe, in der nur eine Textur vorkommt (das heißt der Code ganz oben wird nur einmal ausgeführt), dann wird diese Textur auch auf der gesamten Map so angezeigt wie sie soll.


Wenn ihr euch darunter nichts vorstellen könnt, kann ich gerne mal Screenshots posten. Vielleicht liegt aber auch ein grundsätzlicher Fehler vor, den ihr schnell finden könnt.

Ich bedanke mich schonmal im Voraus für jede Hilfe!

Übrigens spitzen-Wiki - da findet man echt ne Menge guter Hinweise!


PS: Das Problem _kann_ natürlich auch in meiner writebitmap-Prozedur liegen. Allerdings funktioniert diese zumindest in Windows, wenn ich das Bild in ein Image schreibe. Naja.. von einigen (seltenen) merkwürdigen Speicherfehlern mal abgesehen...

Das glEnable brauchst du in der verbindung mit der glBitmap nicht mehr auffrufen. Ich habe daran gedacht, dass beim Bind automatisch glEnable mit dem Target aufgerufen wird. Außer es wird explizit unterbunden.

Jetzt aber mal zu deinem Problem. Ich kann so keinen Fehler erkennen. Es wäre sehr hilfreich, wenn du mal ein Screenshot von den betroffenen Stellen machen könntest. Idealst dann auch noch mit original Textur damit man das vergleichen kann. Dann können wir dir mit sicherheit mehr sagen.

Okay, der Fehler scheint wohl doch in meiner Prozedur zu legen - da, wenn ich das Bild jeweils direkt als JPG speichere, darin auch der Fehler zu sehen ist.

Mir ist nur eine Sache wichtig: Das TGLBitmap2D.Assign funktioniert das wie das TBitmap.assign, soll heißen, dass es eine Kopie des Bildes, das man übergibt, erstellt, oder muss das Bild, das man übergibt anschließend noch existieren?

Danke!


EDIT: Okay, brauchst nicht mehr zu antworten. Hab das Problem jetzt gelöst - Schuld war meine Unkenntnis bezügl. Palettenhandles...

Noch eine Frage, weil das ja auch mit glBitmap zu tun hat (und verwaschene Texturen kriegt man auch, wenn mans falsch macht):

Ich habe hier zwar schon gelesen, dass openGL 8 Bit Texturen nicht mag. Aber gibt es nicht vielleicht doch irgendeine Möglichkeit, an das TGLBitmap2D 8-Bit-Texturen zu übergeben? Das würde meinen Speicherbedarf dritteln und wäre eine enorme Steigerung für meine Performance.

Danke im Voraus!

Also die neuste Version kommt auch prolemlos mit 8 Bit Texturen klar. Aber da muss man zwischen Palettenbildern und Graustufen unterscheiden. Denn Palettenbilder werden von OpenGL nicht unterstützt. Es gibt zwar die Funktionalität in OpenGL aber es wird nicht von der Hardware unterstützt. Bzw macht es qualitiv keinen Sinn. Graustufenbilder sind aber wie 32Bit mit nur einem Kanal. Also recht unspektakulär.

Eine andere Alternative wären 16 Bit Texturen. Also R5 G6 B5. Das wird aber auch nur von einem BMP unterstützt. Aber es kann durchaus passieren, dass dir dein OpenGL Treiber die Bilder dann intern wieder in 32 Bit abspeichert, weil er so schneller damit arbeiten kann. Also 32Bit als Texturformat ist so ziemlich das Schnellste was es gibt.

Aber auch nur solange genug speicherplatz zur verfügung steht. Wird der knapp kann es auch sein, dass das ganze schneller wird, wenn das kleinere format gewählt wurde.

Im Zuge der Entwicklung für die neue glBitmap habe ich auch eine Möglichkeit eingebaut um erstellte Texturen wieder zurück zu holen. Und da konnte ich bei ATI und 16 Bit gut sehen, dass diese intern in 32Bit umgewandelt wurden. Was sich auch mit dem verzögerten Upload der Texturdaten wiedergespiegelt hat. Also da hat der Aufruf von glTexture2D in etwa 20 ms länger gedauert als sonst.

Von der Bandbreite hast du da vollkommen recht. Die Texturen sind kleiner. Somit benötigen sie sowohl auf der Platte als auch im Speicher (normal) weniger Speicher und es wird auch nicht so viel übertragen. Aber im Chip ist es dann so, dass einzelne Bits eines Bytes unterschiedlichen Kanälen zugewiesen ist. Und das erfordert höhere Rechenlast als nur einzelne Bytes abzugrasen. Ich denke mal, dass der Größenvorteil dadurch wieder problemlos zu nicht gemacht wird.

Das betrifft aber nicht alle 16Bit Formate. Ich meine RGBA4 wäre davonnicht betroffen. Bin mir dabei aber nicht so ganz sicher. Bzw je nach Chiparchitektur kann es auch sein, dass der Chip das genau so einfach handeln kann wie den Rest auch. Ein ATI zieht aber eher 32 Bit vor. Und ob der Treiber da einen Unterschied zwischen viel und wenig vorhandenem Speicher macht kann niemand so genau sagen.