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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2194
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
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]
Elodin - Tag | 181 hsz       Online status #202179   2014.03.25 19:21 GMT+1 óra  
Van vmi trükk/tool opengl debuggolásra?

Egyszerűen annyit csinálok, hogy betöltök egy modellt, annak a koordinátái a (-1,1) intervallumba esnek, és megpróbálom kirajzolni minden extra nélkül. Saját shadert használok, ami jelenleg nem csinál semmit gyakorlatilag (bemenetet továbbadja a vertex shader, a pixel shader meg konstans színt ad, háromszögre működött is). Amennyire c++ oldalról látom, minden rendben van... viszont nem rajzolódik semmi.


Szerk.: közben sikerült kicsit javítanom a dolgon. glGetError() segítségével rájöttem, hogy rosszul paramétereztem a glVertexAttribPointer() fv-t. Ezt ki is javítottam, most már nem is kapok errort... de ugyanúgy nem rajzol semmit ; (

Ezt a hozzászólást Elodin módosította (2014.03.25 19:40 GMT+1 óra, ---)

   
Geri - Törzstag | 2194 hsz       Online status #202151   2014.03.23 00:27 GMT+1 óra  
a webgl úgyis randomra elszáll alóluk pár frame után, mert a webfejlesztők szerencsére ezt sem bírták rendesen megoldani.

   
Parallax - Tag | 603 hsz       Online status #202144   2014.03.22 05:18 GMT+1 óra  
Idézet
versio :
en csak azert emlitettem meg, mert en is agyfaszt kaptam a forditasi idoktol windows metrora programozva, soha nem ternek vissza se windowsra se c++-ra, nem ment el az eszem


Ha nálad az a fejlesztés, hogy átírsz valamit, aztán lefordítod, a fordító kidobja a módosításból adódó esetleges hibákat és így tovább, akkor nem a C++ a hibás. Egyébként meg az /MP kapcsoló csodákra képes.

A másik, hogy manapság zömében annyira egyszerű játékok vannak és a fejlesztői eszközök, annyira modernek, hogy nincs is értelme egy nagy és bonyolult engine és a hozzá tartozó infrastruktúra használatát hónapokig tanulni. Egyszerűbb pár nap/hét alatt öszerkani a játékot OpenGL-el és a megfelelő platform specifikus részeket a platformokhoz tartozó SDK-val. Erre már rájöttek az engine fejlesztő cégek is és már szinte ingyen csinálhat az engine-el bárki bármit, ha ágyúval akar hangyára lőni.

Az a kevés cég, aki AAA-ra játszik pedig van annyira pro, hogy nem más kreálmányával heggeszt contenteket, hanem szintén megírja a motort magának.

Utolsó kapaszkodójuk az engine gyárosoknak a webfejlesztők, hátha bekajálják a motorjukat és a C++ ból generált js-el majd összegányolnak valamit, amire maguktól nem képesek.

   
MaNiAc - Szerkesztő | 1735 hsz       Online status #202141   2014.03.21 18:52 GMT+1 óra  
Idézet
versio :
en csak azert emlitettem meg, mert en is agyfaszt kaptam a forditasi idoktol windows metrora programozva, soha nem ternek vissza se windowsra se c++-ra, nem ment el az eszem

Ez mindössze azért ciki, mert egy tetves szó sem volt a fordítási időkről...

Btw aki OpenGL-t akar programozni, az nyílván azért teszi, mert nem egy meglévő enginehez akar contentet csinálni, hanem mert OpenGL-t akar programozni.
Dare to imagine!
http://www.insaneidea.hu
   
versio - Tag | 673 hsz       Online status #202138   2014.03.21 18:06 GMT+1 óra  
en csak azert emlitettem meg, mert en is agyfaszt kaptam a forditasi idoktol windows metrora programozva, soha nem ternek vissza se windowsra se c++-ra, nem ment el az eszem
   
MaNiAc - Szerkesztő | 1735 hsz       Online status #202123   2014.03.21 07:12 GMT+1 óra  
El se kezdjétek ezt a baromságot - ez nem a Unity topic!
Dare to imagine!
http://www.insaneidea.hu
   
Geri - Törzstag | 2194 hsz       Online status #202121   2014.03.21 03:05 GMT+1 óra  
hát hogyne

   
versio - Tag | 673 hsz       Online status #202118   2014.03.21 00:50 GMT+1 óra  
bolyzsolt: a megoldas az unity
   
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 | 71 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 | 71 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 | 71 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 | 71 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 | 71 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 | 71 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 | 71 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 | 71 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 | 2194 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 | 2194 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 | 71 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 | 71 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 | 1312 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 | 1654 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 | 1654 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
   
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]