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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2185
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] [27]
Pretender - Törzstag | 2498 hsz       Online status #197731   2013.09.29 15:25 GMT+1 óra  
Igen, sajnos a deferred nem a leggyorsabb renderelők közé tartozik. De azért van előnye is. Persze, hátránya lehet, hogy több van, de könnyebb megcsinálni szépre

   
ddbwo - Tag | 1625 hsz       Online status #197730   2013.09.29 15:17 GMT+1 óra  
Én csak ezt csináltam, mert lassú nálam a deferred:

1. diffuse, depth, normal,
2. final lighting.
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 #197729   2013.09.29 14:56 GMT+1 óra  
Az egy kicsit más. Mármint, amit ott leírt, azt tudom én is.
Ez azért trükkös, mert két rendertargeten is átmegy, mire a shadingelt változat textúrába kerül.
Amúgy akkor szépen működik, ha a lighting rendertargetet 64 bitesnek választom. Csak az nyilván nem túl jó hatással van a sebességre...

Deferred shading: mindegyik passhoz tartozik egy-egy render target (gbuffer esetén MRT)
1. g-buffer: diffuse texture, normals, depth
2. lighting: normal, depth segítségével a lighting kiszámolása
3. combine: az eddigiek összerakása: gbufferből diffuse texture * lighting color

   
ddbwo - Tag | 1625 hsz       Online status #197728   2013.09.29 14:44 GMT+1 óra  
Asylumnál komplett korrekt leírás van. Ráadásul source-okat is szokott mellékelni.
---

Amúgy elvileg a végső képre kell ráadagolni. Legalábbis úgy csinálom.
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 #197722   2013.09.29 13:51 GMT+1 óra  
Adott egy ARGB8 (azaz 4 csatornás, csatornánként 8 bites, össz. 32 bites) render target / fbo.
Egy pass során kiszámolom a lightingot, és ezt a render target rgb csatornájában tárolom. Egy későbbi pass során kiolvasom ezeket az értékeket, majd azzal megszorozva kapom meg a végső képet.

Probléma: Ha mondjuk van egy directional lightom, meg 2 point light elég közel egymáshoz, akkor az rgb értékek igen csak magasra képesek szaladni (mivel ugye összeadódnak). Nyilván azt várná az ember, hogy akkor ott jó fényes lesz. Csakhogy mivel [0,255] intervallumú csatornákba lesz kimentve a szín, ezért azt szépen fogja, és "megvágja", ezért nem "túl világos" lesz, hanem inkább olyan fakó.


Kérdés: Valahogy be szokták packelni, és amikor a backbufferbe megy a renderelés (tehát már túl a postprocessingen meg mindenfélén), akkor számolnak valamit vissza?

Amúgy deferred shadinges a cucc.

szerk.:
Valami hasonló lenne szerintem az elvárt. Akkor kapok ilyen képet, ha a kiszámolt, textúrába mentett lighting tartalmat a backbufferbe renderelem egy újabb pass segítségével. (Tehát akkor lehet, hogy nem is ott van a probléma?)

   
ddbwo - Tag | 1625 hsz       Online status #195945   2013.07.08 19:10 GMT+1 óra  
Elképzelve furcsán jönne ki. Valami gumi szuperhős. Ha kis helyen spárgázik, az egész teste bevékonyodik.

Van pár tippem hírtelen:

- Animáció legkiterjettebb formájára ellenőrzés, ha megakadna az animáció, akkor eleve le sem játsza és nem történik meg az esemény. (min-maxok közül a legkisebb, legnagyobb)
- Animációt perpixel ellenőrzi, ha megakadna, visszatekeri az animációt és az esemény megáll.
- perpixel ellenőrzés, megpróbálja elhelyezni a karaktert, ha nem sikerül, animáció megáll.
- perpixel ellenőrzés minden frame-re, ha nem férne el, eleve le sem játsza és nincs esemény
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
   
versio - Tag | 659 hsz       Online status #195944   2013.07.08 18:26 GMT+1 óra  
vertex shaderrel ujraszamolod a min,max koordinatakat, problem solved
   
Pretender - Törzstag | 2498 hsz       Online status #195942   2013.07.08 17:51 GMT+1 óra  
És ha mondjuk az álló Sanyika ott van a fal mellett, és benyomja a spárgát? Odébbtolja magát?

   
zeller - Törzstag | 464 hsz       Online status #195941   2013.07.08 17:48 GMT+1 óra  
Ez egy elvi felvetes volt
De mondjuk egy spargazo sanyika meg egy allo sanyika kozott latvanyos kulonbseg van, barmikor.

   
Matzi - Szerkesztő | 2519 hsz       Online status #195940   2013.07.08 17:33 GMT+1 óra  
Mi az a játék, amihez ilyen változó méretű spriteok kellenek?
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
zeller - Törzstag | 464 hsz       Online status #195938   2013.07.08 17:26 GMT+1 óra  
A "kelloen jo" viszont egyeb limitaciokat hoz be. Elsosorban a merettartomanyra, meg valamennyire arra is, hogy mennyire kell meredek, vagy inkabb lapos legyen a meretvaltozasi fuggveny

   
Matzi - Szerkesztő | 2519 hsz       Online status #195935   2013.07.08 16:45 GMT+1 óra  
Erre nincs jó megoldás. Az nem jó, ha átméreteződik a collider, mert bele fogsz lógni valamibe, amibe korábban nem. És feloldani esem triviális. Ilyenkor egyszerűen vesznek egy kellóen jó befoglaló síkidomot, és mindig azt használják.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
zeller - Törzstag | 464 hsz       Online status #195934   2013.07.08 16:36 GMT+1 óra  
Szoval allitanad a collider meretet attol fuggoen, hogy melyik frameben vagyunk? Vegulis nem sok overhead, ha szamitas szempontjabol nezzuk, viszont az eredmeny a leheto legjobb, szoval jogos.

Visznt ez azt varna el, hogy kb pixelre pontosan ott vagjunk, ahol a karakter veget er, de ha egyforma meretu kepkockakat szeretnek, csak benne a valos grafika merete valtozo, akkor mi van?

   
Pretender - Törzstag | 2498 hsz       Online status #195931   2013.07.08 16:12 GMT+1 óra  
Animáláshoz ismerni kell az adott keyframeben lévő sprite méretét, nem? Az miért nem jó?

   
zeller - Törzstag | 464 hsz       Online status #195927   2013.07.08 15:13 GMT+1 óra  
A kerdes a kovetkezo.
Van egy karakter animacios sprite, es nem minden fazisa azonos meretu.
Hogyan valasztod meg a collidert az objecthez, hogy barmely fazisban is utkozik, se ne logjon bele, se ne legyen az utkozes 18 csillo kilometerre a vizualis reprezentaciotol?

   
Geri - Törzstag | 2185 hsz       Online status #195289   2013.06.19 20:12 GMT+1 óra  
az ilyen futtassunk a háttérben asszimetrikusan jellegű dolgoknak max praktikussági (ahogy mondtad is, ne akadjon a kép, amíg megy a töltési csík) jellegű oka van, effektíven max 2 processzormagig lehetett használni, de fölötte ez már nem sokat ér. ha ki akarja az ember használni a 4, 6, 8, 12, 16, 32, 64, és a jövőben még ki tudja, hogy hány magos rendszereket, akkor magát a munkafolyamatot kell belülről, monolitikusan párhuzamosítani

   
Asylum - Törzstag | 5440 hsz       Online status #195285   2013.06.19 18:38 GMT+1 óra  
Renderelést is lehet, de értelme nem sok van (hacsak nem akarod háttérben is futtatni).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Geri - Törzstag | 2185 hsz       Online status #195284   2013.06.19 18:36 GMT+1 óra  
ai-t, hálózatot, fizikát gyönyörűen lehet monolitikusan N darabra párhuzamosítani (asylum, régebben azt mondtad, hogy a renderelést is)

nekem az új enginemben szinte minden minimum 8 szálon, maximum 640 szálon fut

   
Asylum - Törzstag | 5440 hsz       Online status #195282   2013.06.19 18:27 GMT+1 óra  
Azért fölösleges külön szálra tenni, hogy az idö 90%-ában aludjon. Hálózatot mindenképpen külön szálra.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
bolyzsolt - Törzstag | 607 hsz       Online status #195279   2013.06.19 16:36 GMT+1 óra  
Én a kis frameworkömben Allegro-mintára külön szálra tettem a timereket (egy szál) illetve az ablakokat (mindegyiknek külön). Az ablakokat Windows-on így kicsit átláthatóbban lehet kezelni, a timerek meg logikájukból adódóan (függetlennek kell lenniük és altatják a threadet) külön szálra kívánkoznak.

   
__z - Tag | 69 hsz       Online status #195277   2013.06.19 16:11 GMT+1 óra  
Hálózati funkciókat esetleg?

   
Asylum - Törzstag | 5440 hsz       Online status #195276   2013.06.19 15:41 GMT+1 óra  
Content betoltesen kivul szerintem semmit (azt is csak az emlitett esetben). Ha csak foszalon futtatva valami lassu azt optimalizalni kell...

En inkabb az ilyen "fel-parhuzamos" megoldas hive vagyok: a game logic mondjuk egy 10 fps-es timerrol fut, a rendering meg ahogy tud.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2519 hsz       Online status #195274   2013.06.19 14:51 GMT+1 óra  
Úgy kell definiálni a domaineket, hogy függetleníthetőek legyenek. Például a fizikát szétosztod téreflosztás szerint egységekre. Vagy az AI-t. Egyébként nehéz párhuzamosítani a játékokat, mert túlságosan összefüggnek a részek.

A resource loading azért jó párhuzamosítva, mert addig is responsive a gui (nem fagy be a csík), és ha van fallback, akkor folyamatosan be tudsz hozni új contentet töltőképernyő nélkül. Lásd Rage és a magetexture.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
zeller - Törzstag | 464 hsz       Online status #195273   2013.06.19 14:36 GMT+1 óra  
Mi az amit erdemes konkurrensen programozni egy engineben? Koncepcionalis, nagylepteku szinten.
User inputot jo esellyel igen (bar SDL-t hasznalok, az alapbol megteszi).
Resource loading szinten, de itt mar van nemi blokkolas, mert a megjelenitese a resourcenak mindenkeppen csak a betoltes utan lehetseges.
Viszont mas szempontbol a funkcionalisan fuggetlen egysegek megtalalasaval gondom van. Pl
a fuggetlen gameobjectek fizikai szimulaciojat lehetne parhuzamositani, de honnan tudod melyek lesznek fuggetlenek? A csoportositas nagyobb overhead lehet, mint a cpu-k kihasznalasa.

Ilyen elvek szerint keresnek utmutatast.

   
Pretender - Törzstag | 2498 hsz       Online status #194791   2013.06.08 11:40 GMT+1 óra  
Akkor tulajdonképpen valamilyen (fa) adatszerkezetbe (quadtree, bintree, octree, akármi) bepakolom a chunkokat, és a megfelelő lod-szintűt rajzolom ki.
Tárolni hogy szokták? Az összes chunk vertexét mentik ki egy fileba? Rendereléskor mindegyik chunk egy külön VBO, és akkor csak vagy rajzolom, vagy nem?
Jópofának tűnik, nem tudom mennyire számításigényes. Nem kell, hogy generált legyen, inkább az artist tudja valahogy megrajzolni a terraint.

   
Matzi - Szerkesztő | 2519 hsz       Online status #194790   2013.06.08 11:31 GMT+1 óra  
Chunked LOD + köd. Még az oblivion is ezt használta, csak ott nem volt akkora köd, hogy tényleg el lehessen látni messze.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Pretender - Törzstag | 2498 hsz       Online status #194789   2013.06.08 10:39 GMT+1 óra  
Főleg régi játékokban hogy rendereltek nagyobb terepeket? Ott vannak pl. a régi mmo-k (wow és társai), ahol ha hatalmasnak nem is mondható, de azért egy nagyobb belátható terrain van ott. Simán csak kevés poligonból álltak, vagy mit használtak?

Érdekes kérdés még számomra, hogy hogyan legyen letárolva a terrain, ha mondjuk elég nagy terepekről van szó? Plusz ugye textúra sem ártana hozzá.

   
Asylum - Törzstag | 5440 hsz       Online status #194365   2013.05.30 18:41 GMT+1 óra  
2D-ben nem tudsz csontozni, hacsaknem az valójában egy 3D modell (pl. egy hellknight-al játszahtó 2D platformjátékot simán meg lehet csinálni).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #194355   2013.05.30 14:49 GMT+1 óra  
Ha felbontod az adott dolgot külön spriteokra (pl. kéz, láb, stb.), akkor mindegyikhez külön-külön transzformációt rendelhetsz. A transzformációk között meg nyilván tudsz interpolálni. Csak ez körülményes, és nem mindig ad szép megoldást.
A sprite-animáció (amikor pl. egy képen sok képkocka van) az csak azért látszik folyamatosnak, mert eléggé sűrűn lettek elkészítve a képkockák, és megfelelő sebességgel van lejátszva.

   
zeller - Törzstag | 464 hsz       Online status #194353   2013.05.30 14:31 GMT+1 óra  
2D karakter animaciot lehet normalisan interpolalni? Vagy muszaj spriteokat hasznalni?
Vagy igazabol a sprite animacio is interpolacio, csak sok a keyframe?

   
zeller - Törzstag | 464 hsz       Online status #194256   2013.05.27 17:42 GMT+1 óra  
Nem akarsz odairni syam? Hires lehetnel.

   
syam - Törzstag | 1491 hsz       Online status #194254   2013.05.27 16:57 GMT+1 óra  
Idézet
zeller :
Asszem bullethez nincs topic.
Erre tudja vki a valaszt?
http://stackoverflow.com/questions/16774336/removing-a-rigid-body-but-still-getting-collisions-for-it/16774619#16774619



Még nem láttam ilyet (281-gyel dolgozom, svn revíziót most nem tudok mondani).
Hány shapeje van? Esetleg van közöttük trigger/ghost vagy no-collision-response-os?
alias aalberik
   
zeller - Törzstag | 464 hsz       Online status #194253   2013.05.27 15:57 GMT+1 óra  
Draghagdu - Tag | 4 hsz       Online status #194159   2013.05.22 15:35 GMT+1 óra  
Sziasztok.

Androidra készítek puzzle játékot és lenne néhány kérdésem, nem kell kódot írni, csak hogy hogy kellene megoldani. Persze vannak ötleteim, de gondoltam ha tudtok segíteni, akkor így egyszerűbb.
Konkrétan Unityvel programozok, a többit felteszem abban a témában, de ez talán ide is jöhet:
hogy lehetne megoldani, hogy két tárgy, amiknek egymás mellett kell lenniük, ha ott vannak, összeragadnak, de még szét lehet választani őket? Tehát egyszerűen: hogy lehet összeragasztani két objektumot (ha ezek textúrák) ? A többi kérdést felteszem itt: http://jatekfejlesztes.hu/forums.php?m=posts&q=1069

   
Pretender - Törzstag | 2498 hsz       Online status #193559   2013.04.18 05:24 GMT+1 óra  
Ja, tényleg SDL-ről is mondják, hogy jó. De a háttérben az is OGL-t használ.

   
borsi - Tag | 180 hsz       Online status #193547   2013.04.17 21:50 GMT+1 óra  
Vannak egyszerűbb 2D-re kihegyezett könyvtárak, pl allegro, SDL, én egy ilyet használnék.

   
ddbwo - Tag | 1625 hsz       Online status #193546   2013.04.17 21:40 GMT+1 óra  
Nem is tudom. Csak felmerült, hátha létezik valami, ami valahogy gyorsabb rajzolásra van tervezve. Minimalistább, közvetlenebb rajzolás, vagy valami. Eddig az opengl a leggyorsabb.
Talán értelmetlen is lenne mást keresni.
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 #193544   2013.04.17 20:42 GMT+1 óra  
Az OpenGL miért nem jó? Az elég sok helyen elérhető, annál jobbat nem hiszem, hogy találsz.

Amúgy meg lehet platformspecifikus szarokat is használni, mint pl. a Windowsban a GDI, azzal lehet mindenféle dolgot kirajzolgatni, nagyon még nem próbáltam, de szerintem egy OGL-t egyszerűbb fellőni, ami nem csinál mást, csak kirajzolja ezt a cuccot

   
ddbwo - Tag | 1625 hsz       Online status #193543   2013.04.17 20:37 GMT+1 óra  
Mivel lehet értelmesen a lehető leggyorsabban kirajzolni egy folytonosan frissített image array-t?
Olyasmi valamit keresnék, ami van olyan gyors, mint pl. az openGL.

Csak képességét tekintve bőven elég, ha egy frissülő image array-t villám gyorsan ki tud rajzolni... Ennyi lenne az össz feladata.
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
   
Geri - Törzstag | 2185 hsz       Online status #193536   2013.04.17 19:56 GMT+1 óra  
mert az 50 méteres lépegetők leölése nem pusztító gyilkolás?

   
versio - Tag | 659 hsz       Online status #193526   2013.04.17 19:17 GMT+1 óra  
erdekes mod a legjobb jatek az ICO , de az emberek nem ertekelik, a tobbsegnek pusztitasra van szuksege es gyilkolasra
   
ddbwo - Tag | 1625 hsz       Online status #193524   2013.04.17 19:04 GMT+1 óra  
Ha már engine programozás, észrevehetted, hogy nem a 3D / 2D megoldás és nem is a fények szempontjából írtam. A jó és legjobb szubjektív, a kinek és miért meg pláne.
A Diablo2 engine-ként és játékként sem egy nagy durranás. Valójában tényleg csak böködni kell a csontokat. Ez pedig nem jelent több kidolgozottságot a kategóriájában, mint egy Crysis esetén a saját kategóriájában.
Abban a típusban van összetettebb, hangulatosabb, jobb. Még ha a jó szubjektív is, sok technikai elem, történet és kialakítás miatt jobb pl. a Baldur's Gate és az Icewind Dale 1-2.
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 #193475   2013.04.17 06:31 GMT+1 óra  
Ez nem ide való, ezért ez az utolsó postom ezzel kapcsolatban:
A Diablo 2 a játéktörténelem egyik legjobb játéka, és roppantul látszik, hogy fogalmad sincs arról, hogy mi a jó, illetve mi miért jó. Pedig elvileg idősebb vagy nálam, de ezek szerint te is "parasztvakítható" vagy. Ez pedig igen szomorú.

Téma lezárva, ha folytatni akarod, akkor ne itt tedd.

   
ddbwo - Tag | 1625 hsz       Online status #193470   2013.04.16 22:43 GMT+1 óra  
Jaj ne... Diabló, mint jó példa?! Hajam hullik! Pont annál kell bekészíteni három egeret és rákötni egy rotációs kapát, azt kész is. Ebben ki is merül.
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 #193453   2013.04.16 20:39 GMT+1 óra  
Ez tény, nem azt mondom, hogy ez minden, de én nagyon fény-mániás vagyok
A Diablo 2-ben pl. nem volt túl sok fény, de amennyi volt az nagyon jól volt megcsinálva, és dobott a hangulaton A crysis meg szar játék, de nem is annak szánták, ha jól tudom

   
DMG - Szerkesztő | 3172 hsz       Online status #193442   2013.04.16 20:07 GMT+1 óra  
Persze midnennek van hozzá köze, de ami igaz az igaz, egy 8 bites játék mai napig tud hangulatosabb, meg jobb lenni mint egy crysis.
-----------------------------------------
Dont Listen to the Naysayers
   
Pretender - Törzstag | 2498 hsz       Online status #193325   2013.04.11 12:07 GMT+1 óra  
Szerintem nagyon sokat számít a hangulat előállításában, ha meg a játék hangulatát befolyásolja, akkor igenis sok köze van hozzá

   
versio - Tag | 659 hsz       Online status #193323   2013.04.11 12:02 GMT+1 óra  
nem a fenyek miatt lesz jo egy jatek
   
Pretender - Törzstag | 2498 hsz       Online status #193322   2013.04.11 11:16 GMT+1 óra  
Én meg mondjuk mobilban nem gondolkozok. A perpixel dispmapnak meg hasonló követelményei vannak, mint a deferrednek, nem? Azt leszámítva, hogy ugye nem postprocessként végezzük el, és nem kell MRT.
Vízen a tükrözéshez megérné, mert ott úgyse látszana (a hullámzás miatt), hogy lowpolyt renderelünk, de mondjuk egy tükör esetén a backbace-t ugyan úgy displacementtel kell tolni.

Minden esetre azért nem lehet egy túl gyors dolog, de nagyobb skálát ad a dolgoknak, az biztos

Ami még pluszba eszembe jutott a forward mellett, hogy mondjuk egy esti TPS pályán a messzi fényeket simán lehet vertex colorként áttolni, a közepesen messzieket pixel shaderben normal mapping és minden egyéb nélkül, a közeliekre kell csak mindenféle shading.
No majd lesz valami

   
versio - Tag | 659 hsz       Online status #193310   2013.04.10 14:28 GMT+1 óra  
ha keressuk azt az engine-t ami kompatibilis mind a mobilokkal , mind a hitech gepekkel, ugy hogy nem kell semmit ujrarajzolni, akkor szerintem a perpixel dipmapra kell epiteni,

elonyei:

-lefut mobilokon, es lassu gepeken, termeszetesen ha a dispmapot kikapcsoljuk
-a keves polygonszam miatt nem gond ha ujra kell tobbszor rajzolni, backbufferbe vagy shadowmapba
- nem kell LOD, mert nincs highpoly, ez gyakorlatilag 3-ad annyi munkat jelenet grafikusi oldalon
- csucskonzolokon is elfogadhato eredmenyt ad, bekapcsolva a per pixel dispmapot, brutalisan nez ki , gyakorlatilag 100 millio polygonnal egyenerteku a renderelt kep

mivel mobilokon nincs deferred , igy meg ertelme sincs gondolkodni a hasznalatan, ha tobb feny kell vertex shaderrel kell dolgozni , vagy processzorral
   
Frissebbek | Korábbi postok
[1] [2] [3] > 4 < [5] [6] [7] [8] [9] [10] [15] [20] [25] [27]