Názory k článku Pohled pod kapotu JVM – volání funkcí OpenGL s využitím knihovny SDLJava

Ahoj, v pohode, diky za tu zpetnou vazbu :)

Reknu to takto - Java 3D neni moc uspesna ve vsech pripadech, je moc hi-level napriklad pro tvorbu her, takze dnes existuje hned nekolik nastroju, jak z Javy volat OpenGL (a mozna i Direct3D, ale to neznam :). Dneska na to existuje nekolik knihoven, JOGL, LGJW a prave i SDLJava.

Ja tam aspon z meho pohledu vidim tu vyhodu, ze znalosti klasickeho APU OpenGL se tady daji skoro beze zbytku vyuzit, neni moc zapotrebi se ucit napriklad praci s grafem sceny apod. Takze podle me to ma smysl.

Jo a jestli je to v Jave - kdyz mam byt uplne uprimny, taky me to vetsinou nesedne, spis bych se snazil delat C/C++ + nejaka vazba treba na Luu, ale projekty psany v Jave + OpenGL existuji a nektere jsou i hoodne uspesne, takze proc vlastne ne (Minecraft asi neni zapotrebi zminovat).

V cem je OpenGL obskurni? Proc by se to nemelo delat v jave?

Jo ale tady to nedava moc smyslu nadavat na Javu. Kdyz si uvedomime, jak vypada nejaka jednodussi hra uvnitr, tak je to smycka, v niz se nacitaji vstupy, meni se stav hry na zaklade techto vstupu a provede se prekresleni sceny.

Povsimnete si, ze se nikde neprovadi zadne silene alokace pameti, protoze zmena stavu je zapis do nejakych atributu existujicich objektu, pripadne "nove" objekty se mohou brat z poolu atd. - tudiz zadny brutalni GC nehrozi, pokud programator neni prase samozrejme.

Pokud by ta hra byla psana (ted me nebijte :-) ve Swingu, bude obecne stat za nic, a to kvuli tomu, ze Swing na toto neni staveny, pouziva zbytecne moc vysokou uroven abstrakce nad real HW (slovo "lightweight" ma zde jiny vyznam), bezi ve vlastnich vlaknech, takze u slozitejsi aplikace uz nikdo nevi, kdy a proc synchronizovat :) a gfx. hardware pouziva jen na naktere operace.

Ovsem s SDLJava + OpenGL jsme nekde jinde, v Jave zustane logika hry, zbytek je v nativni knihovne a/nebo na akceleratoru. Nejaky uplne zasadni rozdil oproti hre psane v C/C++ s embedovanym jazykem tady uz neni, opet za predpokladu ze programator nedela silenosti s alokaci pameti (ale k tomu obecne v techto pripadech nema zadny duvod).

Takze - grafika v Jave muze byt pomala a malo responzivni v pripade Swingu, ale to se uz zda se nezmeni, protoze Sun na to kaslal a Oracle na to kasle 2x (porad si mysli, ze prorazi s javafx, ale hmm... no uvidime). Pokud se spoji vyhody JVM s OpenGL, tak ty problemy odpadaji, kupodivu i na starsim HW (Athlon 800 a 512 MB RAM je moje domaci masina :-/).

Ten swing (nebo AWT?) me onehda prijemne prekvapil. Delal jsem nejake hracickove demo, radove neco pres 1000 linii, rotovaly ve 3D. Rucne jsem to promital a kreslil na Graphics2D a k memu prekvapeni to evidentne jelo akcelerovane (pres OpenGL?), protoze to delalo az 1000fps. Kdyz jsem to same napsal v C#, tak to delalo asi 40fps.

Taky jsem delal zobrazovadlo nejaky 2D mapy se zoomem a vyberem, asi 1000 objektu s popiskama se na tom hybalo a taky to fungovalo bez problemu.

Takze pokud neni potreba vykreslovat nejaky rozsahly 3D sceny a neni vylozene nutnost jet ve vlastnim vlakne a mit vlastni rizeni, tak myslim, ze ten swing bude dost dobrej.

Z Javy se dá volat i Open CL - JOCL. Ideální pro naprogramování HW akcelerovaného softwarového 3D rendereru :)
Umí SDLko i OCL? Že by to bylo všecko v jednom.