Kein Status zu Shader

[EyDu]

Hallo.

Ich versucher gerade einen recht einfachen Shader zu erzeugen, ich wundere mich aber ein wenig, dass dies nicht funktioniert. Vielleicht vorweg mal der Code:

Code: Alles auswählen

		const GLcharARB* vertexShader[1];
	
		const char buffer[] =
	            "void main(void)"\
		    "{"\
		    "	gl_Position     = gl_ModelViewProjectionMatrix * gl_Vertex;"\
		    "	gl_TexCoord[0]  = gl_MultiTexCoord0;"\
		    "}";
		
		vertexShader[0] = buffer;
		
		int vertexShaderLength = strlen(buffer);
		
		//initialise GPU stuff
		GLhandleARB mProgramObject,
                                    mVertexShaderObject;
		
		mProgramObject = glCreateProgramObjectARB();
		mVertexShaderObject = glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
		
                glShaderSourceARB(mVertexShaderObject, 1,
                                             vertexShader,
                                             NULL);
						  
                glCompileShaderARB(mVertexShaderObject);
		
                int result = 42;
                glGetObjectParameterivARB(mVertexShaderObject,
                                                          GL_OBJECT_COMPILE_STATUS_ARB,
                                                          &result);

Das Problem liegt nun in den letzten vier Zeilen: Nach dem glGetObjectParameterivARB-Aufruf behält "result" immer den Wert bei, den es auch schon vorher hatte. Egal ob ich nun absichtlich Fehler in den Shader einbaue oder nicht. Hat von euch vielleicht jemand eine Idee, warum der Code nicht funktioniert?

Bis dann
Sebastian

[Dirk Schulz]

Hi,

habe noch nie was mit OpenGL gemacht und wenn ich mir das angucke, bestärkt mich das darin, es nie zu tun. :D

Aber wenn ich das richtig verstanden habe, will glShaderSourceARB als zweiten Parameter die anzahl der Strings haben.

Dort steht bei dir "1", sollte das nicht "5" sein? (5 einträge in buffer)

Wie gesagt, ich kann da auch nen Denk-/Verständnisfehler drinhaben.


PS: wie kann man sowas nur produktiv nutzen? Ist mir absolut unverständlich! :shock:

[EyDu]

Hallo und vielen Dank für die Antwort!

In "buffer" stehen keine fünf Elemente, sondern lediglich eins. Mit dem "\" am Ende kann man Strings über mehrere Zeilen zusammensetzen.

Zu der Frage zum produktiven Einsatz: Das wird eigentlich nur ein gruseliger Hack um etwas die Geschwindigkeit zu erhöhen. Ich kämpfe ein wenig mit 1,3 Mio Punkten pro Sekunde, die alle transformiert werden wollen. Eigentlich wäre OpenCL die saubere Lösung für das Problem, da das Projekt momentan jedoch auf gcc4.4 basiert und ich momentan nicht noch eine weiter Abhängigkeit schaffen will, ziehe ich für diese kleine Aufgabe erstmal 10 Zeilen Shader vor.

Sebastian

[Aramis]

Hash du mal probiert ob `glGetError´ was brauchbares von sich gibt? Bezweifle ich zwar, aber Hoffen ist erlaubt.

PS: wie kann man sowas nur produktiv nutzen? Ist mir absolut unverständlich!

Wieso nicht? Die 3D-API Calls machen in jeder ernsthaften Anwendung/Engine sowieso nur einen geringen Anteil aus, bzw. verschwinden hinter Wrappern. Das D3D-Interface ist auch nicht schöner, nur etwas einheitlicher.

[EyDu]

Hallo.

Hash du mal probiert ob `glGetError´ was brauchbares von sich gibt? Bezweifle ich zwar, aber Hoffen ist erlaubt.

Hmm, dass hätte ich wohl gleich erwähnen sollen :roll: Etwas brauchbares kommt leider nicht raus. Nach jedem der GL-Aufrufe liefert mir "glGetError" lediglich "GL_NO_ERROR".

Sebastian

[EyDu]

Argh, die Lösung war zu einfach: Zum Zeitpunkt des Aufrufs scheinen einige OpenGL-Dinge noch nicht richtig initialisiert gewesen zu sein. Warum das an der Stelle der Fall war muss ich noch einmal genauer analysieren.

Vielen Danke euch beiden für die schnelle Hilfe!

Viele Grüße
Sebastian

[Dirk Schulz]

okay,

nach weiterem suchen in den Spezifikationen, die nächste mögliche Fehlerquelle:

wenn der letzte Parameter von glShaderSourceARB NULL ist, dann soll der String 0-terminated sein. Scheint er bei dir aber nicht zu sein?!

also entweder als letzten Parameter &vertexShaderLength angeben, oder den String null-terminieren.

Aber kann mich auch wieder irren! ;)

@Aramis: Ja, wenn man erstmal ein passendes Framework hat, geht das wahrscheinlich, aber vorher scheints ne Qual zu sein:

- Hunderte Funktionen, die mit irgendwelchen Parametern ausgestattet möglicherweise eine passende Fehlermeldung ausspucken, anstatt einen einheitlichen Parameter anzugeben, der die Fehlermeldung speichert.
- Funktionen, die Objekte verändern, ohne dass man deklarieren kann, dass sie in einem neuen Objekt gespeichert werden sollen. (hab ich persönlich ne Abneigung gegen :) )
- allgemein das ganze Extension-Zeugs

edit: okay, scheint sich ja doch erledigt zu haben :D

[Aramis]

wenn der letzte Parameter von glShaderSourceARB NULL ist, dann soll der String 0-terminated sein. Scheint er bei dir aber nicht zu sein?!

C++ Stringliterale sind generell nullterminiert ("hoi"[3] ist '\0').

[Krishty]

Das D3D-Interface ist auch nicht schöner, nur etwas einheitlicher.

Vor allem aber konzentriert das D3D(10/11)-Interface alle für eine Renderstufe relevanten States in einer Struktur. Falls also eine Stufe unerwünschte Ergebnisse liefert, findest du den fehlerhaften Parameter mit an Sicherheit grenzender Wahrscheinlichkeit in eben jener Struktur.

Mit OpenGL hingegen musst du dann die Parameter von zwei Dutzend kaum durchschaubar wechselwirkenden Funktionsaufrufen prüfen.

D3D ist Frustration, OpenGL ist Frustration² ;)

Nochmal was @Topic: Kann man String-Literale über mehrere Zeilen nicht auch ohne Backslash verbinden? "1" "2" "3" müsste der Compiler doch z.B. auch zu "123" auflösen, wenn Zeilenumbrüche dazwischen liegen?

Gruß, Ky

[Dirk Schulz]

C++ Stringliterale sind generell nullterminiert ("hoi"[3] ist '\0').

Du hast natürlich recht! :)

Musste in letzter Zeit (für die Uni) zuviel mit Java programmieren, da vergisst man solche Sachen schonmal. :roll:

@Krishty: ja funktioniert.

[Aramis]

Ja, gemäß 2.13.4.

In translation phase 6 (lex.phases), adjacent narrow string literals are concatenated and adjacent wide string literals are concatenated. If a narrow string literal token is adjacent to a wide string literal token, the behavior is undefined

Die Tatsache dass Zeilenumbrüche dazwischen liegen ist irrelevant (weil translation phase).

[Ingrater]

Was eventuell auch interresant zu wissen ist, die meisten OpenGL Treiber machen beim "compilieren" nur einen groben Syntaxcheck und erst beim "Linken" passiert das eigentliche Compilieren und Linken gleichzeitig, erst dann tauchen eventuelle Fehler wirklich auf.