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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
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] > 51 < [55] [60] [65] [70] [75] [80] [82]
gaborlabor - Moderátor | 4449 hsz       Online status #81292   2008.02.09 10:02 GMT+1 óra  
megcsinálhatod azt is, hogy 3, vagy több sprite-ot rajzolsz egymásra (értelemszerűen egyre lejjebb), és azokat mozgatod jobbra-balra, úgy, hogy minden második azonos irányba mozduljon...
az mondjuk nem élethű, hanem retro, de platformjátékokban találkozni ilyesmivel. és akkor nem kell animált textúra, elég egy (vagy több) olyan kép, aminek hullámos a felső része.
azt is érdemes megnézni, hogy a worms armageddonban hogy van megoldva.

ahhoz meg, hogy élethű legyen, szerintem elsősorban egy jó grafikus kell.

szerk: basszus, megint megelőztél.

   
Asylum - Törzstag | 5511 hsz       Online status #81291   2008.02.09 09:58 GMT+1 óra  
szerintem olyasmire gondol hogy hullámzik és közbe fel-le mozog mint valamelyik játékban ami nem jut most eszembe...végülis a fel-le mozgást egy jól kitalált sinussal meglehet oldani, az animációt pedig szerintem ugy hogy felváltva rajzolod az eredeti vizet, aztán egy kicsit eltolva balra vagy jobbra, de persze ugy hogy ne logjon ki a képernyöröl. vagy megbüvölöd a texcoordokat.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Kristf - Törzstag | 125 hsz       Online status #81290   2008.02.09 09:56 GMT+1 óra  
Egy 2D-s platform játékba illőt, szürkés kék színe legyen, és valósághű mozgása.

   
beast - Törzstag | 1241 hsz       Online status #81287   2008.02.09 09:29 GMT+1 óra  
Megoldás az van egy csomó, inkább csak jól kellene kérdezni. Mert ebből, hogy:
"2D-ben ... egy adott téglalap területén mozogjon és hullámozzon a víz" nem igazán tudjuk, hogy milyet is szeretnél...

   
Asylum - Törzstag | 5511 hsz       Online status #81285   2008.02.09 09:08 GMT+1 óra  
kimész a dunapartra, felveszed ahogy hullámzik a víz, és bejátszod a kép hátterébe
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Kristf - Törzstag | 125 hsz       Online status #81284   2008.02.09 08:16 GMT+1 óra  
Erre gondoltam énis, lehet hogy ezt fogom használni, de nincs esetleg valami más megoldás is?

   
beast - Törzstag | 1241 hsz       Online status #81277   2008.02.09 05:17 GMT+1 óra  
Animált textúra? Elég oldschool, de örökzöld megoldás.

   
Kristf - Törzstag | 125 hsz       Online status #81276   2008.02.09 05:15 GMT+1 óra  
Hello!

2D-ben próbálok vizet szimulálni, úgy hogy egy adott téglalap területén mozogjon és hullámozzon a víz. Rézsecskerendszerrel próbáltam megoldani, de nem sikerült valami szépre. Tudtok esetleg ajánlani egymásik megoldást, egy jó ötletet, vagy egy jó tutorialt a neten? Már keresgéltem, de csak 3d-eseket találtam.

   
syam - Törzstag | 1491 hsz       Online status #80094   2008.01.21 13:35 GMT+1 óra  
a vertex eredetileg egy "gyűjtőfogalom" és több részből áll; mindenképp áll egy pozicioból, de ezenkívül tartozhat hozzá szín, normálvektor, texcoord etc...
alias aalberik
   
fpeti - Törzstag | 1295 hsz       Online status #80091   2008.01.21 12:45 GMT+1 óra  
Heh, ezt nem is tudom, ha transzformálunk, akkor az egész vertexet, vagy csak a vektorait.. nálam ez már filozófikus magasság, meg ugye ha pl csak a textúrakoordinátákat transzfomálod, de a vektorait (ami a vertexben van) nem, akkor csak nem az egész vertexet... ilyen, ha nem oktatásban tanulja az ember a fogalmak neveit - tényleg nem tudom.
   
gaborlabor - Moderátor | 4449 hsz       Online status #80083   2008.01.21 12:15 GMT+1 óra  
Idézet
fpeti :
[...]
(persze akár kézzel is lehetne forgatni a textúrakoordinátákat, a vektorok ettől maradhatnak a helyükön)


ööö nem a vertexek?

   
fpeti - Törzstag | 1295 hsz       Online status #80077   2008.01.21 11:51 GMT+1 óra  
OGL-ben is van biztos textúra-trf-mátrix, ha kör alakú a kép érdemi része (többi része átlátszó), akkor azzal is lehetne forgatni.
(persze akár kézzel is lehetne forgatni a textúrakoordinátákat, a vektorok ettől maradhatnak a helyükön)
   
tomtom - Tag | 4 hsz       Online status #80017   2008.01.20 20:45 GMT+1 óra  
Köszi a linket, átnézem

   
syam - Törzstag | 1491 hsz       Online status #80009   2008.01.20 15:01 GMT+1 óra  
ahoi,

szokásos esetben a quadot nem kell forgatnod; a részecskéket pontnak tekintjük és annak koordinátáját gndlm minden esetben ujraszámolod ezután e pont köré a kamera síkjával párhuzamos síkban kell kiszámolni 4 pontot vagyis a quad 4 csucspontját

a kamera síkját pedig megkapod a glulookat ( vagy ezzel egyenértékű) függvényhívás utáni modelview matrixból

http://www.codesampler.com/oglsrc/oglsrc_6.htm#ogl_optimized_billboards

nézz szét itt, itt alaposan ki van vesézve
alias aalberik
   
tomtom - Tag | 4 hsz       Online status #80004   2008.01.20 13:41 GMT+1 óra  
Hát a quadot nem forgatom( transzponálom a modelview mátrixot), ezért néz a kamera felé, csak az eltolást változtatom,és nincs is 4 koordináta csak egy, ott van a részecske, a quad 4koordinátáját pedig ehhez viszonyítva számolom ki, az a "size" változó segítségével.

Próbáltam a modelview mátrix forgatási részét átírni (csak z tengely kerüli forgatás) de akkor meg összevissza forgott a quad, és szétesett az egész, bár lehet rosszul írtam meg

[szerk]

De lehet így marad és egyelőre kihagyom a forgatást

   
Birmacher - Törzstag | 516 hsz       Online status #80003   2008.01.20 13:30 GMT+1 óra  
Alapjáraton van 1 Quadod... 4db (XYZ) koorináta. Ezt elforgatod, hogy a kamera felé nézzen, így kapsz 4 újabb koordinátát, amire 2D forgatást alkalmazol, magyarul maradsz ugyanezen a síkon. A 2Dben való forgatáshoz veszel egy középpontot ami a QUAD közepe lesz. és már csak alkalmazod a forgatást... Megint kapsz 4 koordinátát, amivel már ki is rajzolhatod az alakzatot

Ennek működnie kell

   
tomtom - Tag | 4 hsz       Online status #80002   2008.01.20 13:23 GMT+1 óra  
Elmozdulás az már megvan, az elforgatás pedig a quadra merőleges vektor körül lenne, ami ugye a kamera felé mutat, csak nemtudom hogyan kellene megírni.

"kapott csúcsokra hajtod végre a forgatást." - arra gondolsz hogy a quad koordinátáit forgassam el?

glBegin( GL_QUADS );
glTexCoord2f(0,0); glVertex2f(-p->size,-p->size); // <-- it forgassak?
....
glEnd( );

Egyébként azért akarom elforgatni mert jól néz ki sztem

   
Birmacher - Törzstag | 516 hsz       Online status #80001   2008.01.20 13:14 GMT+1 óra  
A kamera felé nézést, azaz billboardingot ha már meg tod valósítani, akkor először azt hajtod végre, majd a kapott csúcsokra hajtod végre a forgatást.
( Feltéve ha a forgatáson a kamera felé néző quad-ra merőleges síkon veszed a forgatást, különben nincs túl sok értelme )

Bár igazán nem értem, minek egy részecske rendszerbe külön fogást belevenni, inkább elmozdulás kéne sztem

( remélem jól értettem a kérdést )

   
tomtom - Tag | 4 hsz       Online status #80000   2008.01.20 12:36 GMT+1 óra  
Üdv.
Remélem jó helyre írok :-)

Egy részecske rendszert szeretnék leprogramozni, a részecskéket egy quadra rajzolom, ami mindig a kamera felé néz.. Ez működik is de amikor a quadot el akarom forgatni, úgy hogy továbbra is a kamera felé nézzen akkor forog minden felé és nem a kamera felé néz. A kérdésem az lenne hogy hogyan tudom megoldani hogy forogjon is, meg a kamera felé is nézzen a quad.

c++/opengl

Thx!

   
gaborlabor - Moderátor | 4449 hsz       Online status #79894   2008.01.18 11:57 GMT+1 óra  
Sikerült, köszönöm szépen!

   
syam - Törzstag | 1491 hsz       Online status #79857   2008.01.17 12:04 GMT+1 óra  
ez igy egyszerü
full screen additiv blend és kész vagy - ha csak ez a feladat
alias aalberik
   
gaborlabor - Moderátor | 4449 hsz       Online status #79826   2008.01.17 06:43 GMT+1 óra  
Igen, ilyesmit szeretnék, köszönöm.
De nekem végülis elég lenne egy sokkal egyszerűbb progit összedobni. A lényeg, hogy egy ilyet meg tudjon jeleníteni:
http://www.gameus.de/content/produkte/seed_it/help/images/rgb.jpg
(Nekem jó négyzetekkel is, vagy bármivel)
Tehát rajzolok 3 polygont 2d-s vetítéssel, azok 1-1 alapszínnel vannak kitöltve, mozognak, és ahol fedik egymást ott láthatjuk az additív színkeverés működését.

Próbálkozom...

   
syam - Törzstag | 1491 hsz       Online status #79823   2008.01.17 05:44 GMT+1 óra  
ahoi,

ha jol sejtem erre gondolsz: http://en.wikipedia.org/wiki/Image:RGB_illumination.jpg

most, h csináltam egy kezdetleges raytracert a köv. módon oldanám meg: külön tárolnám a szin intenzitást és alapszínt( az alapszint normalizálással állítom elő a hossza pedig az intenzitása); a normalizált szineket összeadom és az intenzitások összegével visszaosztom; ehhez viszont az kell, h egyszerre minden fény érje az adott pontot...

az eredmény szerintem hasonló lenne az additiv szinkeveréshez
alias aalberik
   
gaborlabor - Moderátor | 4449 hsz       Online status #79761   2008.01.16 03:02 GMT+1 óra  
Üdv.

Olyan programot szeretnék írni, ami az RGB additív színkeverést demonstrálja.
Tehát az RGB színkörhöz hasonlót szeretnék kirajzolni.
OpenGL segítségével ezt hogyan lehet a legegyszerűbben megvalósítani?
Elméletre gondolok... Már kísérletezgettem vele, de sehogy nem jött össze.

   
gaborlabor - Moderátor | 4449 hsz       Online status #78094   2007.12.29 04:27 GMT+1 óra  
Köszi, akkor megpróbálom így! Végülis, maximum nagyon lassú lesz. De egy próbát megér, thx.

   
proof88 - Törzstag | 530 hsz       Online status #78071   2007.12.28 17:25 GMT+1 óra  
Kisebb mipmap szinteket így érsz el:
bebindeled a textúrát, aminek N. szintje kell, aztán
glGetTexImage(GL_TEXTURE_2D, N., GL_RGBA, GL_UNSIGNED_BYTE, pixeldata);
természetesen a paramétereket megváltoztatod úgy, ahogy kívánod. pixeldata mutató által mutatott területre kapod meg a textúra N. szintjét (nem tudom, hogy akkor is működik-e, ha csak 0. szint van és mondjuk a 2.-at kéred, de működhet, akár le is generálhatja...)

Őőő belezavarodtam. Azt hiszem, nem tudok olyan megoldást mondani, ami ne használná a rendszermemóriát kép tárolására.
   
gaborlabor - Moderátor | 4449 hsz       Online status #78046   2007.12.28 13:54 GMT+1 óra  
Akkor valamit nagyon nem értek.

"Legyen 2 textúrád. Az egyik a nagy, 1024x1024-es, ide rendereled EGYSZER a képet a viewport állítással, lekéred a pixeleket, aztán vagy legenerálod belőlük gluBuild2DMipmaps() használatával a mimap szintjeit és onnan kopizod a változó méretű mapeket egy másik textúra 0. szintjére, vagy a viewport állítás utáni textúrába renderelés után lekérheted egyből a kisebb mipmap szintet, ha be van kapcsolva az automatikus mipmap generálás (ami nem csak automatikus, de hardveres is)."

Tehát: Van 1 textúrám, amibe glCopyTexImage2D-vel elmentem a képet 1024x1024-ben (viewportot nem kell állítani, mert 1024*768-at használok). És azután?
A textúrából csináljak mégegy textúrát, de azt már a gluBuild2DMipmaps-szel? Azt hogyan? Ez a fgv. is kliens memóriaterületről kéri be a pixeladatokat, mikor textúrát csinál, tehát előtte le kéne másolnom az egész nagy képet (a glReadPixels-szel), hogy aztán legyen belőle egy mipmapeket is tároló textúrám. Azután pedig a mipmap szintek közül kéne kiválasztanom egy kisebbet, és abból megint csinálni egy textúrát a glTexImage2D-vel? Ez már végképp lelassítaná az egészet. Ráadásul nem is tudom, hogy hogyan lehet elérni a kisebb mipmap szinteket.

   
proof88 - Törzstag | 530 hsz       Online status #78040   2007.12.28 13:36 GMT+1 óra  
Konkrétan glGetTexImage2D()-re gondoltam, de az is szerver-kliens... tudom, hogy lassítja, ezért is javasoltam inkább az extension használatát... bár az se a leggyorsabb lesz, de jobbat nem tudok.
   
gaborlabor - Moderátor | 4449 hsz       Online status #78004   2007.12.28 12:47 GMT+1 óra  
"lekéred a pixeleket"

A glReadPixels()-re gondolsz? Az szörnyen lelassítja, mert szerver-kliens memória közötti másolgatás...

   
proof88 - Törzstag | 530 hsz       Online status #78001   2007.12.28 12:23 GMT+1 óra  
A gluBuild2DMipmaps szoftveresen csinálja, ha extensiont használsz, akkor az hardveresen* fog működni (tehát gyorsabb lesz).
Legyen 2 textúrád. Az egyik a nagy, 1024x1024-es, ide rendereled EGYSZER a képet a viewport állítással, lekéred a pixeleket, aztán vagy legenerálod belőlük gluBuild2DMipmaps() használatával a mimap szintjeit és onnan kopizod a változó méretű mapeket egy másik textúra 0. szintjére, vagy a viewport állítás utáni textúrába renderelés után lekérheted egyből a kisebb mipmap szintet, ha be van kapcsolva az automatikus mipmap generálás (ami nem csak automatikus, de hardveres is).

Huhh, remélem, érthető voltam.

* a hardveresen az remélhetőleg hardveres is jelent, mert attól, hogy egy adott implementáció exportál egy adott extension stringet, még nem biztos, hogy hardveresen támogatja is azt. Előfordul, hogy exportálva van egy extension string, tehát az implementáció úgy tesz, mintha támogatná, de csak szoftveresen megy a dolog, és ezt úgy vesszük észre, h pl. gyorsulást várunk a dologtól, de nem gyorsul ... még lassulhat is kicsit. Gondolom ezt azért szokták csinálni, hogy minél nagyobb legyen a támogatottság mértéke, mivel jópár játék, ami OGL-re épül, alapból megnézi miket támogat a kártya, és hát, esetleg nem fut, ha valami nincs támogatva.
   
gaborlabor - Moderátor | 4449 hsz       Online status #77618   2007.12.28 04:13 GMT+1 óra  
Én a gluBuild2DMipmaps() fgv. segítségével készítek automatikusan mipmapokat. De a gond ott van, hogy mikor kirajzolok egy textúrázott poligont, akkor a rendszer automatikusan dönti el, hogy melyik mipmap szintet húzza rá. Ha pl nagyon közel van a nézőponthoz, akkor a legnagyobb felbontásút fogja ráhúzni, nem tudom én szabályozni, hogy egy kisebbet tegyen rá.

   
proof88 - Törzstag | 530 hsz       Online status #77616   2007.12.28 03:50 GMT+1 óra  
Hmm, 97-es extension van erre: http://oss.sgi.com/projects/ogl-sample/registry/SGIS/generate_mipmap.txt
Ez automatikusan generáltatja a mipmap-eket, elvileg már a TNT is tudta, kérdés, hogy milyen sebességgel. Egy 1.3-as kártya szerintem biztosan tudja. Elvileg minden változáskor legenerálja az új mipmap szinteket. Szóval van egy 1024x1024-es textúrád, ahol be van kapcsolva ez a dolog, és bármikor, ha megváltoztatod, automatikusan meglesznek a mipmap-szintek, és akkor azokat már le is kérheted. glGetTexImage2D() vagy hasonló függvény van erre.
   
gaborlabor - Moderátor | 4449 hsz       Online status #77615   2007.12.28 03:39 GMT+1 óra  
De ha mipmapokat gyártok, akkor utána az OpenGL magától választja ki, a távolság függvényében, hogy melyik mipmap szintet használja. Ha magam tudnám elérni az egyes szinteket, tökéletes lenne.
Ennek utánanézek, hátha megoldható...

   
Hacker - Törzstag | 567 hsz       Online status #77611   2007.12.28 02:20 GMT+1 óra  
Használj mipmapokat erre a célra. Bár enm tudom pontosan, hogy lehet-e, de szerintem meg lehet oldani.
No [img] !
Programozz ne háborúzz!!!!

   
gaborlabor - Moderátor | 4449 hsz       Online status #77571   2007.12.27 12:48 GMT+1 óra  
Köszi a választ.
Egy kicsit kísérletezgettem vele, és én is arra jutottam, hogy nem a meglévő textúrába rakja, hanem a textúrát átméretezi akkorára, amekkora területet a glCopyTexImage-dzsel menteni akarok.
Ez nekem most nem jó.
Én azt szeretném elérni, hogy van egy kirenderelt képem, és azt tetszőleges felbontásban tudjam textúrába menteni. Ezt eddig úgy sikerült megoldanom, hogy: glViewport()-tal állítottám át, hogy az ablakj mely részébe rendereljen. Pl ha nekem 512*512-es textúra kellett akkor a scene-t először 512*384-be rendereltem és azt mentettem textúrába, majd pedig visszaállítottam és kirajzoltam a textúrát.
Ez így egy textúra esetén még elfogadható.
De mi van akkor, ha én a kirenderelt képet el szeretném menteni először egy normál (1024*1024) méretű textúrába, minőségromlás nélkül, de ugyanebből kell nekem egy 512*512-es is meg egy 256*256-os is?
Ahány textúra kell, annyiszor kell a viewportot átméreteznem, és az egész jelenetet újrarajzoltatni, és textúrába menteni?
Az nagyon lassú lenne. A gond az, hogy 1.3-as ogl-t támogat a vga-m, így fbo-t sem tudok használni, pedig a neten találtam rá példakódot, hogy azt hogyan lehet átméretezni.

   
proof88 - Törzstag | 530 hsz       Online status #77570   2007.12.27 12:38 GMT+1 óra  
Üdv!

A kódodra nézve azt gondoltam, hogy valami access violationt kéne kapnod rá, mert túllősz a memóriaterületen. A dokumentációt olvasva viszont már érthető a viselkedése a kódodnak:
,,glCopyTexImage2D defines a two-dimensional texture image with pixels from the current GL_READ_BUFFER." - tehát tulképpen CSINÁL egy MEGADOTT MÉRETŰ textúrát az aktuális buffer alapján. És ezután már az 512x512-es textúrának 1024x1024-es lesz a mérete. Tehát valószínűleg így működik jól. Azonban azt gondolom, hogy ha nagyobb az utólag megadott méret, mint a létrehozáskor használt méret, akkor sebességügyi problémák adódhatnak. Szóval legyen inkább nagyobb buffer, aminek nem mindig a teljes méretét használod.
   
gaborlabor - Moderátor | 4449 hsz       Online status #77553   2007.12.27 09:19 GMT+1 óra  
üdv
Ha létrehozok egy textúrát így:
Kód:
unsigned char *mem;
if( !( mem = (unsigned char*)calloc(512*512*4, sizeof(unsigned char))) )
exit(0);
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexImage2D(GL_TEXTURE_2D, 0, 4, 512, 512, 0, GL_RGBA, GL_UNSIGNED_BYTE, mem);
free(mem);

akkor ugye egy olyan textúrám lesz, mai 512*512 méretű.

Ha ezek után én ebbe így másolok képet:
Kód:
glBindTexture(GL_TEXTURE_2D, texture);
glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 0, 0, 1024, 1024, 0);

Akkor az 1024*1024 es kép le lesz kicsinyítve 512*512-re, és ezek után kerül bele a textúrába?

Ha igen, akkor ha a legelején kisebb méretű textúrát hozok létre, pl 128*128-asat, és abba másolom a képet, majd a textúrát kirajzolom, akkor ugye minőségromlást kéne tapasztalnom, mert jobban le kellett kicsinyíteni az 1024*1024-es képet?
De nem így van
Mindegy, hogy mekkora textúrát készítek a prog elején, mindig ugyanúgy néz ki.
Még 2*2-essel is próbáltam és néhány paca helyett mégis a rendes képet látom
A textúra kirajzolása előtt persze törlöm a színbuffert, úgyhogy semmi mást nem látok, csak azt ami a textúrában van. Ezért nem értem....

   
beast - Törzstag | 1241 hsz       Online status #77026   2007.12.20 04:38 GMT+1 óra  
Na, ezt akartam csak:


Ezt a hozzászólást beast módosította (2007.12.20 06:50 GMT+1 óra, ---)

   
danó - Tag | 13 hsz       Online status #77024   2007.12.20 03:49 GMT+1 óra  
egyre jobb thx!
   
gaborlabor - Moderátor | 4449 hsz       Online status #77019   2007.12.20 03:05 GMT+1 óra  
hi
én nem igazodok ki a képen
viszont a rajzolásnak így mennie kell:

glBegin(GL_QUADS);
// bal alsó sarok koordinátái, pl:
glVertex2i(0, 0);
// jobb alsó sarok koordinátái
glVertex2i(500, 0);
// jobb felső sarok
glVertex2i(500, 100);
// bal felső sarok
glVertex2i(0, 100);
glEnd();

QUAD_STRIP-et felesleges ilyenkor használni, az másra való....
Alapból a poligonnak mindkét oldalát kirajzolja, mert nincs bekapcsolva a back face culling. Ilyenkor mindegy, hogy az óramutató járásával megegyező, vagy éppen ellenkező irányban adod meg a vertexek koordinátáit, és az is mindegy, hogy melyik sarokból indulsz.
Ez persze lassabb, mintha a hátsó oldalak megjelenítését kikapcsolnád.
Olyankor meg kell mondani az OpenGL-nek, hogy melyik az első oldal:
glFrontFace(GL_CCW); vagy glFrontFace(GL_CW);
CCW = Counter clock wise, tehát óramutató járásával ellenkező, a CW óramutató járásával megegyező irányt jelent.
Miután az OGL-nek megmondtad, hogy melyik az első lap, utána bekapcsolhatod, hogy a poligonoknak melyik oldalát dobja el (ne rajzolja ki):
glCullFace(oldal);
oldal lehet: GL_BACK, GL_FRONT és GL_FRONT_AND_BACK
aztán pedig glEnable(GL_CULL_FACE);
Szerintem általában a CCW szokott lenni az első oldal, és a hátsó lapok megjelenítését kapcsolják ki. Viszont ilyenkor tényleg figyelni kell a körbejárási irányra....

   
danó - Tag | 13 hsz       Online status #77002   2007.12.19 12:15 GMT+1 óra  
értem köszi...
   
Joga - Törzstag | 1791 hsz       Online status #76988   2007.12.19 08:50 GMT+1 óra  
Jó sorrendben kell megadni a koordinátákat, mert OpenGLkét háromszögre bontja úgy, hogy feltételezi a helyes sorrendet, és azt, hogy konvex
(ಠ ›ಠ) Stewie!

   
danó - Tag | 13 hsz       Online status #76987   2007.12.19 08:44 GMT+1 óra  
Hali!
Nem tudja valaki, hogy mér van az, hogy amikor akarok rajzolni egy téglalapot QUADS-al akkor az egyik oldalt benyomja, aztán ugyanazt kirajzoltatom QUAD_STRIP-pel akkor pedig normálisan kirajzolja. Ezután akarok még egy téglalapot csinálni az előző mellé QUAD_STRIP-pel
de akkor is benyomja az oldalát de ha ugyanezt ki akarom rajzoltatni QUADS-al akkor meg simán működik?
itt egy kép a jelenségről...
Előre is köszi a segítséget!
   
Joga - Törzstag | 1791 hsz       Online status #76609   2007.12.13 09:56 GMT+1 óra  
Semmi sem okoz gondot, csak rendesen meg kell tanulni használni...
(ಠ ›ಠ) Stewie!

   
beast - Törzstag | 1241 hsz       Online status #76608   2007.12.13 09:55 GMT+1 óra  
Viszon a Paul Nettle féle memory manager-rel (ami teljesen igyenes) a leak-ek sem okoznak gondot.

   
ibax - Tag | 154 hsz       Online status #76607   2007.12.13 09:53 GMT+1 óra  
pedig egy jó öreg tanárom azt mondta, hogy a programozás során a legtöbb problémát a mutatók és a cím operátorok helytelen használata okozza...

ezért például jobb a java, ott ezt már megoldották .... kiszedték belőle!
   
Joga - Törzstag | 1791 hsz       Online status #76605   2007.12.13 09:46 GMT+1 óra  
Én mutatók nélkül élni se tudnék
(ಠ ›ಠ) Stewie!

   
Hacker - Törzstag | 567 hsz       Online status #76604   2007.12.13 09:44 GMT+1 óra  
Unsafe módban aki szeret az pointerezhet. Amúgy nem nagy ördöngősség a pointer és így szerintem a programozó jobban gépközelinek érzi a nyelvet. A gond a memory leak-ekkel van.
No [img] !
Programozz ne háborúzz!!!!

   
Joga - Törzstag | 1791 hsz       Online status #76602   2007.12.13 09:30 GMT+1 óra  
C#-ban is vannak csillagok....Vagy annyira leegyszerűsítették, hogy ott szorzás sincs?
(ಠ ›ಠ) Stewie!

   
psyche - Tag | 36 hsz       Online status #76601   2007.12.13 08:55 GMT+1 óra  
hát én pont a pointerek miatt szeretnék áttérni c#-ra!
el nem tudom mondani mennyire utálom a csillagokat!

   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] > 51 < [55] [60] [65] [70] [75] [80] [82]