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

Én csak ezt csináltam, mert lassú nálam a deferred:

1. diffuse, depth, normal,
2. final lighting.

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

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.

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?)

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

vertex shaderrel ujraszamolod a min,max koordinatakat, problem solved

És ha mondjuk az álló Sanyika ott van a fal mellett, és benyomja a spárgát? Odébbtolja magát?

Ez egy elvi felvetes volt
De mondjuk egy spargazo sanyika meg egy allo sanyika kozott latvanyos kulonbseg van, barmikor.

Mi az a játék, amihez ilyen változó méretű spriteok kellenek?

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

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.

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?

Animáláshoz ismerni kell az adott keyframeben lévő sprite méretét, nem? Az miért nem jó?

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?

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

Renderelést is lehet, de értelme nem sok van (hacsak nem akarod háttérben is futtatni).

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

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.

É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.

Hálózati funkciókat esetleg?

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.

Ú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.

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.

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.

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.

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á.

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).

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.

2D karakter animaciot lehet normalisan interpolalni? Vagy muszaj spriteokat hasznalni?
Vagy igazabol a sprite animacio is interpolacio, csak sok a keyframe?

Nem akarsz odairni syam? Hires lehetnel.

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?

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

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

Ja, tényleg SDL-ről is mondják, hogy jó. De a háttérben az is OGL-t használ.

Vannak egyszerűbb 2D-re kihegyezett könyvtárak, pl allegro, SDL, én egy ilyet használnék.

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.

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

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.

mert az 50 méteres lépegetők leölése nem pusztító gyilkolás?

erdekes mod a legjobb jatek az ICO , de az emberek nem ertekelik, a tobbsegnek pusztitasra van szuksege es gyilkolasra

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.

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.

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.

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

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.

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á

nem a fenyek miatt lesz jo egy jatek

É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

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