Autor Wątek: [c++] Opengl opakowany w obiekty, czy warto?  (Przeczytany 39542 razy)

Offline Q

  • Użytkownik

# Luty 17, 2014, 00:39:26
Witam.
Jakiś czas temu miałem do czynienia z biblioteką threejs. Teraz gdy zacząłem bawić się opengl postanowiłem upodobnić mój kod do tej biblioteki. Niestety trudno jest mi wpisać funkcję w obiekty.
Np. obecnie nie wiem jak poradzić sobie z funkcja Display() która wywoływana jest w  glutDisplayFunc( Display ).
Bo chciałbym by mogła się posługiwać metodami i właściwościami głównego obiektu w którym jest zawarta.
Głownie chce opanować tą chmarę funkcji, wprowadzić ład. I sprawić by łatwo pisało się aplikacje tego typu początkującym.
Ale pomijając aspekt techniczny czy warto się w to bawić, czy to wykonalne oraz czy ktoś podejmował już takie wysiłki?
« Ostatnia zmiana: Luty 17, 2014, 00:45:13 wysłana przez Q »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline JasonVoorhees

  • Użytkownik
    • FotoGry

  • +1
# Luty 17, 2014, 10:15:30
Nie jeden przed Tobą robił takie rzeczy ;) Jakiś famework, nakładki opakowujące funkcje OpenGL'owe.

Tutaj jest poruszony problem, który napotkałeś: http://stackoverflow.com/questions/3589422/using-opengl-glutdisplayfunc-within-class

Swoją drogą nie widzę sensu opierać swojego frameworka o glut. SDL do OpenGL byłby lepszym wyborem. Tam nie ma funkcji glutDisplayFunc :)


Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 17, 2014, 11:21:54
Cytuj
Swoją drogą nie widzę sensu opierać swojego frameworka o glut. SDL do OpenGL byłby lepszym wyborem. Tam nie ma funkcji glutDisplayFunc :)
Ja bym nie radził opierać frameworka OpenGL o cokolwiek niezwiązanego z OpenGL. W ten sposób możesz framework łatwiej reusować w przyszłości.

Ja w swoim frameworku mam klasę Device, która ma parę metod do wołania "z zewnatrz" jak:
- Init - do wywołania za każdym razem jak mamy nowy kontekst OpenGL,
- ContextLost - do wywołania jak chcemy posprzątać (nie trzeba jeżeli za chwilę wołamy Init),
- BeginFrame - start ramki,
- EndFrame - koniec ramki

Powyższe pozwoliło bez większych problemów wpiąć ten framework w przykładowe aplikacje na Androidzie, BlackBerry, a nawet we framework kolegi przy wspólnym projekcie.

Offline ArekBal

  • Użytkownik

# Luty 17, 2014, 11:32:21
Pomijając różne opinie, podejścia oto jeden ze sposobów na opakowanie takiego delegata. Szczegóły są do dopięcia przez ciebie.
class GraphicsDevice
{
virtual void OnDraw()
{
}
...
glutDisplayFunc([]() { OnDraw(); });
...
};
Mój "GraphicsDevice" ma blisko do D3D GraphicsDevice.

Jest esencją SRP... robi wszystko... tworzy, przypisuje deklaracje, bufory wierzchołków, shadery i steruje ustawieniami. oczywiście z pomocą masy klas pomocniczych, chociażby VertexBuffer, VertexDeclaration, VertexElement, VertexShader, PixelShader.
« Ostatnia zmiana: Luty 17, 2014, 11:38:13 wysłana przez ArekBal »

Offline Dab

  • Redaktor
    • blog

  • +2
# Luty 17, 2014, 11:39:45
glutDisplayFunc([this] { OnDraw(); });

Od kiedy glutDisplayFunc przyjmuje jako parametr std::function? Lambda może zostać zrzutowana na gołą funkcję tylko jeżeli nie przechwytuje żadnych obiektów z kontekstu.

Offline ArekBal

  • Użytkownik

# Luty 17, 2014, 11:44:01
Dlatego "szczegóły" zostawiłem dla Q.

A kod poprawiłem na zagadkę zanim odpisałeś.

EDIT: "self" czy "that" można (lub nie można zależy jak masz poukładane)wyciągnąć tą samą drogą jaką wyciągasz z uchwytu do okna. W tym scenariuszu mając metodę typu GetWindowFromHandle
należy ją tu wywołać, zrzutować na GLWindow czy coś w ten deseń i wywołać OnDraw na GraphicsDevice.
Alternatywa to po prostu static member trzymający this (ale to tylko pozwoli ci trzymać jedno okno).
Altrnatywa 2 to static map z this;
« Ostatnia zmiana: Luty 17, 2014, 12:06:54 wysłana przez ArekBal »

Offline Dab

  • Redaktor
    • blog

# Luty 17, 2014, 13:47:07
Spoko, to pewnie miał być tylko poglądowy kod, ale...

Cytuj
A kod poprawiłem na zagadkę zanim odpisałeś.

...jest jeszcze gorzej, bo this nie jest niejawnie przechwytywane przy tworzeniu lambdy (a nawet gdyby było, to: patrz uwaga z poprzedniego posta).

Offline ArekBal

  • Użytkownik

# Luty 17, 2014, 13:52:01
Wiem przecież!?! :D

Dlatego dopisałem to wszystko też chwilę temu w poprzednim poście.

Offline Q

  • Użytkownik

# Luty 17, 2014, 14:28:19
Cytuj
Ja bym nie radził opierać frameworka OpenGL o cokolwiek niezwiązanego z OpenGL
Na razie operam sie na glut -cie bo wiele tutoriali opiera sie na nim. A jako że jestem świerzy w temacie wole mieć gdzie spojrzeć po podpowiedź. Frameworker może udostepniać kilka bibliotek w tym glut-a, sdl czy wlasną. Oczywiście to kilkakrotnie wiecej pisania ale daje też wiecej możliwości.

Na glut -cie (nie wiem czy tak to sie odmienia) nie bedzie mi działało w androidzie?

Dzięki za ten kod, wypróbuje go jak bede w domu (za 2 dni)
« Ostatnia zmiana: Luty 17, 2014, 14:41:04 wysłana przez Q »

Offline JasonVoorhees

  • Użytkownik
    • FotoGry

# Luty 17, 2014, 15:03:51
Ogólnie jak celujesz w androida, to lepiej byłoby skorzystać z Javy + np. LibGDX - http://www.gamedev.pl/txt/wstep-do-libgdx

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 17, 2014, 15:13:27
Ogólnie jak celujesz w androida, to lepiej byłoby skorzystać z Javy + np. LibGDX - http://www.gamedev.pl/txt/wstep-do-libgdx
Taak... a potem weź to zportuj na iOS. ;)

Offline JasonVoorhees

  • Użytkownik
    • FotoGry

# Luty 17, 2014, 15:38:17
To niech weźmie inną bibliotekę, która wspiera wszystkie/większość platform docelowych :)

Offline Xender

  • Użytkownik

  • +3
# Luty 17, 2014, 16:17:35
Ja bym nie radził opierać frameworka OpenGL o cokolwiek niezwiązanego z OpenGL. W ten sposób możesz framework łatwiej reusować w przyszłości.

Ja w swoim frameworku mam klasę Device, która ma parę metod do wołania "z zewnatrz" jak:
- Init - do wywołania za każdym razem jak mamy nowy kontekst OpenGL,
- ContextLost - do wywołania jak chcemy posprzątać (nie trzeba jeżeli za chwilę wołamy Init),
- BeginFrame - start ramki,
- EndFrame - koniec ramki

Powyższe pozwoliło bez większych problemów wpiąć ten framework w przykładowe aplikacje na Androidzie, BlackBerry, a nawet we framework kolegi przy wspólnym projekcie.
Zacznijmy od tego, że SDL 2 czy GLFW z definicji są związane z GL. SDL 2 chodzi na GL, GLFW to pomocnicza libka dedykowana do GL.

Super, skoro już to naklepałeś, to możesz podzielić się tym frameworkiem, zamiast dawać dobre rady "nie używaj gotowych rozwiązań, napisz sam".

Obsługa kontekstu OpenGL na różnych platformach to PITA, zwłaszcza, jeśli chcesz to opakować w przenośny interfejs i nie wiesz, jak się za to zabrać (a jeśli nie korzystałeś z takiego interfejsu (jakim są SDL 2 czy GLFW), to nie wiesz, jak powinien wyglądać).

Ponadto odnoszę wrażenie, że OP chce pisać w GL, a nie pisać pomocniczą libke do GL, zanim cokolwiek zrobi.

SDL 2 jest multiplatformowe. GLFW też. Obsługują najważniejsze platformy OOTB. I są Open Source - jak OP będzie potrzebował odpalić swoją grę na innej platformie, to wystarczy, że dorobi backend do SDL/GLFW dla niej. I będzie musiał naklepać tylko to, co potrzebuje dla danej platformy, a nie cały framework od zera.

Rozumiem, że masz syndrom NIH, ale proszę, nie zarażaj tym innych.



Co do GLUT - AFAIK jest przestarzałe. Tutorial możesz zmienić, albo po prostu zastąpić wywołania GLUT tymi z GLFW lub SDL 2.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Luty 17, 2014, 16:59:51
Cytuj
Super, skoro już to naklepałeś, to możesz podzielić się tym frameworkiem, zamiast dawać dobre rady "nie używaj gotowych rozwiązań, napisz sam".
Autor wątku pytał się o opakowywanie, więc zakładam, że chce coś takiego napisać samemu.


Co do podzielenia się, to brak jakiejkolwiek dokumentacji d mojego frameworka raczej nie jest zachęcającą rzeczą. :)

Cytuj
Ponadto odnoszę wrażenie, że OP chce pisać w GL, a nie pisać pomocniczą libke do GL, zanim cokolwiek zrobi.
W takim przypadku nie pytał by, jak GL owinąć.

Cytuj
Rozumiem, że masz syndrom NIH, ale proszę, nie zarażaj tym innych.
Nie tyle NIH, co trudności ze znalezieniem czegoś, co by mi odpowiadało. A przeglądałem tego sporo.

Offline Xender

  • Użytkownik

# Luty 17, 2014, 19:57:04
Od kiedy glutDisplayFunc przyjmuje jako parametr std::function? Lambda może zostać zrzutowana na gołą funkcję tylko jeżeli nie przechwytuje żadnych obiektów z kontekstu.
Tak przy okazji, to typ lambdy jest implementation defined. Przyjmowanie jest przez parametr szablonowy może być bardziej wydajne, niż przez std::function.