Also, ich wollt von euch mal wissen, wie ihr eure Texturen in OpenGL managed.
Ich habe ne CTexture klasse, ind die ich BMPs und mein Hauseigenes Tpk format (Texture Package) laden kann. In einer anderen Klasse, CTexturePackage, werden zu Anfang alle Texturen in CTexture Klassen geladen und dann in ein Hash-Array gespeichert. Beim Beenden wird dann alles wieder freigegeben.

Habt ihr bessere Methoden?

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

Nicht wirklich. Allerdings bevorzuge ich es, wenn man Texturen zu jeder beliebigen Zeit laden oder entladen kann.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Also das die Engine zwischendurch immer wieder mal LoadTexture(dateiname) oder UnloadTexture(Texturid) aufrufen kann ?!

Ich hab mal dran gedacht, das Texturen, die seit 500 Frames oder so nicht mehr benutzt worden sind, einfach zu ent-laden, und wenn sie benutzt werden, werden sie wieder geladen. Noch besser: Wird die Tex nicht benutzt, wird eine (vorberechnete) sehr viel kleinere Version der Textur anstelle der Großen geladen. So könnten keine "schwarzen Löcher" durch den Ladevorgang der "großen" Textur entstehen!

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

Ja, man kann dann zwischendurch [Un]LoadTexture aufrufen. Um genau zu sein ruft man Texture::Load() auf, eine statische Funktion, die die Liste der geladenen Texturen überprüft und die Textur lädt bzw. die Reference Count erhöht. Freigegeben werden Texturen dann mit pTexture->Release().

Die Idee mit dem Umbauen der Texturen halte ich nicht für besonders gut, da sich schlecht vorhersagen läßt, wann eine Textur gebraucht wird. Wenn du allerdings eine gigantische Welt hast, die in Zonen aufgeteilt ist, könntest du z.B. immer nur die Zone, in der der Spieler ist und die Nachbarzonen im Speicher halten und dementsprechend auch die Texturen organisieren.

Wirklich interessant ist eine Hardware/Treiber-basierte Lösung wie sie AFAIK vom neuen P10-Chip von 3dLabs verwendet wird, wobei der Grafikkartenspeicher als Cache betrachtet wird: alle Texturen liegen im RAM, und bei Bedarf werden Texturen in den Onboard-Speicher geladen. Mit dieser Lösung kann man auch bei geringerem Onboard-Speicher effizient arbeiten. Einziger Nachteil ist eben, daß die Texturen, die gerade im Cache sind, auch im Hauptspeicher liegen, d.h. es wird Speicher verschwendet.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Aber (die meisten) haben mehr RAM aufm Board als auf der Grafikkarten (ausg. GF4 mit 128MB, aber wenn die Zahlen weiter so wachsen, braucht man sich nachher gar keine Gedanken mehr ums TexManagement machen)

Benutzt du eigendlich sowas wie WAD-Files? (Ich hab so was ähnliches)

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

wad-files ist ja wohl das blödeste was man benutzen kann!

1. Wad-Files sind 256 Farben mit RGB-Palette begrentzt.
2. Wad-Files unterstützen keine Kompression.
3. Wad-Files speichern einige Mip-Levels die man auch gur zur Laufzeit erstellen kann und verschwenden dadurch noch mehr Speicherplatz als sie es so schon machen.
4. Sie unterstützen keinen Alpha-Channel.

Ich werde in Zukunft nur noch gängige Dateiformate verwenden (auch für Maps), da hat man am wenigsten Streß mit dem Editing.
Falls notwendig können rechenintensive Preprocessing-Dateien gecachet werden, so wie es HL mit Nodefiles für das Monster-Pathfinding macht.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

@Diabolo_bth:

Meine "wad" files heißen "tpk" = "Texture Package"
Da drin kannste 32Bit Texturen speichern. (Alpha channel muss ich ma gucken, das sind dann... 40 Bit Texturen)

Aber sie kompressieren auch nichts.. Kenn keinen Kompressing Algo... :(

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

32 Bit = 4 Byte

3 Bytes Farben (RGB)
1 Byte Alphaanteil (0-255)

Wofür dann das 5. Byte?

Zum Komprimieren (net "Kompressieren") würde ich einfach einen LWZ-Algorithmus nehmen und ihn dementsprechend anpassen (zlib googeln oder mal bei www.gnu.org suchen).

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

32 Bit hmm.. stimmt... Wiso gibts dann 32Bit BMPs mit nur 3Farben?

Ah: Remember: 0x00RRGGBB ? !
Also könnte man ja ganz einfach nen AlphaChanngel hinzufuegen:
0xAARRGGBB
!!

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

Hmm.. 40Bit = 10Bit pro Kanal? ;)

Die 32-Bit BMPs lassen halt einfach ein Byte ungenutzt. Man verwendet trotzdem lieber 32-Bit statt 24-Bit (auch für reines RGB ohne A), weil man dann mit aligned words hantiert, und dabei ist der Speicherzugriff schneller als bei unaligned data.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Hrm Hrm Prefect... Das hab ich da oben erkannt!

0x00000000
0xB1B2B3B4

B1 = Ungenutzt (Alpha?)
B2 = Rot
B3 = Grün
B4 = Blau

0x??RRGGBB

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

Ja klar. Ich wollte nur noch anmerken, _warum_ man 32 Bit verwendet (wo 24 Bit doch eigentlich platzsparender wäre).

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

warum nimmst du net 16 bit das ist doch viel platzsparender, oda?

16 bit is scheiße, da man für jeden der 3 Farbkanäle 5 Bits verwendet -> da hängt man lieber nich ein byte an jedes Pixel und hat nicht mehr das Heckmeck beim laden und man hat keinen Alpha-Channel.

für die Graka und das Ram is 32-Bit pro Pixel sowiso am besten - da man ja schließlich mit einem 32-Bit System umgeben ist (noch :P)

für Alpha-Texturen finde ich komprimierte TGA's immer noch am besten - klar RLE nich so gut wie über eine discrete cosinus-Transformation [jpeg] - aber dafür verlustfrei. (png geht auch noch, is aber schwerer zum Laden, wenn man keine lib benutzt)

Zitat:

Diablo_bth postete
klar RLE nich so gut wie über eine discrete cosinus-Transformation [jpeg] - aber dafür verlustfrei. (png geht auch noch, is aber schwerer zum Laden, wenn man keine lib benutzt)

NIEMALS verlustbehaftete formate fuer texturen benutzen, das sieht zum reihern aus.
jpeg ist ganz nett zum anschauen, aber nicht um irgendwelche sachen damit zu machen, fuer die es nicht konzipiert wurde.

'KEINE PANIK' - aus der Triologie in fuenf Baenden von Douglas Adams

'FÜR DEINN FERD' - aus 'Gevatter Tod' von Terry Pratchett

*blickaufdiablo* : Benutzt du nicht *.jpg Texes in deiner Engine??

Kennt jemand nen guten Loader der *alle* Bildformate laden kann (Ich hab jetzt echt keine Lust, nen Loader für komprimierte Targas oder Pngs zu machen, von der Materie (De/Komprimieren) verteh' ich eh nichs), und das leicht zu implementieren ist ( #include "pictureloader.h", und man kann alle funktionen benutzen) ? (ich hatte ma einen, aber mit dem bin ich nicht klargekommen! Am besten:

[code]
struc TPICTURE
{
SIZE size;
BYTE* pData;
}
Immer 32Bit! (Also lengt(pData) == size.cx * size.cy * 3 )

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

@Diablo_bth: Außer man geht wieder zum Hardcore-Programming über und macht das ganze Shading usw. auf Softwarelevel, jeweils 2 Pixel (also 32 bit) gleichzeitig.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

TTT: Selbst da wäre 32 Bit besser, denn dann kannst du MMX-Routinen verwenden. 8-8-8-8 kann MMX handeln, 5-5-5/5-6-5 nicht.

Tron: Interessanterweise verwenden die meisten (alle?) Quake 3-Engine-Spiele JPEG für normale Texturen, und TGA für Texturen mit Alphakanal.

Für verlustfreies Packen ist wohl PNG am besten, vor allem da es auch einen Alphakanal unterstützt.

Zum Laden von Bildern: Nun, es gibt natürlich für die komplexeren Bildformate eigene Libraries (libjpeg, libpng), und es gibt Libraries wie SDL_image, die gleich eine ganze Reihe von Bildformaten unterstützen.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

PNG ist gut, da der Alphakanal sogar fadebar ist (in der letzten Revision von PNG). Das es aber immernoch ziemlich hakt am Support sieht man am Besten bei den ganzen Browsern, die stricken sich ihr PNG so zusammen wie sie's grade brauchen. Aber als Texturbasis wäre das mal cool. Aber vorsicht! Bei vielen Farben pro Textur (ungünstigster Fall wäre z.B. ein Farbverlauf oder gar mehrere) wird ein PNG nicht mehr sonderlich großartig komprimiert. Große Erfolge sind eher bei unifarbenen oder wenig-colorierten Texturen zu verzeichnen.

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Hauptsache, es ist kleiner als BMP ;)

@diabolo_bth: Shader usw.. in die Textur mit reinpacken? Wat hat das fürn nutzen?

@Prefect: Genau diese SDL Lib hatte ich, bin damit aber überhaupt nicht klar gekommen (Ich glaub, das brauch auch das ganze SDL-Grundsystem :( SDL_WindowInit() usw...)

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

@viking: wie meinst Shader in eine Textur reinpacken? Als Shader würde ich die Rendering-Eigenshaft einer Oberfläche bezeichnen - die umfass durchaus Texture-mapping - hat aber mit Bildformaten reichlich wenig zu tun.

ich benutze jpegs in meiner engine schlicht des Platzes wegen - der Unterschied zu verlusfreien Formaten ist minimal und eigentlich nicht relevant - da die Gaka bei minification/magnification alles sowiso nochmal überfiltert (vom bilinearen oder trilinearen filtering ganz zu schweigen)

Zitat:

Prefect postete
Für verlustfreies Packen ist wohl PNG am besten, vor allem da es auch einen Alphakanal unterstützt.

@Kriz: PNG wird von Opera vollständig unterstützt. (Also mit Alpha)

abgesehen vom ie läuft png eigentlich in allen browsern problemfrei

IE mal wieder... *g*Weiß nicht, was alle gegen MS haben. Läuft bei mir (fast immer ) alles wunderbar! ( Ich hab noch NIE, NIE PNGs auf Internetseiten gesehn)

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446