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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2188
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]
~Cre@tine~> - Tag | 702 hsz       Online status #81691   2008.02.15 03:36 GMT+1 óra  
Psyche Builder.

Ezt a hozzászólást ~Cre@tine~> módosította (2008.02.15 03:41 GMT+1 óra, ---)

   
psyche - Tag | 36 hsz       Online status #81690   2008.02.15 02:41 GMT+1 óra  
már most lehet gondolkodni azon, hogy mi legyen a neve.
lehet kicsit kreatívabb is, mint: game maker,fps creator..stb.

   
~Cre@tine~> - Tag | 702 hsz       Online status #81666   2008.02.14 03:46 GMT+1 óra  
Igaz, hogy én mindig az .ISO változatot használtam eddig, hogyha újra kell telepíteni a rendszert, vagy valami, ne kelljen újra letöltögetni mindent. Akkor a netes telepítőben lehet ez benne sincs.

Jó nagy fába vágtad a fejszét. Arra vigyázz, hogy az OpenGL kezdőknek könnyű, de a tanulási görbéje más, mint mondjuk az XNA-nál, ahol nem nehezebb egy textúrázott, shaderes 3D modellt se betölteni, mint egy négyzetet. Egy időben dolgozgattam benne, nekem annyira nem jött be, hátha neked igen.

   
psyche - Tag | 36 hsz       Online status #81665   2008.02.14 03:33 GMT+1 óra  
kosz, hogy a felhívtad a figyelmem MaNiAc cikkére. elfogom olvasni.
a sünis könyv megvan. átnézem azt is. csak az ott használt matematikát kéne jobban megértenem.
hát nem tudom, de én amikor telepítettem a VC# Expresst, akkor .NET nélkül fel se rakja.
jelenleg egy ilyen: http://www.silentworks.hu/index.php
progi tervezésén dolgozom. lehet elötte kidobok vmi egyszerü lovoldozos fpst.
ha vmi érdemlegeset csinálok akkor felteszem ide is.

   
~Cre@tine~> - Tag | 702 hsz       Online status #81664   2008.02.14 03:18 GMT+1 óra  
Idézet
psyche :
itt az egyik legegyszerűbb technika arra, hogyan üzemeljük be a Taot C# alatt.
http://saweb.atw.hu/opengl.html


Na itt már végre látszik mit csináltál. Nem kötözködés képp, de azt a részt töröld ki, hogy .NET 3.5 letöltése/telepítése, mert fölösleges, ha a VC#-t is felrakod, mivel a telepítő CD, vagy DVD alapból tartalmazza azt.

Ezt pedig teszteld le. precedens
Lehet .NET 3.5-nél mindegy.
Kód:
        [STAThread]
        static void Main()


Ha megvan a sünis, könyv a benne lévő ogl progikat 1-1 ben fel tudod használni Tao-val is. Sok sikert! (Be is regeled a projectet, ha lesz valami?)

   
beast - Törzstag | 1241 hsz       Online status #81662   2008.02.14 02:58 GMT+1 óra  
Jah, bocs, elnéztem.
Azért nem véletlen, hogy pl. Doom3 engines játékokat is mind újra kell inditani egy beállitás elfogadásához...
Egyébként ez a sharelists-es megoldás amolyan félhivatalos, szóval...
S mivel nem új dologról van szó, gondolom van rá rendes implementáció nvidia és ati részről is.
Tegyél egy próbát, teszteltesd különböző konfigokon és kiderül mennyire életképes.

   
proof88 - Törzstag | 530 hsz       Online status #81654   2008.02.13 15:03 GMT+1 óra  
Nem értem, miért kell átmeneti RC. Nem elég a régi meg egy új?
A nagy hsz-emben írtam:
Idézet
Amit most nézegettem, a wgl-es rc manipuláló függvények. Sikerült működőképessé tenni az új rc-vel való dolgozást úgy, hogy wglCopyContext(régi_rc, új_rc, GL_ALL_ATTRIB_BITS), aztán wglShareLists(régi_rc, új_rc), és törlöm a régi_rc-t.

Szóval működött az, amit csináltam, a gondom az egésszel az MSDN-en leírt, számomra aggasztó mondat:
Idézet
All rendering contexts of a shared display list must use an identical pixel format. Otherwise the results depend on the implementation of OpenGL used.

Ez alapján a régi és az új RC-nek is megegyező pixel formátumot kell használnia. Nálam ez nem teljesül, mivel az új pixelformátum annyiban tér el a régitől, hogy kérek benne sample buffereket.
   
beast - Törzstag | 1241 hsz       Online status #81653   2008.02.13 14:27 GMT+1 óra  
Nop, a megoldás a wglShareLists.
A lényeg:
- van egy opengl contexted
- ha cserélni akarod, akkor hozz létre még egy átmeneti context-et, lehetőleg _ugyanazzal_ a pixel formátummal (legjobb ha minden context létrehozáskot letárolod a pixelformatdescriptort)
- mielőtt még belőnéd aktuális contextre: wglShareLists(oldRC, newRC) és ez után wglMakeCurrent
- létrehozod az új pixelformátumot, contextet
- ha megvan a vadiúj context, akkor megint wglShareLists(), most az első paraméter lesz az átmeneti rc, a második az új rc (nem a temp!)
- wglMakeCurrent új context-tel
Ne felejtsd törölni az átmeneti context-et.
Nálam működik, viszont az összes ogl állapotot újra be kell állitani, ami az előző kontextusban volt...

   
beast - Törzstag | 1241 hsz       Online status #81650   2008.02.13 12:11 GMT+1 óra  
Én nem tartom megoldásnak, hogy bent tarts annyi adatot a memóriában.
A téma érdekes, én is utána nézek.

   
proof88 - Törzstag | 530 hsz       Online status #81649   2008.02.13 12:05 GMT+1 óra  
Amúgy nem akarom benn tartani a memóriában a textúrákat, ezt lehet állítani textúránként, de kötelezően csak ilyen esetekre, NEM! Ha van 100 db textúra, amik beleférnek a VRAM-ba, akkor foglaljanak el helyet a rendszermemóriában is, csak azért, hogy ilyen esetekben gyorsabb legyen a töltés? Jobb ötletem van: inkább visszakérem a textúrákat a VRAM-ból, majd visszatöltöm őket új contextben... Sajnos a mipmap-szinteket is mind kell, mert az 1 dolog, hogy lehetne generáltatni őket, de ha pl DDS-ből származott a textúra, előre meghatározott mipmap-szintekkel, akkor ott ragaszkodni kell azokhoz.
Rájöttem hogy ez inkább engine-fejlesztés vagy hasonló topic, de ha már itt kezdtem el tárgyalni, itt is fejezem be.
   
proof88 - Törzstag | 530 hsz       Online status #81648   2008.02.13 11:50 GMT+1 óra  
Nyilván, ha a kép adatokat a memóriában tartom, akkor viszonylag gyorsan újra tudom csinálni a textúrákat. Sőt, a textúrákat is le tudom kérni, és újakat létre tudok hozni belőlük az új contextben. Ez viszont bonyolultabb. Bár végül is, nem annyira. Na mindegy, majd megírom az eredményeket.
   
proof88 - Törzstag | 530 hsz       Online status #81647   2008.02.13 11:45 GMT+1 óra  
Ok, tehát D3D maga kezeli ezt. Bizony, én OGL-elben dolgozok, és pont azért akarom így csinálni, mert zavar, hogy D3D magától csinálja.
Na, mindenesetre megnézem h x textúrát mennyi idő újratölteni úgy, ahogy írtam...
Shaderes élsimításnál még nem járok.
   
beast - Törzstag | 1241 hsz       Online status #81644   2008.02.13 11:18 GMT+1 óra  
Viszont, ha shaderes volt az élsimitás, akkor nem is kellett semmit újratölteni...

   
beast - Törzstag | 1241 hsz       Online status #81643   2008.02.13 11:17 GMT+1 óra  
Ha jól tudom, DX-nél nem kell teljesen "lerombolni" a rendszert a multisample-hez, van egy device reset, ami a megadott struktúra szerint újraépiti. OGL-nél viszont teljesen újat kell hozzá létrehozni.
Viszont dx-nél is újra kell tölteni azokat az adatokat, amik a D3DPOOL_DEFAULT-tal lettek a memoriába pakolva.
Ha jól tudom, ha nem, javitsatok ki.

   
proof88 - Törzstag | 530 hsz       Online status #81636   2008.02.13 10:13 GMT+1 óra  
Ennyire bonyolultat kérdeztem vagy senkinek sincs kedve elolvasni, mert túl hosszú?
   
proof88 - Törzstag | 530 hsz       Online status #81505   2008.02.11 14:43 GMT+1 óra  
Üdv!

Az lenne a problémám, hogy a graf. motorommal szeretném megoldani a teljes újraindítás nélküli bekapcsolását az élsimításnak. OpenGL, multisampling AA. Ez azt jelenti, hogy ne csak a motor inicializálásánál lehessen megadni az MSAA-t, hanem menet közben is. Odáig eljutottam, hogy megy az élsimítás. Viszont textúrákkal szenvedek. XD
Részletesen: program inicializálja a motort, a motor csinál ablakot meg amúgy mindent ő kezel, a programnak objektumokat ad vissza (mutatók ugyebár osztálypéldányokra). A program betöltet pár textúrát, ezek mind objektumok lesznek, legyenek mondjuk tex1 és tex2.
A program meghívja a motor SetFSAA() függvényét, ami megpróbálna okosan cselekedni. Odáig eljut, hogy bekapcsolja az élsimítást... ehhez új ablak kell, aminek a DC-jéhez beállítja az új pixelformatot, aztán ehhez új RC is kell. Mivel új az RC, ide kéne hozni az előző RC-ből a textúrákat, etc. Újratölthetném a textúrákat a motor rutinjaival automatikusan, de akkor máshol lennének a memóriában, mint ahova tex1 és tex2 mutat, magyarul a programot nem tudjuk értesíteni, hogy elévült adat van nála. Megoldást jelenthet erre az, hogy spéci módon töltöm újra a textúrákat, tehát a textúra objektumaimmal töltetem újra önmagukat, így maradnak a pointerek, ez viszont macerás, mert figyelni kell minden olyanra, amit a program eddig kért, azaz LOD, tömörítési eljárás, mipmapek, etc... Ráadásul nem vagyok benne biztos, hogy ez a legnyerőbb és leggyorsabb megoldás.
Amit most nézegettem, a wgl-es rc manipuláló függvények. Sikerült működőképessé tenni az új rc-vel való dolgozást úgy, hogy wglCopyContext(régi_rc, új_rc, GL_ALL_ATTRIB_BITS), aztán wglShareLists(régi_rc, új_rc), és törlöm a régi_rc-t. Ezzel csak az a gondom, hogy egyáltalán nem látom túl biztosnak, hogy máshol is működik. MSDN-en azt olvastam, hogy:
,,All rendering contexts of a shared display list must use an identical pixel format. Otherwise the results depend on the implementation of OpenGL used."
Nálam pl. a 2 RC pixelformatja különböző, pont azért, mert az újabbat élsimításhoz használom. Szóval lehet, hogy másik driverrel/kártyával azt kapom, hogy nincsenek meg a textúrák, vagy kapok egy runtime errort.

Nektek erről az egészről mi a véleményetek? Mert pl NFS Most Wantedban az élsimítást játék közben lehetett állítani, és tök gyorsan, tehát nem sokat tölthetett újra - kivéve, ha a memóriában tartotta a textúrákat, meg egyebeket.

Persze, azt is csinálhatnám, hogy a program tölteti újra a textúrákat a motorral a hagyományos módon, és akkor megkapja a jó mutatókat, de pont az lenne a lényeg, hogy a motor maga intézze el a piszkos munkát.
   
psyche - Tag | 36 hsz       Online status #81502   2008.02.11 13:47 GMT+1 óra  
Tökéletesen igazatok van(orphy,hacker), de olyan egyszerű projectekkel dolgozom, hogy még felesleges a .NET-et belevonszolni. A cél, hogy az OpenGL programozás alapjait ismertesem és
mindenképp kell egy Win ablak, amit a legegyszerűbb Gluttal megoldani.
Amúgy a FreeGlut is platformfüggetlen.
Az "FPS Creator+Game Maker" keveréke progi ablakkezelése erősen .NET-es lesz, de ez nem
része a cikksorozatnak.

Ezt a hozzászólást psyche módosította (2008.02.11 15:03 GMT+1 óra, ---)

   
Hacker - Törzstag | 567 hsz       Online status #81466   2008.02.11 07:20 GMT+1 óra  
Idézet
Orphy :
Idézet
psyche :
itt az egyik legegyszerűbb technika arra, hogyan üzemeljük be a Taot C# alatt.
http://saweb.atw.hu/opengl.html




Hmmm,

látom GLUT-ot használsz hozzá.
Azért itt megjegyezném, hogy az alap Windows-ot is lehet használni, akár panelre renderelve is: ha nem szempont a gépfüggetlenség, akkor lehet érdemesebb azt használni - később könnyebb lesz pl tool-okat készíteni a játékhoz.

Érdemes végigtúrni a TAO-s példákat ezügyben, főleg a NeHe-seket.



De mivel maga a .NET is pont a platformfüggetlenség miatt lett kitalálva, így elméletileg ugyanúgy kellene futnia egy tao-s proginak Linuxon, mint Windows-on. Szóval én nem ajánlom a glut használatát taoban ha c# nyelven programozol.
No [img] !
Programozz ne háborúzz!!!!

   
beast - Törzstag | 1241 hsz       Online status #81462   2008.02.11 06:30 GMT+1 óra  
Idézet
Orphy :
Hmmm,

OpenGL alatt létezik valami olyasmi, mint a DirectX .fx file-ja?
Ha igen, akkor tudtok adni róla egy linket?

Köszi


Ha az fx a shader, akkor glsl (dx - hlsl), egyéb nincs.

   
Orphy - Törzstag | 1893 hsz       Online status #81461   2008.02.11 06:24 GMT+1 óra  
Idézet
psyche :
itt az egyik legegyszerűbb technika arra, hogyan üzemeljük be a Taot C# alatt.
http://saweb.atw.hu/opengl.html




Hmmm,

látom GLUT-ot használsz hozzá.
Azért itt megjegyezném, hogy az alap Windows-ot is lehet használni, akár panelre renderelve is: ha nem szempont a gépfüggetlenség, akkor lehet érdemesebb azt használni - később könnyebb lesz pl tool-okat készíteni a játékhoz.

Érdemes végigtúrni a TAO-s példákat ezügyben, főleg a NeHe-seket.
   
Orphy - Törzstag | 1893 hsz       Online status #81460   2008.02.11 06:20 GMT+1 óra  
Hmmm,

OpenGL alatt létezik valami olyasmi, mint a DirectX .fx file-ja?
Ha igen, akkor tudtok adni róla egy linket?

Köszi
   
psyche - Tag | 36 hsz       Online status #81447   2008.02.11 01:28 GMT+1 óra  
itt az egyik legegyszerűbb technika arra, hogyan üzemeljük be a Taot C# alatt.
http://saweb.atw.hu/opengl.html

   
syam - Törzstag | 1491 hsz       Online status #81361   2008.02.09 18:13 GMT+1 óra  
vagy perlin noise-zal generáltatsz texturát akár előre renderelve akár realtime:]

http://www.pcdome.hu/image.php?image=/gallery/415/image146.jpg&caption=Neverwinter%20Nights - itt is ilyet használtak real time
alias aalberik
   
Kristf - Törzstag | 125 hsz       Online status #81295   2008.02.09 10:15 GMT+1 óra  
Na oké még próbálgatom...

   
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 | 5448 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 | 5448 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 | 1291 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 | 1291 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.
   
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]