játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5457
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2521

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2190
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] > 8 < [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]
Pretender - Törzstag | 2498 hsz       Online status #202113   2014.03.20 22:41 GMT+1 óra  
Arra esetleg megpróbálhatsz egy köztes dolgot: lehet, hogy az a kód, amit használsz egy csomó minden checket csinál, ha bizonyos dolgok definiálva vannak (amik debug esetén). Csinálsz egy custom targetet, aminek lecopyzod a release beállításait, csak kikapcsolod a kódoptiamlizálást,, debug infókat bekapcsolsz, stb.

Én arra gyanakszok, hogy debug módban a memóriát is nagyon figyeli (kiindexelés tömbből, ilyesmik), és az foghatja meg. Na de oda TODO-ztam, hogy release-re majd uncomment.

   
bolyzsolt - Törzstag | 607 hsz       Online status #202112   2014.03.20 22:07 GMT+1 óra  
Idézet
Pretender :
szerk. 2:
Aha, újabb tapasztalatok azt mutatják, hogy csak vs-ből indítva debuggerrel csinálja. Ha az elkészült exe-t indítom, akkor nincs akadás. Érdekes.


VS tud csinálni érdekes dolgokat... Én most egy meglévő (nem általam írt) kódalapra fejlesztek játékot, ami debug módban 2-3 FPS-t tud, releaseben 55-60-at. Azaz release módban tudok csak rendesen tesztelni, viszont ekkor a végső linkelés több, mint egy percig tart. :sóhaj

   
Pretender - Törzstag | 2498 hsz       Online status #202110   2014.03.20 19:45 GMT+1 óra  
VBO update:
Több helyen is azt olvastam, hogy jó, ha a glBufferSubData előtt hívunk egy glBufferData-t null pointerrel, és ezzel xy dolgot jelzünk a drivernek. Így is tettem, és csak pislogtam, hogy mi a fene van, mert periodikusan néhány mp-enként megakadt az egész kb. fél mp-re. Ha kiszedem a glBufferData-s dolgot, akkor meg jól működik. Ez mennyire általános? Teljesen driver-függő legalább?

Így jó:
Kód:
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferSubData(GL_ARRAY_BUFFER, 0, numVertices * vertexSize, _vertices);


Így nem:
Kód:
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, numVertices * vertexSize, 0, usageTypes[dynamic]);
glBufferSubData(GL_ARRAY_BUFFER, 0, numVertices * vertexSize, _vertices);


Annyi megjegyzéssel, hogy a numVertices * vertexSize állandó, a buffer létrehozásakor számolom csak ki, azaz mindig a teljes buffer tartalmát lecserélem.

szerk.:
Ja igen, ATI/AMD kártyám és driverem van, lehet az a baj

szerk. 2:
Aha, újabb tapasztalatok azt mutatják, hogy csak vs-ből indítva debuggerrel csinálja. Ha az elkészült exe-t indítom, akkor nincs akadás. Érdekes.

Ezt a hozzászólást Pretender módosította (2014.03.20 19:56 GMT+1 óra, ---)

   
Seeting - Törzstag | 2306 hsz       Online status #201973   2014.03.12 11:59 GMT+1 óra  
Idézet
syam :
Idézet
__z :
Idézet
syam :
Én itt nem látok vbot csak vertex arrayt.


A lényeg, hogy működik...





Viszont ha kliens memóriából töltöd fel az adatot minden frameben, akkor tud számítani a felesleges méret. Persze kis méretnél ill. amíg 60 fps a sebesség addig nincs gond



Ha vbo-t használ akkor is kliensből tölti fel minden frameben (ha dinamikus változik). Sőt, ha glBufferData-t vagy glBufferSubData-t használ akkor úgy néz ki, hogy kliens->pinned (kliens) -> device. Míg mapbuffer esetében csak kliens -> device. Ha a driver el tudja kerülni a másolást, akkor el fogja.
   
syam - Törzstag | 1491 hsz       Online status #201969   2014.03.12 11:18 GMT+1 óra  
Idézet
__z :
Idézet
syam :
Viszont ha kliens memóriából töltöd fel az adatot minden frameben, akkor tud számítani a felesleges méret.


Jah, hát ezért kérdeztem.
Viszont egyrészt a glDrawArrays-nál gondolom nem véletlenül kell megadni tartományt, másrészt a futás közbeni sebesség bőven jó (30+ FPS egy Alcatel 990-en).



Hogy mikor és mit művel a vertex arrayjal az a driver dolga. A "tartomány" csak annyit mond, h hány mettől meddig akarsz renderelni vagyis azokat fogja feldolgozni - hogy mennyi megy fel a gpunak az már driver kérdés.
Egyébként a drawarrayst nem szeretik, mert nem használod a vertex cachet. Ahol lehet indexelt geometriát használj. Ilyen esetben már extension optimalizálásra: glDrawRangeElements, aminek meg lehet mondani, hogy mekkora vertex mennyiséget fogsz felhasználni az arrayból.

De még egyszer: ha megfelelő / interaktív sebességű a framerate, akkor totál mindegy mit csinálsz, ha minden készüléken megy és ugyanúgy is néz ki
alias aalberik
   
__z - Tag | 69 hsz       Online status #201968   2014.03.12 11:08 GMT+1 óra  
Idézet
syam :
Viszont ha kliens memóriából töltöd fel az adatot minden frameben, akkor tud számítani a felesleges méret.


Jah, hát ezért kérdeztem.
Viszont egyrészt a glDrawArrays-nál gondolom nem véletlenül kell megadni tartományt, másrészt a futás közbeni sebesség bőven jó (30+ FPS egy Alcatel 990-en).

   
syam - Törzstag | 1491 hsz       Online status #201967   2014.03.12 10:58 GMT+1 óra  
Idézet
__z :
Idézet
syam :
Én itt nem látok vbot csak vertex arrayt.


A lényeg, hogy működik...





Viszont ha kliens memóriából töltöd fel az adatot minden frameben, akkor tud számítani a felesleges méret. Persze kis méretnél ill. amíg 60 fps a sebesség addig nincs gond
alias aalberik
   
__z - Tag | 69 hsz       Online status #201966   2014.03.12 10:54 GMT+1 óra  
Idézet
syam :
Én itt nem látok vbot csak vertex arrayt.


A lényeg, hogy működik...

   
syam - Törzstag | 1491 hsz       Online status #201965   2014.03.12 10:43 GMT+1 óra  
Idézet
__z :
Itt a konkrét kód (Android/Java):
Kód:
FloatBuffer vertices = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer(),
            texCoords = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer();
float[] array = new float[12];
int[] transform = new int[2];         
float width, height;

gl.glVertexPointer(2, GL10.GL_FLOAT, 0, vertices.clear());           
gl.glTexCoordPointer(2, GL10.GL_FLOAT, 0, texCoords.clear());

void drawArrays(GL10 gl) {
  gl.glDrawArrays(GL10.GL_TRIANGLES, 0, vertices.position() / 2);
  texCoords.clear();
  vertices.clear();
}       

void draw(float x, float y, int textureX, int textureY, int textureWidth, int textureHeight) {     
  if (vertices.remaining() == 0) drawArrays(gl);
  array[10] = array[2] = array[0] = x;
  array[9] = array[5] = array[1] = y;           
  array[8] = array[6] = array[4] = x + Math.abs(transform[0]) * textureWidth;
  array[11] = array[7] = array[3] = y + Math.abs(transform[1]) * textureHeight; 
  vertices.put(array);             
  array[10] = array[2] = array[0] = (transform[0] > 0 ? textureX : textureX + textureWidth) / width;
  array[9] = array[5] = array[1] = (transform[1] > 0 ? textureY : textureY + textureHeight) / height;           
  array[8] = array[6] = array[4] = (transform[0] < 0 ? textureX : textureX + textureWidth) / width;
  array[11] = array[7] = array[3] = (transform[1] < 0 ? textureY : textureY + textureHeight) / height;
  texCoords.put(array);                 
}
// a transform tömböt tükrözéshez és nagyításhoz használom




Én itt nem látok vbot csak vertex arrayt.
alias aalberik
   
Seeting - Törzstag | 2306 hsz       Online status #201964   2014.03.12 08:07 GMT+1 óra  
Idézet
syam :
VBO frissítése nem ajánlott dolog. Ha mégis muszáj, mert pl. uniformként nem kezelhető az adat, akkor buffersubdata esetleg dupla bufferelve. A mappelés annyira nem válik be.



Hát pedig ez a dynamic batchelés lényege. Minden frameben frissíteni. Csak az a kérdés, hogy milyen módszerrel invalidáljuk a régi adatot. A duble bufferinget is el lehet érni többféleképpen. Egyébként miért nem szereted a mapbuffer-t?
   
__z - Tag | 69 hsz       Online status #201963   2014.03.12 06:44 GMT+1 óra  
Itt a konkrét kód (Android/Java):
Kód:
FloatBuffer vertices = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer(),
            texCoords = ByteBuffer.allocateDirect(49152).order(ByteOrder.nativeOrder()).asFloatBuffer();
float[] array = new float[12];
int[] transform = new int[2];         
float width, height;

gl.glVertexPointer(2, GL10.GL_FLOAT, 0, vertices.clear());           
gl.glTexCoordPointer(2, GL10.GL_FLOAT, 0, texCoords.clear());

void drawArrays(GL10 gl) {
  gl.glDrawArrays(GL10.GL_TRIANGLES, 0, vertices.position() / 2);
  texCoords.clear();
  vertices.clear();
}       

void draw(float x, float y, int textureX, int textureY, int textureWidth, int textureHeight) {     
  if (vertices.remaining() == 0) drawArrays(gl);
  array[10] = array[2] = array[0] = x;
  array[9] = array[5] = array[1] = y;           
  array[8] = array[6] = array[4] = x + Math.abs(transform[0]) * textureWidth;
  array[11] = array[7] = array[3] = y + Math.abs(transform[1]) * textureHeight; 
  vertices.put(array);             
  array[10] = array[2] = array[0] = (transform[0] > 0 ? textureX : textureX + textureWidth) / width;
  array[9] = array[5] = array[1] = (transform[1] > 0 ? textureY : textureY + textureHeight) / height;           
  array[8] = array[6] = array[4] = (transform[0] < 0 ? textureX : textureX + textureWidth) / width;
  array[11] = array[7] = array[3] = (transform[1] < 0 ? textureY : textureY + textureHeight) / height;
  texCoords.put(array);                 
}
// a transform tömböt tükrözéshez és nagyításhoz használom

   
syam - Törzstag | 1491 hsz       Online status #201961   2014.03.12 01:57 GMT+1 óra  
Mármint dinamikusan töltöd fel / updateled minden frameben a vbo tartalmát?
alias aalberik
   
__z - Tag | 69 hsz       Online status #201960   2014.03.12 00:38 GMT+1 óra  
Idézet
syam :
A vbo "akármekkora" lehet sebességet nem befolyásol. Ha mobilplatform is bejátszik, akkor arra kell figyelni, h 64k vertexnél ne legyen több.


Az ilyesmikre voltam kíváncsi, de most csak kb. ~12k vertex-nyit foglalok (49152 byte), ami már biztosan elég, és ezek szerint sok vizet nem zavar a "fölöslegesen" lefoglalt hely.
Egyébként nem tudom, milyen alternatívák vannak, de én egyszerű float-ként olvasom be a bufferekbe a texcoord és vertex pozíciókat, így feltételezem, ezek frame-enként "közlekednek" a két ram között, ezért gondoltam, hogy számíthat a méretük...

   
syam - Törzstag | 1491 hsz       Online status #201959   2014.03.11 23:10 GMT+1 óra  
A vbo "akármekkora" lehet sebességet nem befolyásol. Ha mobilplatform is bejátszik, akkor arra kell figyelni, h 64k vertexnél ne legyen több.

Kb. csak arra kell figyelni, hogy interleaved legyen az adat és minél kisebb méretű legyen a vertex attrib össz mérete.

VBO frissítése nem ajánlott dolog. Ha mégis muszáj, mert pl. uniformként nem kezelhető az adat, akkor buffersubdata esetleg dupla bufferelve. A mappelés annyira nem válik be.
alias aalberik
   
Seeting - Törzstag | 2306 hsz       Online status #201958   2014.03.11 22:08 GMT+1 óra  
Egyébként te hogy frissited a vbo-k tartalmát? Mert jelenleg pont én is ilyesmit implementálok. És ez egyáltalán nem triviális dolog.
   
Seeting - Törzstag | 2306 hsz       Online status #201957   2014.03.11 22:05 GMT+1 óra  
Minél nagyobb a vbo, nyilván annál többet foglal a vram-on, és ha kevés négyszöget rajzolsz ki, akkor ráadásul feleslegesen is.
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201950   2014.03.11 12:57 GMT+1 óra  
Amit írtam, az igazából független attól, hogy mit rajzolsz ki - ezer db négyzet = kétezer db tri (feltéve, hogy nincs ismétlődés), meg egy kétezer polys modell is kétezer tri

Szóval nem, nem látom, hogy lenne bármilyen hátulütője a dolognak.
Dare to imagine!
http://www.insaneidea.hu
   
__z - Tag | 69 hsz       Online status #201949   2014.03.11 08:41 GMT+1 óra  
MaNiAc :
Még mindig csak 2D-s sprite-okat rajzolgatok.
A kérdés arra vonatkozott, hogy foglalhatok akkorát, amibe mondjuk 1000+ "négyzet" belefér, úgyis csak a használt rész számít (a glDrawArrays-nál ugyebár meg kell adni ezt), vagy lehetnek ennek hátulütői?

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201939   2014.03.10 22:29 GMT+1 óra  
Ha 1x akkora kell a modellnek, amit megjelenitesz, akkor akkora kell neki, ebbol ne csinalj problemat Ha mar millios nagysagrendrol van szo, akkor meg ugyis lesz valamifele vagas, ami alapjan megjelenitesz vagy nem jelenitesz meg egy objektumot (pl. egy epulet modelljet felvagod reszekre es csak azokat a reszeket jelenited meg, amik a latoterben vannak, stb)
Dare to imagine!
http://www.insaneidea.hu
   
__z - Tag | 69 hsz       Online status #201891   2014.03.09 07:55 GMT+1 óra  
Implementáltam a dolgot, még az a kérdés merült fel bennem, hogy mekkora vertex és texCoord buffereket érdemes foglalni? Vagy másként megfogalmazva: ha túl nagy méretet foglalok (persze itt csak kilobyte-os nagyságrendre kell gondolni), annak lehet negatív hatása? (Most 4kb-ot foglalok, és ha kevés lenne, meghívódik a glDrawArrays és a bufferek visszaállítása.)

   
Seeting - Törzstag | 2306 hsz       Online status #201835   2014.03.07 05:56 GMT+1 óra  
Ja igen, főleg ha VAO-t használsz. De ha nem, akkor jobb az összevont buffer, mert az csak 1 db glBind().
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201830   2014.03.06 19:40 GMT+1 óra  
Idézet
Seeting :
Desktop GL esetében is ajánlott, a drawcall-ok számának redukalasa. Persze pc-n egy 2D-s játék eseteben nem fogod érzékelni a változást.

Összevonás alatt arra gondoltam, hogy két külön array van vs. egy db array + stride. Ez drawcall szempontból tök mindegy szerintem.
Dare to imagine!
http://www.insaneidea.hu
   
Seeting - Törzstag | 2306 hsz       Online status #201820   2014.03.06 13:11 GMT+1 óra  
Desktop GL esetében is ajánlott, a drawcall-ok számának redukalasa. Persze pc-n egy 2D-s játék eseteben nem fogod érzékelni a változást.
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #201818   2014.03.06 09:36 GMT+1 óra  
Szerintem az összevonás preferencia kérdése - bár nem tudom, ES-nél van-e erre valami speciális dolog... (Desktop GL-lel dolgozok). Én csináltam már így is, úgy is.

A másik meg igen, triangles... Régen nagyon nyomatták a tristrip-et is, néhány esetben biztos jó is, de sokszor elég szopás, mivel egy random 3d progiból (pl. Blender) kiexportált modellben sima trik lesznek, indexelve.
Dare to imagine!
http://www.insaneidea.hu
   
syam - Törzstag | 1491 hsz       Online status #201817   2014.03.06 09:34 GMT+1 óra  
Amit lehet batchelj. A mobilok nagyon kényesek a drawcall számra.
Célszerű külön kezelni uvt és pozíciót.
Indexelt háromszögeket érdemes használni, mert akkor egymással össze nem kapcsolt háromszögeket tudsz renderelni (strip esetén degenerált háromszög kellene), de ugyanakkor használod is a vertex cachet.

Én billboard pontokat és vonalakat batchelek (ill. szöveget) - tipikusan az az eset, amiből sok van viszont egyszerre kevés a geometria.
alias aalberik
   
__z - Tag | 69 hsz       Online status #201814   2014.03.06 09:02 GMT+1 óra  
Még két kérdés:
- a texCoord és vertex tömböket össze lehet (illetve érdemes) vonni egybe?
- mi a legcélszerűbb primitiv (gondolom GL_TRIANGLES) ?

   
Pretender - Törzstag | 2498 hsz       Online status #201813   2014.03.06 08:29 GMT+1 óra  
Szövegekre mindenképpen érdemes egybegyúrni. Sőt, a sprite-ok rajzolásához is. Általában Sprite Batch-nek nevezik ezt az egészet, és egy dinamikus VBO-ba frissítgetik az értékeket.
Szóval ilyesfajta sprite renderelésnél szerintem mindenképpen gyorsulást hozna, elkerülve a draw callok overhead-ét.

   
__z - Tag | 69 hsz       Online status #201812   2014.03.06 05:39 GMT+1 óra  
OpenGL ES (1.1) kérdés: Egy 2D-s játéknál, ha a "négyzetenkénti" rajzolás (gl.glDrawArrays(GL10.GL_TRIANGLE_STRIP, 0, 4); ) helyett összegyűjteném a textúra és vertex koordinátákat egy über tömbbe, és csak egyszer hívnám a glDrawArrays-t, az eredményezhet-e érdemi gyorsulást, illetve lehetnek-e egyéb előnyei/hátulütői (rajzolási sorrend, stb.) ?
(Most főként a szövegek kiírásánál jön elő lassulás, ahol a betűket is a fent leírt módon, "egyesével" rajzolom.)
(Szerk: Persze a felvetett megoldás feltételezi, hogy egyetlen nagy textúra atlaszból rajzolok, és nem váltogatom a textúrákat közben.)

   
Geri - Törzstag | 2190 hsz       Online status #201534   2014.02.23 14:46 GMT+1 óra  
én a régi enginemben kettesével töltöttem őket, az újban még nem írtam meg a textúrabetöltéshez szűkséges threadolást.

   
Pretender - Törzstag | 2498 hsz       Online status #201533   2014.02.23 14:39 GMT+1 óra  
Igazából azért a 2048x2048 nem egy túl kicsi textúra, nagyjából 1mp-es betöltési idő talán oké lehet. Persze, ha minden egyes ilyen textúrabetöltésre új threadet indítok, ...

   
Geri - Törzstag | 2190 hsz       Online status #201531   2014.02.23 13:52 GMT+1 óra  
xanat: használj threadokat, azért van a sok cpu mag.

   
__z - Tag | 69 hsz       Online status #201530   2014.02.23 12:35 GMT+1 óra  
Pretender :
Nem tudom, mennyit határoz, de egy próbát megér szerintem, ha a png-ken leveszed a tömörítést 1-3 közé (ha a nulla jelenti a tömörítetlent)...

   
Pretender - Törzstag | 2498 hsz       Online status #201523   2014.02.23 09:02 GMT+1 óra  
Na még egy, ha már a textúráknál vagyunk
Az mennyire természetes, hogy 9 db 2048x2048-as png képet kb. 8-9 mp-ig tart betölteni? Lodepng nevű statikusan befordítható cuccot használom a betöltéshez.

   
Pretender - Törzstag | 2498 hsz       Online status #201522   2014.02.23 07:21 GMT+1 óra  
Ja-ja, ez is jó ötlet. Így viszont szerencsére elkerülöm ennek a problémának az általános megoldását, mert nem fog előjönni.
Minden esetre abban a progiban valahogy trükköztek, mert ezeket a contenteket használva oldották meg. Persze az is igaz, hogy az egy cél-program.

   
__z - Tag | 69 hsz       Online status #201521   2014.02.23 06:07 GMT+1 óra  
Pretender :
Ami nekem eszembe jutott:

Itt az A-B, C-D, E-F részt mindig kirajzolod (persze az utóbbi kettő pozíciója változik), és B-C, D-E rész rajzolásánál trükközöl (vágod, nyújtod, stb.).

   
Pretender - Törzstag | 2498 hsz       Online status #201517   2014.02.22 19:51 GMT+1 óra  
Igazából a contentek adott voltak, egy másik programból vettem kölcsön tesztelés céljára, és ezáltal rögtön elő is jött ez a "probléma". Bár én sem érzem teljesen valósnak, mert ahogy Te is mondtad, más content-használattal kikerülhető.

Arra is gondoltam, hogy 2 részből állna a csík: egy a vastagabb és egy vékonyabb. Ez azért lenne jó, mert ha nem tele van, akkor is jó lenne, ha "csapott végű" maradna, ami pedig az üres + tele csík rajzolgatással nem érzem, hogy megoldható lenne.

   
Lord_Crusare - Törzstag | 1290 hsz       Online status #201516   2014.02.22 19:42 GMT+1 óra  
Ezt elég furcsán valósítod meg. Miért nem készítesz egy üres és egy tele állapotot a csíkból, és a "tele" verzióból csak annyit rajzolsz rá az üresre, amennyire szükség van? A nem-téglalap alakú csíkokat általában így szokták megoldani.

   
Pretender - Törzstag | 2498 hsz       Online status #201515   2014.02.22 19:35 GMT+1 óra  
Adott két alpha csatornával rendelkező kép. Adott továbbá egy program, ami helyesen ábrázolja a két képet. Gyorsan összedobtam egy sprite-kirajzolót. A zöld csík után a szürke keretet rajzolom: srcblend: srcalpha, destblend, invsrcalpha.
A képen látszik, hogy a program jól csinálja, csak nem értem, hogy hogyan. Ugyanis ahol a keret csíkja elvékonyodik, alul nem "lóg ki" a zöld csík. Tudom, kicsit kesze-kuszára sikerült, de itt egy kép. A kérdés röviden annyi, hogy a felül lévő tesztből, hogy csináljak olyat, hogy úgy nézzen ki, mint az alsó (a feliratokat és a kisebb dobozt leszámítva)? Hogy "vágják" meg a zöldet úgy, hogy takarásban legyen?



Olyan jutott eszembe, hogy a z irányában egy kicst eltolom "előrefelé" a szürke keretet. Bekapcsolom az alpha testet és a depth bufferezést. Ahol az alpha < x, ott a zöld csík fog látszani, egyébként meg kitakarja a szürke.

   
Pretender - Törzstag | 2498 hsz       Online status #201467   2014.02.20 21:33 GMT+1 óra  
Ó, elég ratyi így ez az fbo-rendszer. Kicsit át akartam alakítani a rendereremet, amihez kell egy depth prepass. Gondoltam én naív módon, hogy készítek egy fbot depth attachmenttel, majd a kövi fbohoz szintén depth attachment, de a depth write és clear kikapcsolásával. Hát persze, hogy nem. Valószínűleg az lenne a megoldás, hogy ugyan azt a depth renderbuffert csatoljam mindkettőhöz. De ez így miezmár? Oda a struktúra...

szerk.:
Oké, végül is teljesen jogos, hogy miért így működik. Meg nem is volt nagy kihívás megcsinálni. Csak hát na...

Ezt a hozzászólást Pretender módosította (2014.02.20 22:16 GMT+1 óra, ---)

   
ddbwo - Tag | 1625 hsz       Online status #201254   2014.02.16 11:16 GMT+1 óra  
Szerintem nem túl nagy kitérő. Később már mindegy mit hogy hívnak., vagy hogy magának elnevezi-e ugyanazt. Legalább találkozik a szereplőkkel mindenféle pepecselés nélkül.

Utána minden új dolog csak apróság és gyorsabban beépül. Mindennek a megértése a leghosszabb idő, a formaiság szinte lényegtelen.
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
   
Pretender - Törzstag | 2498 hsz       Online status #201253   2014.02.16 11:06 GMT+1 óra  
Ja értem. Szerintem azért elavult dolgokat már nem érdemes tanulni, ha már egyszer tanulja az ember, de való igaz, ez egyszerűbb kicsit. Mármint cpu oldalon.

   
ddbwo - Tag | 1625 hsz       Online status #201252   2014.02.16 10:52 GMT+1 óra  
Az alap alatt a standardot értem. Így elég annyit tenni, hogy meglegyen a shader fordítás, a többit a GLSL ismeri. Ami így néz ki:

Vertex Shader:
Kód:
void main()
{
    gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}


Fragment Shader:
Kód:
void main()
{
    gl_FragColor = vec4(0.0, 1.0, 0.0, 1.0);
}
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
   
Pretender - Törzstag | 2498 hsz       Online status #201251   2014.02.16 10:30 GMT+1 óra  
Ennél alapabb shader nem létezik (mármint ami csinál is valami láthatót) Én csak arra akartam utalni, hogy nem kell 5 millió soros cg kódot nézni kezdetnek, hanem fel kell fogni, hogy mi mit csinál. És ez arra pont jó, lehet vele játszadozni. Persze egy minimális háttértudás azért nem árt.

   
ddbwo - Tag | 1625 hsz       Online status #201249   2014.02.16 09:57 GMT+1 óra  
A Pretendernél látott kód pont nem az alap, érdemes az igazi alappal kezdeni, mert ha azt megérted, a többit kisujjból átírod.
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
   
Elodin - Tag | 173 hsz       Online status #201247   2014.02.16 08:23 GMT+1 óra  
http://ogldev.atspace.co.uk/index.html

Lépésről lépésre a végén talán összeáll vmi kép.
Vagy nézd meg a Szirmay féle bme-s előadásvideokat. Vagy járj be hozzá előadásokra Ott aztán nem kímélnek a gyakorlatban elő nem jövő alapokkal sem. Jól megértheted, hogy hogy működnek olyan dolgok a videokariba, amihez úgyse lesz semmi közöd nagy valószínűséggel

Vagy keress vmi könyvet, vagy vmi. Azért ilyen hamar feladni nem érdemes

   
Pretender - Törzstag | 2498 hsz       Online status #201244   2014.02.16 07:31 GMT+1 óra  
Pedig nem egy bonyolult dolog, csak egyszerre túl sok mindent akarsz megérteni. Én például soha nem akartam tudni, hogy fizikailag hol tárolódik a frame buffer tartalma.

Érteni kell hozzá az alap matematikai struktúrákat (mátrixok, vektorok, ...) és a hozzá tartozó műveleteket. Továbbá fel kell fogni azt, amit lentebb írtam. Mire használod a vertex shadert és a fragment shadert.

A legegyszerűbb shadert egyébként úgy tudod előállítani, hogy nem csinál kb. semmit. Értsd ezt úgy, hogy a kirajzolást screenspace koordinátákkal adod meg (azaz [-1, 1], [-1, 1] intervallumon), ekkor a vertex shadernek csak annyi a dolga, hogy a bejövő pozíciót beállítsa outputként.
Valami ilyesmi:
Kód:
#version 110
attribute   vec2    inPosition;
void main()
{
    gl_Position = vec4(inPosition.x, inPosition.y, 0.0, 1.0);
}


A fragment shaderben meg például átszínezed a pixeleket zöldre
Kód:
#version 110
void main()
{
    gl_FragData[0] = vec4(0.0, 1.0, 0.0, 1.0);
}


Persze ez csak a shader-oldali kód. Ezt OpenGL-ben be kell tölteni, linkelni, használni.

   
Viperion - Tag | 540 hsz       Online status #201243   2014.02.16 03:30 GMT+1 óra  
"egyáltalán minek neked shader?"
Azért,hogy ne csak a proci szenvedjen a feladatokkal.
Meg azért,hogy tudjak írni sajátot.

De mindegy már mert lemondtam róla.
Maradok csak a c# nál.

   
Geri - Törzstag | 2190 hsz       Online status #201242   2014.02.16 01:23 GMT+1 óra  
egyáltalán minek neked shader?

   
Viperion - Tag | 540 hsz       Online status #201241   2014.02.16 00:15 GMT+1 óra  
Túl nehéz.
Nem értem a logikáját teljesen nem látom át ezt az egészet.
Azt hiszem,hogy maradok csak simán a c# nél. Aztán ha fognak kelleni shaderek akkor majd veszek + ott van még ez is Shader Forge elég jónak tűnik.


   
ddbwo - Tag | 1625 hsz       Online status #201237   2014.02.15 22:30 GMT+1 óra  
Idézet
Geri :
viperion: az a baj, hpgy a közepán próbálod megfogni a dolgot. először is talán sima opengl 1.0 kellene neked, meg sima C, amiben játszadozhatsz.



Kezd egy ponggal!
++
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
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] > 8 < [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] [55] [60] [65] [70] [75] [80] [82]