Ubuntu.pl 🇺🇦️ - Forum Ubuntu

Od razu do rzeczy. Od niedawna uczę się openGL z nehe. przeszedłem do lekcji 6.. tam jest o teksturach blablabla... wszystko pod window$. Tak więc postanowiłem że wczytywanie zrobię za pomocą soila. Mam małą klasę (tekstura i siatka). W niej funkcja wczytująca teksturę: Wszystko kompiluje się jak powinno. Uruchamia się ... tekstur nie ma, a w terminalu napis:

nie można odczytać tekstury: texture.png.

Tekstura jest zadeklarowana tak Plik texture.png istnieje na 100%(w katalogu dist/Release/GNU-Linux-x86 i dist/Debug/GNU-Linux-x86). Ide z którego korzystam to NetBeans.

Użyj debuggera i zobacz co się dzieje

Nigdy nie używałem SOIL (DevIL czy Freeimage tak), ale to wygląda tak jakby nie istniał plik texture.png... wiem wiem jest tam gdzie plik wykonywalny, ale Linux to nie windows i nie ważne jest gdzie jest plik wykonywalny w adresach względnych tylko aktualny katalog (pewnie masz ustawione w projekcie, że program jest uruchamiany z katalogu projektu, a nie w miejscu gdzie wrzuca plik binarny (czyli plik texture.png powinien być w katalogu projektu, a nie w dist/Release/GNU-Linux-x86)).
Najłatwiej możesz sprawdzić czy plik texture.png istnieje sprawdzając czy plik da się otworzyć za pomocą fopen (jak nie to znaczy, że pliku nie ma tam gdzie potrzebujesz). Ewentualnie możesz w konsoli wejść do dist/Release/GNU-Linux-x86 i uruchomić z tego miejsca plik wykonywalny (powinno działać wtedy).
Jak to nie to to pozostaje Ci debugger lub debugger OpenGL (jak gDEBugger).

O ty patrz pan.. wchodzę w folder z programem, ./program, i... kochane segmentation fault. Najprawdopodobniej miełeś rację i program uruchamiał się z innego katalogu. Segmentation fault to już pewnie wina mojej słabej znajomości openGL. Na wszelki wypadek zostawię wątek i jak coś to jeszcze zapytam.

EDIT:
no i wątek dalej żyje. Problem jest dalej w tym samym miejscu(sprawdziłem debuggerem). Teraz jestem w 100% pewien że widzi plik(zmieniłem ścieżkę do uruchamiania).

pixelenter pisze:O ty patrz pan.. wchodzę w folder z programem, ./program, i... kochane segmentation fault. Najprawdopodobniej miełeś rację i program uruchamiał się z innego katalogu. Segmentation fault to już pewnie wina mojej słabej znajomości openGL. Na wszelki wypadek zostawię wątek i jak coś to jeszcze zapytam.

Segmentation fault to mało prawdopodobne, że przez słabą znajomość OpenGL (ten nie wyrzuca takich błędów - po prostu wyrzuci Ci program bez błędu ;p)... no chyba, że przekazałeś np. glBufferData jako drugi parametr większą liczbę niż rozmiar tablicy przekazanej w trzecim, ale zapewne powodem jest jakiś wyciek pamięci/naruszenie ochrony pamięci w zupełnie innej części kodu - sprawdź debuggerem gdzie się kończy działanie programu (w tej linijce masz błąd ;p).

Polecam przeczytać też częste błędy http://www.opengl.org/wiki/Common_Mistakes (części z nich możesz nie uświadczyć, a na kartach innej firmy wywali program - np. pkt 5 działa na nVidii, a na Ati wywali aplikację).

Swoją drogą jak masz często Segmentation fault (skoro tak bardzo kochasz to możliwe ;p) to może zmienisz IDE na Eclipse + LinuxTools (w linux tools, masz integrację z Valgrind (masz też oprofile i inne swietne rzeczy, ale teraz nie o tym ;p), który jest bezcenną aplikacją ;p)? Jeśli nie to użyj jakiegoś zewnętrznego Gui do Valgrinda.

BTW jeśli masz nową kartę (obsługującą OpenGL 4.1) to radzę zaprzyjaźnić się z rozszerzeniem GL_ARB_debug_output - jeśli nie to zaprzyjaźnij się z glGetError.

pixelenter pisze: EDIT:
no i wątek dalej żyje. Problem jest dalej w tym samym miejscu(sprawdziłem debuggerem). Teraz jestem w 100% pewien że widzi plik(zmieniłem ścieżkę do uruchamiania).

Pokaż linijkę, w której wywala się program (jeśli w SOIL_load_OGL_texture to albo coś jest nie tak z biblioteką, albo jakieś flagi nie są kompatybilne z png (nie znam biblioteki - strzelam ;p)).

Program zatrzymuje się w linijce z SOIL_load_OGL_texture, flagi są dobrze, raz nawet sprawdziłem tak jak było na ich stronie. Jednak błąd ciągle ten sam. Błąd pewnie spowodowany przez soil, ale właśnie nie wiem gdzie. Jak nic nie pomoże to spróbuję z devilem, ale na razie jeszcze pobabram się z soilem.

pixelenter pisze:Program zatrzymuje się w linijce z SOIL_load_OGL_texture, flagi są dobrze, raz nawet sprawdziłem tak jak było na ich stronie. Jednak błąd ciągle ten sam. Błąd pewnie spowodowany przez soil, ale właśnie nie wiem gdzie. Jak nic nie pomoże to spróbuję z devilem, ale na razie jeszcze pobabram się z soilem.

Jeśli masz SOIL zbudowaną jako debug to możesz wejść do SOIL_load_OGL_texture w debuggerze i sprawdzić która linia w którym pliku SOIL powoduje błąd (i albo poprawić, albo wywnioskować z tego ze złe dane dostaje ;p).

Problem dotyczy najprawdopodobniej nie tylko png, bo zapisałem też jako bmp, i też jest błąd. Nie wiem może wybrać co innego?

pixelenter pisze:Problem dotyczy najprawdopodobniej nie tylko png, bo zapisałem też jako bmp, i też jest błąd. Nie wiem może wybrać co innego?

Ja dążyłbym do rozwiązania zagadki (czy to Twoja wina czy biblioteki ;p) i debuggował bibliotekę ;p - więcej niestety nie mogę pomóc (nie znam tej biblioteki).
Co do przejścia na DevIL czy FreeImage to raczej wybór jest osobistą kwestią (jakie api wolisz i jaką licencję) - pamiętaj tylko jeśli piszesz w OpenGL 3+ i nie chcesz mieć profilu kompatybilności (rzeczy które wyleciały z nowych OpenGL względem 2.1 zostały wrzucone do tego profilu) to nie używaj funkcji zaczynających się od ilut (wystarczą Ci same funkcje il*, a dane łatwo już prześlesz do karty graficznej za pomocą api OpenGL).

jak już pisałem jestem na początku nehe, więc nie mów mi o jakiś ilutach i ilah bo cię nie kumam Nie chcę robić zarąbistych efektów graficznych, bo moja karta jest z intela i może ich nie pociągnąć. Co do soila, jeżeli biblioteka zawiera błąd(a tak pewnie jest), to ja nie jestem od tego aby ją poprawiać. Od tego są ludzie którym naprawę SIĘ CHCE. A mi się nie chce i wolę poszukać alternatywa . Tak więc oto stawiam na devila(ze względu na licencję), oraz zamykam temat

pixelenter pisze:jak już pisałem jestem na początku nehe, więc nie mów mi o jakiś ilutach i ilah bo cię nie kumam

Ilut z nehe nie ma nic wspólnego - to część DevIL, który nie bez powodu dawniej nazywał się OpenIL, bo zarówno Api jak i biblioteki ma podobne do OpenGL i tak np.:

- jest biblioteka główna, która daje dostęp do wszystkiego (funkcje rozpoczynają się od gl/al/il w OpenGL, OpenAL, DevIL),

- jest biblioteka pomocnicza (np. OpenGL Utility) GLU/ALU/ILU dodająca rzeczy które się przydają często, a co nie należy do głównej części biblioteki (w OpenGL to nie jest wykonywane na GPU, tylko na procku i np. funkcja gluLookAt czy gluPerspective ustawia macierz projekcji, ale można się obyć bez tych funkcji i napisać własne, lub użyć jakiejś implementacji gotowej jak glm czy cml (nawet lepiej wymienić to co jest w GLU na inne bo jest mało wygodne, małe możliwości i stosunkowo wolne) - w OpenGL 3.x nie ma już glut i glu).

- jest biblioteka rozszerzająca tą pomoc czyli OpenGL Utility Toolkit (GLUT - w wypadku OpenAL i DevIL jest to właśnie ALUT i ILUT). GLUT dodaje możliwość tworzenia wieloplatformowych okien i obsługę klawiatury/myszy (z tym, że jest to słabe api i dodatkowo jest wiele lepszych bibliotek, dających dużo więcej możliwości), ALUT tak samo nie daje nic poza obsługą wav (których i tak nikt nie chce używać - po prostu lepsze są OGG i ALUT jest zbędne). ILUT to takie rozszerzenie do DevIL dodające np. funkcję robienia screenshotów z OpenGL, czy tworzenia tekstur OpenGL (nie musisz korzystać z Api OpenGL do załadowania tekstury tylko jedna funkcja robi to za Ciebie... ale często i tak lepiej załadować samodzielnie (zamiast jednej funkcji, piszesz kilka linijek z funkcjami rozpoczynającymi się od gl (ładujesz za pomocą funkcji il* obrazek, i przekazujesz do gl*))).

pixelenter pisze:Nie chcę robić zarąbistych efektów graficznych, bo moja karta jest z intela i może ich nie pociągnąć.

Jak masz kartę intela to masz problem z głowy (obsługują max OpenGL 2.1) - ale i tak IMO nie warto korzystać z ILUT - lepiej pisać tak jakbyś pisał pod nowe GL... mój silnik w zależności od możliwości karty korzysta z kontekstu od 2.1 do 4.1 i udostępnia mi funkcje (bezpośredni dostęp do próbek AA w shaderach (GL3.2 - w Dx od 10.1), czy tesselacja w 4.0) - radze Ci pisać tak samo, żeby w wypadku jakbyś chciał użyć czegoś z nowszych OpenGL w przyszłości nie musiał modyfikować już istniejącego kodu, tylko łatwo dodać nowe rzeczy (ale to tylko rada - rób jak chesz).
Nowe karty Intela (Sandy Bridge), mają obsługiwać już OpenGL 4.0 i OpenCL 1.1.

pixelenter pisze:Co do soila, jeżeli biblioteka zawiera błąd(a tak pewnie jest), to ja nie jestem od tego aby ją poprawiać. Od tego są ludzie którym naprawę SIĘ CHCE. A mi się nie chce i wolę poszukać alternatywa . Tak więc oto stawiam na devila(ze względu na licencję), oraz zamykam temat

Ja Ci nie każę naprawiać - dobrze tylko wiedzieć gdzie jest błąd i ja wolę prześledzić to.