2011-12-16 12 views
8

Określenie wersji GLSL powoduje błąd składni podczas korzystania z LWJGL. Nie próbowałem odtworzyć tego problemu poza LWJGL. Dzieje się to na wielu komputerach Mac z systemem Lion.GLSL #version daje błąd składni (LWJGL na komputerze Mac)

Dostałem zarówno shaderów wierzchołków i fragmentów do pracy bez użycia #version. Ale zamierzam użyć funkcji texture, która wydaje się wymagać dyrektywy #version.

Oto najprostszy braku przykład:

#version 120 

void main() { 
    gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0); 
} 

Kompilacja Ten fragment shader i nazywając glGetShaderInfoLog daje ten błąd:

ERROR: 0:1: '' : syntax error #version 

Wymiana 120 z niczym innym, jak 110, daje również błąd. Co ciekawe, jeśli używam 130 lub więcej, daje to ten sam błąd plus skargę na temat wersji, która nie jest obsługiwana. (Wiem, że mój system nie ma GLSL 1.3, ale nadal jest dziwne, że ten błąd jest wyświetlany, gdy kompilator działa tak, jakby nie rozumiał znacznika wersji.)

Jestem na komputerze Mac z kartą ATI Radeon HD 4670. GL_VERSION to 2.1 ATI-7.12.9 i GL_SHADING_LANGUAGE_VERSION jest 1.20.

Biorąc to pod uwagę, nie widzę żadnego powodu, dla którego GLSL 1.20 powinien być niedostępny. I naprawdę dziwne jest dla mnie twierdzenie, że #version jest błędem składni, w przeciwieństwie do wypowiedzenia czegoś na temat nieobsługiwanej wersji GLSL.

+0

Gdzie jest twój kod ładujący modułu cieniującego? –

+0

Mogę wkleić, że raz mam internet. (Korzystając teraz z mojego telefonu.) Czy kod źródłowy thab byłby pomocny? – rlkw1024

Odpowiedz

17

Rozwiązany! Nie miało to nic wspólnego z OpenGL. Mój kod czytnika plików zrzucał wszystkie podziały wierszy. To było w porządku w cieniu modułu cieniującego, który miał średniki. Jednak dyrektywa preprocesora nie zawierała średnika chroniącego go przed tym błędem.

Tak dla każdego, kto ma ten problem, upewnij się, że kod, który faktycznie przekazujesz do glShaderSource, nadal ma swoje linebreaki.

+1

Wielkie dzięki, uratowałeś moją noc! Jestem na Macu z SDL i C++, ale z tym niejasnym komunikatem o błędzie OpenGL próbował mi powiedzieć to samo. – zubko

+0

Sposób podejścia do tego można znaleźć [tutaj] (http://schabby.de/opengl-shader-example/).BufferedReader ściąga źródło cieniowania po linii, odrzucając znaki CR/LF. Następnie jawnie powraca się znak nowego wiersza do każdej linii za pomocą StringBuilder (patrz około 2/3 drogi w dół tej strony). –

+0

Wielkie dzięki. To był dokładny problem, który miałem. Pesky Java IO usuwa podział linii! – Textfield

1

Zarówno shader wierzchołków, jak i fragmentów muszą mieć tę samą wersję. Więc jeśli dodasz #version 120 do shadera fragmentów, powinieneś również dodać go do vertex shadera. Ale to trochę dziwne, że jest to zgłaszane jako błąd składni. Być może jest inny błąd, ale oba muszą mieć ten sam tag wersji.

EDIT: Należy także pamiętać, że znacznik wersja musi być w pierwszej linii w kodzie źródłowym modułu cieniującego (nowe linie i komentarze powinny być OK przez specyfikację, ale kto wie, jakie sterowniki myślę).

+0

Próbowałem używać tej samej wersji w obu, ale bez powodzenia. Ponieważ dzieje się to w kompilacji, a nie w łączeniu, nie sądzę, że shadery i tak wiedzą o sobie nawzajem. – rlkw1024

+0

@Jarrett Biorąc pod uwagę złowieszczy dostawca karty graficznej, może to być również błąd sterownika. Chociaż jest to naprawdę bardzo prosta funkcja i nie powinno być problemu z obsługą, ale z drugiej strony nadal jest to ATI. –

+0

I rzeczywiście sprawdziłem ten sam problem z GeForce 320M. Tak więc zaczynam wątpić, że obaj dostawcy mają dokładnie taki sam błąd w podstawowej funkcji. – rlkw1024

Powiązane problemy