Du siehst mich ein wenig verwundert.
Ich habe auch noch mal nachgeschaut wie es in der Spec von GL_ARB_texture_cube_map steht. Und da ist es genau so beschrieben wie ich es gemacht habe. Laut delphi3d.net hat deine Karte 1.3 als OpenGL Version. Ab dem Zeitpunkt ist die CubeMap auch in den Core gewandert und muss somit unterstützt werden.

Ich an deiner Stelle würde mal den neusten Treiber drauf ziehen. Ich finde das reichlich merkwürdig, da ich das auf verschiedenen Systemen schon ausprobiert hatte. Und das waren alles ATI Karten. Und das sich ein Rechner bei so etwas aufhängt ist alles andere als Normal. Auch wenn es vollkommen falsch wäre.

PS: Evtl wäre es nicht schlecht, wenn du dir auch mal das CubeMapDemo von sulaco anschaust. Die machen eigentlich auch nichts anderes als ich aber die haben eine echse dabei. Wenn die auch nicht funzt, dass ist was ganz anderes im argen.

PPS: Macht deine Karte eigentlich bei irgendwelchen Spielen Probleme?

Hitmen 1,2; SplinterCell; RiseOfNations; Nexuiz;Quake 2 ;AOE 1,2; usw., kein Problemm.
Es stürtz nicht ganz ab, ich habe mich falsch ausgedrückt. Es kommt aber als würde man die Auflösung ändern und dann sagt der Monitor "VGA Mode not Supported", dann hängt alles etaw 2-3 sec., dann kommt das Ganze wieder zu sich und meine Anwendung ist schon geschlossen.
Es kommt keine Fehlermeldung von atiglXXX.dll oder Windows selbst.
Und es gibt keine Fehler in log ( glGetError() ).
Und ja, ich ändere in meiner Anwendung die Auflösung NICHT.

Ich werde das Demo anschuen.

Edit: Treibers sind UpToDate.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Okay. Dann weiß ich auch nicht was man da noch machen könnte.

Das ist wahrscheinlich genau so ein phänomen wie mein erster Direct3D Versuch von vor 4 Jahren. Auf 5 Rechnern lief es perfekt ohne anstalten zu machen und auf dem 6ten ohne auch nur mit der Wimper zu zucken bekam Windows 2k gleich nen Bluescreen.

"VGA Mode nit supported" - ist das nicht meist ein problem mit der wiederholfrequenz? das is bei siedler 3 u. 4 nänmlich auch ein problem bei mir, in niedriger auflösung gehts, aber wenn man höherschaltet(wo ja die maximalfrequenz des monitors zurückgeht), kommt diese meldung.

_________________


"User Error. Replace User and hit Continue."

Hmmm....
Ich weiss nicht. Vielleicht bin ich zu müde.
Die Demos von sulaco funktionieren einwandfrei ( cube maping demo und dynamic cube maping demo ).
....no comment...

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Leider kann ich dir gerade auch keine Exe mit anbieten, aber das bitte einfach mal übersetzen und starten. Sollte so ohne weiteres eigentlich gehen.

Ich hatte auch noch mal geschaut. Sulaco benutzt 6 getrennte Texturen und bindet die einzelnen Untertexturen (GL_TEXTURE_CUBE_MAP_POSITIVE_X etc.). Ich hingegen benutze die GL_TEXTURE_CUBE_MAP und die Untertexturen nur zum Übertragen der Bilddaten. Was laut Spec auch so angegeben wurde.

Danke für die Code, es hilft und funktioniert. Wenn ich den Fehler in meiner Anwendung gefunden habe, dann sage ich es auch .

Eine Bemerkung, ein Vorschlag oder gar Freedback hätte ich noch im Bezug auf glBitmap.pas.
Vielleich ginge es schneller so:



EDIT:
So getestet:

Ist meine F. weit überlegend. ( 0,0379 sec gegen 0,26404 sec )
Ob dies ein Vorteil ist hängt davon ab ob man es wirklich so eilig hat. Ich denke eher nicht.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Okay. Das beruhigt mich ja schon, dass wenigstens das jetzt bei dir läuft.

IsPowerOfTwo: Ja da könntest du durchaus recht haben. So sucht er nur bis zum ersten Bit. Ich benutze aber keine Arithmetischen sondern Bitoperatoren. Habe jetzt ein Weg dazwischen gewählt.

PS: Tu dir keinen Zwang an und mache ruhig Vorschläge für den restlichen Code. Also die Stellen an denen de Bilder geladen werden etc.

probier mal das:

Kann sein, dasses dann evtl noch schneller geht, weil meiner Meinung nach der shr Befehl weliger interne Zyklen im Proc braucht, als Div und das Bitweise und schneller ist als eine Modulo und ein Vergleich. Bei Assembler isses definitiv schneller.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

div wird vom Compiler in shr umgesetzt, wenn es sich dabei um einer Zweierpotenz handelt.
Aber man kann auch ganz ohne Schleife.

result := ((Val and (Val-1))=0) and (Val<>0);

Da merkt man glatt, dass du schon sehr viel und ich (noch) zuwenig mit Assembler programmiert hast. In den Hochsprachen wird man einfach zu sehr verwöhnt, da kommt man garnicht mehr auf solche Ideen

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Ähm. Ich will ja nicht unken. Aber das ist ein Stück code der gerade 2 Mal pro Texturengenerierung aufgerufen wird. Da könnte ich sogar noch nen Sleep einbauen und es würde keiner merken.

Wenn jemand etwas tun möchte, dann bin ich für Performancevorschläge bei allem anderen dankbar. Die wohl gemerkt nichts an der derzeitigen Struktur ändern. Das ist eine Anspielung darauf, dass man TGA's und PNG's auch schneller (ohne umweg) laden könnte.

Wenn das Texturladen noch schneller gehen könnte wär das super. Bei einem Projekt, was ich in kürze mal hier vorstellen will, ist der Start durch das laden der Texturen ganz schön Zeitraubend. Bin da sehr gespannt, wie du deinen Loader noch optimierst.

Aber man sollte mal diesen Thread hier aufsplitten: In den Teil der was mit dem Tut zu tun hat (was nochmal überarbeitet werden sollte... ) und dem Loaderteil.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich muss mich ersmal entschuldingen für die OT, aber @Sidorion, deine Variante ist doppelt so schnell.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

@Flash: Bin für Vorschläge jederzeit offen. Aber ehrlich wüsste ich nicht was ich daran noch optimieren könnte.

@Thread: Japp. Da könntest du recht haben ist ein wenig vom Thema abgekommen.