☰ Menu

Scene.hu

Magyar demoscene portál – grafikusok, zenészek, programozók alkotói közössége

Viewing 22 posts - 31 through 52 (of 52 total)
  • Author
    Posts
  • #21152
    avatarrawbits
    Member

    Bocsi, én is csak magamból indulok ki. Ez a linuxos izé nekem kínai és még bonyolultnak is tűnik.

    Én úgy kezdtem, hogy az opengl.org-on a Getting started with OpenGL-re kattintottam és elolvastam ami ott van, kiválasztottam ránézésre szimpátia alapján a GLFW-t meg a GLEW-t. Letöltöttem, elolvastam a használatukat, kijavítottam a hibákat a headerekben és konvertáltam a lib-eket (Borland C++ command line tools), majd a GLFW és GLEW dokumentáció alapján nyitottam egy ablakot.

    Ezután megörültem, hogy nem nehéz ez, és kerestem tutoriálokat. Ezek használati sorrendben:
    Swiftless
    Lazy Foo’ Productions
    NeHe Productions

    Az nem zavar, hogy nem használja senki a GLFW/GLEW kombót, mert nagyon jól dokumentáltak és egy egyszerű motort azért csak össze tudok talán rakni… Az viszont igen, hogy sehol nincs egy jó összehasonlító cikk az OpenGL 2.1 és 3.x/4.x között. Azt mondják nem is hasonlít. Hát szerintem ugyanazt írják a 4.x-es tutoriálok is.

    Mindenesetre az én Intel-em csak a 2.1-et ismeri úgyhogy egyenlőre ez nem okoz gondot. :)

    #21156
    avatarArtlace
    Member

    En ugy tapasztaltam (szinten magambol kiindulva) hogy a legtobb OpenGL program mukodik a verziok kozott, csak 3.x felett mar sok funkcio “deprecated” es azon felul mar el is van tavolitva par de compatibility modban meg mindig lehet regebbi programokat futtatni.
    Ami igazan nagy tores volt nekem az az OpenGL ES (iOS es hasonlok) mert ott tenyleg elhagytak sokmindent. Nalam a NeHe volt az etalon es oda is megyek meg most is vissza sokszor.

    #21159
    avatarkt
    Member

    Ez a visszafelé kompatibilitás nagyon jó ötlet.
    OGL4.1-től bejött az ARB_separate_shader_objects (ami pl. 3.3-ban is használható), ezzel pár OGL hivásból be lehet lőni vs/fs shadert. A kompatibilitás miatt még a glRect-et is tudod használni, igy nem kell bufferekkel bajlódnod egy sima fullscreen quad-hoz.
    Mutatok .
    Egyszerű és rövid is. :D

    #21160
    avatarkt
    Member

    Elizéltem a linket sikeresen. :D
    Nem lehet szerkeszteni hozzászólást?

    #21253
    avatarArtlace
    Member

    Ez kicsit offtopic ugyan, de most volt kalandom OpenGL ES-el. En kis naiv azt hittem hogy az OpenGL ES 2.0 az vigan kompatibilis lefele az OpenGL ES 1.1-el (Ez iOS 4.x es iOS 5.verziok) es pofara estem, rogton ketszer.

    Eloszor azert, mert OpenGL ES nem tudja mi az a GL_QUADS. Semmi gond mert tenyleg csak lustasag vesz ra hogy quad-okat hasznaljak.
    Viszont ES 2.x-ben mar mindent shaderbol nyom es semmi fixed pipeline nincs. Kompatibilitas innentol mar alig van.

    #21384
    avatarMurphy
    Member

    És nincs valami külső opensource cucc ami lewrappeli amit csak lehet?

    Mert egyrészt baromi jó, hogy kidobták a sok múltszázadi sallangot, másrészt azért van amikor gyorsan kellene valamit átrakni végeredmény optimális megvalósítása kevésbé szempont.

    #21411
    avatardarklon
    Member

    iOS5-on a GLKit framework elvileg valami ilyesmire van. Kérdés, hogy hajlandó -e az ember ilyen Apple specifikus library-t használni.

    #21966
    avatarMurphy
    Member

    Most volt alkalmam kicsit opengl-ezni, és dx után nagyon jajj…

    #22037
    avatarkt
    Member

    Miért? :)

    #22040
    avatarMurphy
    Member

    Kb minden témában sokkal modernebb a d3d, főleg egy 10-11-es. Nem azért mert ők sokkal okosabbak, hanem mert időről időre merték újragondolni, és nem ragaszkodtak egy 1992-ben még jó ötletnek tűnő, időközben meglehetősen idejétmúlt koncepcióhoz…

    A felépítés úgy unblock szintekkel jobb d3d-ben, mert meglehetősen béna dolog a tonna függvény, főleg mikor ezek egy része csak és kizárólag azért kell, hogy a régi, visszafelé kompatibilitásból fakadó api és belső hiányosságokat elfedjék. (Bindolások, csak, hogy módosíthass egy resource-ot, nye…)
    Az alap resource kezelés úgy ahogy van totális lúzerség. A resource ID-k teljesen transparensek, símán növekvő számok amik nem tartalmazzák a resource típusát, ennek folyományaként minden resource típusnak saját felszabadító függény kell, nagyszerű hibalehetőségek tárházát nyújtva ezzel. Épp ezért besetelni is ezernyi hülyeséget tudsz, de legalább a hiba outputok alapból kínosan szűkösek. Az enumok helyetti define-ok használata is kiváló hibalahetőség, meg úgy általában az egész api tele van régen jó ötletnek tűnő, és azóta úgymaradt dolgokkal.

    Mennyire egyszerű és logikus, hogy a D3D-ben vannnak create és set és get és draw függvények, és ezzel mindent meg tudsz csinálni… Ehhez képest opengl-ben még egy egységes naming convention sincs amivel az adott resource-ra vonatkozó függvényeket legalább egyben tartanák…

    • This reply was modified 8 years, 6 months ago by avatarMurphy.
    #22054
    avatarTravis
    Member

    Murphy: Azt azért ne felejtsd el, hogy OpenGL-nek nem csak C++-ban, hanem egy rakás más programnyelven is futni kell. Egy nem objektum orientált programozási nyelvben maximum stringeket tudsz használni, ha az erőforrás típusát is le akarod írni.

    Ugyan ezen oknál fogva van több felszabadító függvény is.

    Egyébként megfigyelhető bizonyos konvergencia. A 2.1-ben még külön függvényekkel kellett vertex arrayt, textúra arrayt, stb létrehozni, de a 3.0-tól már ezeket összevonták. Shaderből kell megmondani, hogy mire akarod használni az arrayt.

    #22056
    avatarMurphy
    Member

    Tekintve, hogy semmilyen resource-ból nem lesz 3 milliónál több darab lekreálva, a felső 5 bit pl. tökéletes megoldás lehetne a resource típusának tárolására. Ez nagyon minimális átalakítás lenne a jelenlegihez képest, de pl. a struktúra elég alap c eszköz, ami már a lehetőségek végtelen tárházát nyitná meg a fejlesztők előtt… ;)

    • This reply was modified 8 years, 6 months ago by avatarMurphy.
    #22060
    avatarkt
    Member

    Én évekig OpenGL-eztem, hc fannak is tartom magam, de nem olyan régen bepillantottam DX10-be (7-8-9-essel is foglalkoztam régebben, alap szinteken), és teljesen beleszerettem az egészbe. Modern felépités, logikus meg minden. Mellette az OGL tényleg egy ókori valami sok szempontból.
    De nem tudok mit tenni, a szivem mindig visszahúz OpenGL-hez. :D

    #22063
    avatarTravis
    Member

    Murphy: Mennyire lenne ez jövő álló? Mi lesz, ha elfogy az 5 bit, mert felszaporodnak az erőforrás típusok? Hogyan őrzik meg a visszafelé kompatibilitást? A struktúra már sokkal jobb megoldás lenne, bár nem tudom, Haskellben akkor hogyan írna demót Blala :-)

    Egyébként a Microsoft könnyebb helyzetben van, mert nem kell senkire sem tekintettel lennie. Ha holnaptól úgy döntenek, hogy csak C#-ban lehet DX progikat írni, akkor senki nem tehet ellene semmit (erősen sarkított példa, tudom). OpenGL azért van telefonon, PC-n, Mac-en, újgenerációs Amigákon. Itt nem olyan könnyű drasztikus változásokat hozni.

    #22064
    avatarMurphy
    Member

    Az 5 bit helyett akár 8 bit is lehet, gyanítom resource típusonként a 16 millió darab se fog a közeljövőben elfogyni. Haskell-t nem ismerem, de gyanítom tetszőleges adatszerkezettel megoldható lenne akár ott is az opengl binding.

    Egyébként a Microsoftnak más miatt van könnyebb dolga, időnként azt mondják, hogy oké, új verzió, ami nem akar görcsösen kompatibilis maradni a korábbiakkal…
    A fejlesztő mikor jónak látja átáll az újra, cserébe utána sokkal boldogabb lesz az élete.

    #22065
    avatarGargaj
    Member

    A felépítés úgy unblock szintekkel jobb

    Na itt ledobta az agyam a szijat :D

    #22066
    avatarTravis
    Member

    Windowsban legalább van választási lehetőség. Nekem Linux alatt nincs.

    #22067
    avatarMurphy
    Member

    Travis: Igen, ez zavar engem is…

    Gargaj: halljuk az ellenérveket ;)

    #22068
    avatarGargaj
    Member
    #22069
    avatarMurphy
    Member

    Jahogy ja :)

    #22070
    avatarBery
    Member

    unblock-al arra utalt Murphy, hogyha a nem tömbként tekintünk, mi kockák a dologra, akkor is jobb a DX ;)

    • This reply was modified 8 years, 6 months ago by avatarBery.
    #22164
    avatarArtlace
    Member

    Megszakitva a sort, de itt egy elegge objektiv es jo doksi:

    http://www.arcsynthesis.org/gltut/index.html

    GLKit egyebkent annak az eletet konnyiti meg aki fosik a GLES 2-tol meg attol hogy semmi fixed pipeline nincs mar. Peldaul az enyemet.

Viewing 22 posts - 31 through 52 (of 52 total)
  • You must be logged in to reply to this topic.
Ugrás a lap tetejére Ugrás a lap aljára