Olvastam a fragment shader ről.
Azt olvastam róla,hogy a pixelek pozíciója nem változtatható meg.
Ha ez igaz akkor a youtub miért dob ki olyan találatot,hogy mozgóképet csinátak fragment shaderrel?
Pl ez?
Mondanám, hogy elég a sima, de nem tudom mit csinál a GLFX. Ha magadtól írsz shadereket, szinte ugyanúgy haladhatsz, csak éppen a változatokat meg kell oldani és külön átírni az adott glsl verzióra.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
Keresel egy .tga / .bmp betöltőt (ahogy a többiek is ajánlotték) és kész is vagy.
Ha már nagyon a végén vagy érdemes megismerkedni a .pvr formátummal, mert ios-re célszerű használni PVRTC formátumú textúrákat (androidra ETC1 kell). Van egy képkonvertáló, ami képes ilyen textúratömörítésű képeket gyártani és .pvr fileformátumba menteni.
Értem. Egy uno szerű játékot szeretnék programozni szakdogára. C++ nyelvet választottam és ahhoz kellene kép betöltés (kártyák, háttér).
Az OpenGL-t azért választottam, mert megszeretném tanulni iOS fejlesztéshez.
Esetleg van egyszerűbb mód a képek betöltéséhez?
Igazából gyakorlásnak is jó megírni egy kis fájlbeolvasást. Később ezek már mind rutin dolgok lesznek, szóval mindegy mivel kezdesz. BMP is lehetne egész nyugodtan.
Én pl zip-ből olvasok tga-t. De software-es DXT compress/decompress-t is begyűjtöttem/autómatizáltam, amit minden támogat.
---
Bőven elég a windows ablak, minimál openGL és valami minimál textúra. Minden mást sokkal több idő begyakorolni, mint hogy később milyen libeket fogsz használni.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
Idézetivanicsm93 :
És ha még időben (most) váltok OpenGL-ről SDL-re és ha azt jobban megértem akkor, majd visszatérek rá? Még csak nagyon alap dolgokat kezdtem el tanulni.
SDL-nél ott van az SDL_image.
Az SDL egy extra réteg lesz, amire az alkalmazásod épül. Ha most nekiállsz az SDL-re építeni bármit is, később minél több kódod épül majd rá, annál nehezebb lesz megszabadulni tőle. Én a helyedben már nem erőltetném az SDL-t, persze ez attól is függ, hogy mit akarsz csinálni - ha csak a textúrabetöltésről van szó, akkor SDL = ágyúval lőni verébre szvsz.
IdézetGeri :
nem javaslom a dds-t. max ha lopsz bele s3tc dekódert. sok sikert az 1 millió dolláros jogdíj kifizetéséhez.
Geri, ez k***a régi lemez és még mindig hamisan szól... Kár ezzel a hülyeséggel riogatni a kezdőket újra meg újra - a jogdíjat nem ő fizeti, hanem a drivert publikáló cég. Te max akkor fizetsz jogdíjat, ha saját drivert írsz. (És miért pont 1 millió dollár? Ezt csak úgy felböfögted, igaz?)
Ha írsz egy rohadt hobbyprojectet és használsz benne egy fájlformátumot, azért nem kell fizetned. A compressed texture támogatás meg nem a te dolgod, hanem ismétlem: a VGA driver készítőié.
És ha még időben (most) váltok OpenGL-ről SDL-re és ha azt jobban megértem akkor, majd visszatérek rá? Még csak nagyon alap dolgokat kezdtem el tanulni.
SDL-nél ott van az SDL_image.
case DXT1_FOURCC:
format = GL_COMPRESSED_RGBA_S3TC_DXT1_EXT;
break;
case DXT3_FOURCC:
format = GL_COMPRESSED_RGBA_S3TC_DXT3_EXT;
break;
case DXT5_FOURCC:
format = GL_COMPRESSED_RGBA_S3TC_DXT5_EXT;
meg persze olyan gyártó, ami rendelkezik engedéllyel az s3tc szabadalmaihoz - vagy egyáltalán támogatja az s3tc-t.
opensource driverek eleve nem, a mobiltelefonok elég nagy része szintén nem támogatja.
nem javaslom a dds-t. max ha lopsz bele s3tc dekódert. sok sikert az 1 millió dolláros jogdíj kifizetéséhez.
Ha textúrának akarod betölteni azokat a képeket (márpedig gondolom annak!) akkor elgondolkodhatsz a .DDS file-okon. Kisebb helyet foglalnak, mint a TGA meg az egyéb formátumok, ráadásul a betöltésükhöz nem kell semmilyen library, csak egy minimális kód. Lásd még:
OpenGL-ben sehogy sem lehet betolteni kepeket. Ehhez valamilyen mas library-t szokas hasznalni. Esetleg megirhatod a sajat kepbetolto rutinjaidat. Az utobbit nem javaslom, mivel nagyon maceras (pl.: a png kepeket betolto library (libpng) nagyjabol 20000 sor forraskod). Egy bmp betolto megirasa viszont nagyon egyszeru, kb. 10 perces munka, ha mar ismered a bmp fajlformatumot.
Megintcsak azt tudom javasolni, hogy hasznalj Qt-t, aminek ott a QImage osztalya kepbetoltesre. Vagy hasznald az SDL egyik kiterjeszteset (SDL_image). Esetleg hasznalhatod a libpng, libjpg stb. konyvtarakat. Ezt szinten nem javaslom, mivel mindet mashogy kell kezelni.
Sikerült!
Végre lefuttatta a GLFW.xcodeproj-t az Xcode 5, de nem hozta létre a libglfw.dylib-et. Írtam a videó készítőjének (http://www.youtube.com/watch?v=GHdorvcZRMg) és azt mondta generáljam újra cmake-ben a fájlokat. Legeneráltam, újra lefuttattam és létrehozta a libglfw.dylib fájlt. Bemásoltam a /usr/local/lib mappába, de előtte átírtam a nevet libglfw.dylib-ről libglfw3.dylib-re.
Utána Xcode 5 -> új projekt -> bemásoltam a példa kódot, beállítottam a build settings-t és a build phases-t (a videó alapján), futtattam és létrehozta az ablakot.
Ja és előtte telepítettem a glfw3.0.3-t homebrew-el.
Kb. 4 napig tartott, de csak összejött
Köszönöm mindenkinek a segítséget!
zeller: megpróbáltam, de megint ezt az üzenetet írta ki: make: *** No rule to make target `install'. Stop.
- - - -
Megpróbáltam homebrew-el is, de szintén elakadtam...
Beírtam ezt a parancssort: brew install --build-bottle --static glfw3
Első futtatáskor telepített ha minden igaz, ezt bizonyítja, ha újra beírom a parancssort ezt írja ki:
Warning: glfw3-3.0.3 already installed, it's just not linked
Ezt a hozzászólást ivanicsm93 módosította (2013.12.16 18:53 GMT+1 óra, ---)
Idézetivanicsm93 :
Mitől jobb/másabb a glfw3 mint pl. a glut vagy glew vagy a freeglut?
A GLUT zárt forráskódú, implementációfüggő, öreg, keveset tud. A FreeGLUT ennek a nyílt forráskódú megvalósítása. A GLFW pedig hasonló cucc mint ezek, csak sokkal többet tud náluk, nyílt forráskódú, aktív projekt.
A GLEW-val szerintem tévedésben vagy, mivel az egy OpenGL bővítményekkel kapcsolatos library, az ablakozáshoz nincs sok köze.
"Kicsit" kocka vagyok szóval egy játék a szakdoga témája. Először egy kártyás játék volt a terv (mint pl. Hearthstone) aztán úgy döntöttem inkább a Puzzle Quest-re fog hasonlítani. Mivel már leadtam a szakdolgozat témát így a kártyás résznek is benne kell lennie, szóval a karakter képességei kártyákkal lesz megoldva a harc pedig a Puzzle Quest-ben lévő harcrendszerrel.
Valamiért nagyon az OpenGL-el szeretném csinálni.
Mitől jobb/másabb a glfw3 mint pl. a glut vagy glew vagy a freeglut?
A korabbi verziokkal csak Linux-ra, Windows-ra es OS-X-re lehetett fejleszteni. A napokban megjelent Qt 5.2-es verzioval mar iOS-re es Android-ra is fejleszthetsz Qt-val platformfuggetlen modon. En meg nem probaltam ki ido hijan, de biztos vagyok benne, hogy jol mukodik. A Qt fejlesztoitol meg nem tapasztaltam olyat, hogy valamit ne teszteltek volna le alaposan.
Valamint a Qt nem zarja ki az OpenGL-t. A Qt alapvetoen widget-ekkel mukodik. En ugy szoktam csinalni, hogy letrehozok egy OpenGL widget-et es korulpakolom a szamomra fontos GUI elemekkel (pl.: PushButton stb.). Az OpenGL widgetben rajzolok, a rajzolast pedig befolyasolni tudom kulonbozo felhasznaloi interakcioval.
Nem tudom, mi a szakdogad temaja, de a Qt biztosan nagy segitseged lenne, ha ilyesmiket tervezel. En is annak a segitsegevel irtam a szakdogamhoz a szoftvert.
Szakdogához szerettem volna megtanulni az OpenGL-t, de most elgondolkoztam a Qt-n.
A fő cél az iOS alkalmazás fejlesztés, ezért akartam a szakdogát is ezzel programozni.
Qt-vel lehet iOS-re és Mac-re is fejleszteni?
Ahogy zeller is irta a Qt tenyleg hatalmas. Meg az SDL-el es az fltk-val sem emlitenem egy lapon.
Az SDL es az fltk csak addig jo, amig nem akarsz veluk mast csinalni, mint megjeleniteni egy ablakot es rajzolni ra a sajat szajized szerint. Ha mar tobb ablak is kellhet, esetleg mindenfele mas beviteli eszkoz (pl.: PushButton, ComboBox, SpinBox, stb.), akkor mar a Qt-t javaslom.
Ha ezek a feature-ok nem kellenek most, akkor is erdemes elsajatitani, mivel pillanatok alatt lehet vele GUI-s alkalmazasokat kesziteni platformfuggetlen modon.
(A qt egy heavy weight framework, nincs egy sulycsoportban a glfw-vel.) De en elfelejtenem a glfw-t glutot meg a tobbi hasonlot.
Ha platform fuggetlenul akarsz ablakozni es esemenyt kezelni akkor fltk, sdl, qt.
Javaslom, hogy használj Qt-t. Eleinte picit macerásnak tűnik, de ha megtanultad, utána már nagyon kényelmes. Én Windows-on és Linux-on használom, teljesen meg vagyok vele elégedve.
-----
nem vagyok egy cmake guru (sose hasznaltam) de a leiras alapjan elvileg cd build , utana pedig sudo cmake meg kene oldja. Abban a txt fileban kell legyenek INSTALL direktivak is
Ezt a hozzászólást zeller módosította (2013.12.16 08:57 GMT+1 óra, ---)
Amúgy az baj ha a Letöltések mappában van? Azon belül is a letöltött glfw-3.0.3 mappában, ahol létrehoztam egy Build nevű mappát és abba generáltam a fileokat CMake-val.
Biztos jól írom be a parancssort(belepek a Build mappába és ezt írom be: sudo make install, utána beírom a jelszót)?
Ezt a hozzászólást ivanicsm93 módosította (2013.12.16 00:20 GMT+1 óra, ---)
ok, most latom, hogy cmake-kel kell. Az nekem nincs fent.
Milyen targetek vannak a makefileban? Ki kene keresni a megfelelot (vagy a readmeben megnezni, aztan azt sudoval meghivni)
Az alapvető probléma az, hogy nincs jogosultságod a "/usr/local/lib/cmake/glfw" könyvtár létrehozásához. Ezt akkor próbálja meg létrehozni, amikor installálni akarja a glfw3-at.
Sajnos nem vagyok otthon a Mac világában, így nem tudom, hogy mi a terminál parancs a telepítéshez. De az elé beírva a sudo-t működnie kéne.
Egy másik megoldás (elég ronda megoldás) lehet az, hogy engedélyezed a root bejelentkezést valahol a GUI-ban, majd kijelentkezel és újra bejelentkezel root-ként. De ismétlem ez nagyon csúnya megoldás, nem így kéne működnie.
Nekem nagyon ugy tunik, hogy csak annyi a hibad, hogy nincs root jogosultsagod. Ird be a parancs ele, hogy sudo. Linuxon ez lenne a megoldas, ahogy elneztem Mac OS X-en is van ilyen parancs.
Eddig nem terminálból csináltam. sudo open xcodeprojekt_neve vagy már rögtön installálni kell?
Nekem nagyon ugy tunik, hogy csak annyi a hibad, hogy nincs root jogosultsagod. Ird be a parancs ele, hogy sudo. Linuxon ez lenne a megoldas, ahogy elneztem Mac OS X-en is van ilyen parancs.
Már a 4. napja szenvedek a glfw3 telepítésével, de egyszerűen nem sikerül. Youtube-on találtam egy videót (http://www.youtube.com/watch?v=GHdorvcZRMg) ami elég jól megmutatja, hogy is kell, de elakadok, mert nálam hibát ír ki.
Több oldalon is utánanéztem, megpróbáltam, de nem jó.
CMake program segítségével próbálkoztam.
Amikor generál egy GLFW.xproj fájlt, megnyitom Xcode-al, beállítom installra a videó(4:04) szerint, de a warning-on kívül nekem egy hibát is talál és nem fut le.
Ezt a hibát írja ki:
/Applications/CMake\ 2.8-12.app/Contents/bin/cmake -DBUILD_TYPE=Debug -P cmake_install.cmake
-- Install configuration: "Debug"
-- Installing: /usr/local/include/GLFW
-- Up-to-date: /usr/local/include/GLFW/glfw3.h
-- Up-to-date: /usr/local/include/GLFW/glfw3native.h
CMake Error at cmake_install.cmake:35 (FILE):
file cannot create directory: /usr/local/lib/cmake/glfw. Maybe need
administrative privileges.
Glew + mingw Windows-on kombóhoz tud valaki valami okosat mondani?
Eljutottam odáig jó sok google után, hogy VS-re készült, és azért kell vele bénázni.
Most ott járok, hogy a lib-eket, includeokat bemásoltam, a glew.h és a glew.c fájlokat hozzádobtam a projektemhez, és beraktam egy #define GLEW_STATIC -ot az includeolás elé.
Elvileg így működnie kéne, gyakorlatilag ha van a kódban olyan függvény, ami igényelné, akkor az exe leáll egy seg fault kíséretében.
Szerk.:
Ez a hiba most teljesen független volt az előzőektől, a glewInit() maradt le. Jó tudni, hogy olyat is kell. Legalább megoldódott.
Ezt a hozzászólást Elodin módosította (2013.12.08 22:30 GMT+1 óra, ---)
Ez azért túlzás, mert az egyes böngészők és azok verziói is különbözőképpen futtatják ugyanazt a heterogén módon megírt kódot, míg egy hagyományos natív cross-platform esetben legalább az adott platform és verzió ugyanazt a futtatást produkálják a szintén heterogén módon megírt és később lefordított programmal. Vagyis beviszünk az "egyenletbe" még egy fölösleges réteget, ami minden, csak nem egységes. Manapság inkább szabadulni akarnak a fejlesztők a kötöttségektől, nem pedig még többet bevinni az engine-be.
Ha pontosak akarunk lenni, akkor nem JavaScriptre fordít az Emscripten, hanem asm.js-re, ami a JavaScript egy durván redukált, alacsonyszintű változata. Lehet kézzel is asm.js kódot írni, de nem feltétlen célszerű. Az asm.js a Mozilla találmánya, külön optimalizálja is a fordítójuk a böngészőben, a Chrome nem írt ezért külön AOT fordítót de valamennyire ő is optimalizálja, az IE-ben meg nincs külön support hozzá. Én kicsit félmegoldásnak érzem az egészet.
Sajnos a JavaScript önmagában nem felel meg játékfejlesztésre a sebessége miatt (elég, ha csak pl. csinálsz egy vector "class"-t és elkezded használni úgy, ahogy logikusnak tűnne - baromi lassú lesz, külön object pool-t kell hozzá írni, az objektumot ki kell "bontani" függvények paramétereinél, stb.). JavaScriptben két választása van igazából az embernek: vagy szép, vagy gyors kódot ír...
WebGL amúgy már van IE11-ben is, szóval lassan tényleg cross-browser megoldásnak számít.
WebGL:
Az Emscripten nem tűnik annyira beteg dolognak, a portolás sem annyira bonyolult (ha jól láttam kvázi automatán fordít c++ból?).
Ha jól tudom a Firefox OS ezzel (is?) megy.
Ezt csak úgy felböfögted, igaz?) 
