játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5441
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:    2186
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [16]
Imre_ - Tag | 2 hsz       Online status #211535   2017.08.04 20:48 GMT+1 óra  
Nem is szamitottam ilyen gyors reakciora. Koszonom a gyors valaszokat. Szepensorban atolvasgatom amiket belinkeltetek. Koszonom megegyszer!

   
Elodin - Tag | 172 hsz       Online status #211534   2017.08.04 19:30 GMT+1 óra  
fpeti - Törzstag | 1283 hsz       Online status #211533   2017.08.04 18:42 GMT+1 óra  
Ciklusból hívogatnak minden szépen sorban, újra meg újra, kb:

eleje:
playermozgatás();
for(fáklya in fáklyalista): fáklya.lobogjá();
if(escape_levannyomva()) exit();
ugras(eleje);

Cikket nem tudok, fogalmam sincs, hogy hívják ezt.
   
Asylum - Törzstag | 5441 hsz       Online status #211532   2017.08.04 17:12 GMT+1 óra  
Igy:



Az eredmeny pedig (a fegyver oldalan levo szellozonyilas animacioja ez):

https://www.youtube.com/watch?v=LK3KIKPzQ58&feature=youtu.be

2D jatek irashoz pedig:

https://github.com/asylum2010/DummyFramework/tree/master/projects/source/spacebang2
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Imre_ - Tag | 2 hsz       Online status #211531   2017.08.04 15:43 GMT+1 óra  
Udv!
Az utan keresgelek, nem tul nagy sikerrel, hogy hogyan oldjak meg 2d jatekoknal, a par kepkockabol allo animaciok mukodeset. Peldaul egy fakja lobogo langjat amibol van sok peldany a kepernyon.
Tobb szalat hasznalnak ahhoz hogy meg a karaktret is lehetkozben iranyitani? Fellelheto valamilyen cikk vagy blog ami foglalkozik ilyesmivel, nem tul professzionalis nyelvezettel? Nem konkretan a jatek keszites a lenyeg inkabb a programozas, de igy szorakoztatobb. Latom eleg komoly eszme cserek fojnak itt , remelem nem rontom itt a szinvonalat az en kis problemammal.

   
Asylum - Törzstag | 5441 hsz       Online status #211454   2017.06.22 10:18 GMT+1 óra  
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
turidoo - Tag | 34 hsz       Online status #211453   2017.06.22 08:33 GMT+1 óra  
nem voltam egy ideje... sikerült azóta megoldani a GTAO-t?

   
Instalok - Tag | 532 hsz       Online status #211153   2017.04.01 09:25 GMT+1 óra  
Na igen, lehettem volna konkrétabb is. Nem volt túl sok időm mostanában ezzel foglalkozni, azonban, ha megint előjön, és gondom van vele, akkor konkrétabb leszek.

   
Matzi - Szerkesztő | 2519 hsz       Online status #211102   2017.03.13 17:44 GMT+1 óra  
Szóval mondjuk neked egy megoldást egy olyan problémára, amit csak te ismersz, mi meg csak annyit tudunk hogy bonyolult?
Nyilván szét kell szedni darabokra, de így elég nehéz megmondani, mert nincs bevett módszer ilyen konkrét dolgokra.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Instalok - Tag | 532 hsz       Online status #211100   2017.03.13 14:53 GMT+1 óra  
@Elodin:
Igen, valami ilyesmi a cél, csak nehéz magukat a komponenseket is már megépíteni, mert annyira sokfélék lehetnek.

Amúgy ja, editorból lenne a legjobb összeszerkeszteni, de egy csomó dolgot nehéz leírni. Például mi van, ha egy adott komponenst csak egy másik komponens egy eseményekor akarsz létrehozni? Vagy mi van, ha azt akarod, hogy akkor szűnjön meg, ha egy másik megszűnik, vagy létrejön, vagy egyéb eseménykor? Mindezt leginkább csak szövegesen tudnád leírni, amit minden egyes képesség létrejöttekor parse-olni kellene, és abból kódot építeni.

@Matzi:
A legtöbb képesség amúgy már megvan, ha nem is konkrét adatokkal, de legalább koncepció szinten. A gond inkább az, hogy annyira sokfélék tudnak lenni, hogy nehéz köré bármilyen rendszert is húzni.

Eleve úgy közelítettem meg az egészet, hogy van egy AbilityBlueprint, aminek a függvényeit az adott karakter hívja meg (pl. CanUse(), Use()). Ez az osztály felelős azért, hogy megvizsgálja, hogy létre lehet-e hozni az adott Abilityt (van-e elég erőforrás (mana/stb.), nincs-e cooldown-on, stb.). Ezután, ha használható a képesség, akkor létrehoz egy konkrét Ability példányt, ami a saját működéséért felelős. Például a FireballBlueprint létre tud hozni Fireball objektumokat, és maga a Fireball osztály írja le azt, hogy mit csinál.

Az egész kicsit olyan, mint a Unitys prefab + instantiate, csak saját (és egyszerűbb/gyorsabb) rendszerrel, így nem kell tényleges GameObjecteket létrehozni, kapcsolgatni, törölni, mozgatni, stb.

   
Matzi - Szerkesztő | 2519 hsz       Online status #211098   2017.03.13 13:37 GMT+1 óra  
Szerintem eloszor mindenképpen szedd ossze hogy miket szeretnél megcsinálni, és annak megfeleloen bontsd szét részekre a problémát. Nincs értelme elkezdeni egy általános rendszert ha nem tudod mit akarsz kihozni belole. Ha már megvan, hogy mik a konkrét elvárások, akkor lehet utána újabb effekteket osszerakni.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Elodin - Tag | 172 hsz       Online status #211097   2017.03.13 12:21 GMT+1 óra  
Szerintem valami alap komponensekre építő rendszer lenne ideális, amivel utána a konkrét skill-eket config fájlban / vmi editorral elő tudod állítani anélkül, hogy programkódba bele kéne nyúlni.

   
Instalok - Tag | 532 hsz       Online status #211096   2017.03.13 12:01 GMT+1 óra  
A cél egy flexibilis képességrendszer, a lehető legkevesebb duplikált kóddal. Persze az nem kihívás, hogy az adott képességeket egyesével leprogramozzam, de akkor bonyolultabb lenne megcsinálni a "modifier"-eket.

Aki ismeri a Path of Exile nevű játékot, annak ismerős lehet a Lesser Multiple Projectile support. A lényeg az, hogy alapból egy fireball egyetlen projectile-t lő, ezzel összekapcsolva viszont 3-mat. De ez igaz az összes többi projectile-alapú képességre (Icebolt, Magic Missle, akármi).

Viszont nem ugyan úgy viselkedik minden projectile esetén. Például van egy Rapid Fire, ami kis szórással, de ugyan oda lő alapból 3 lövedéket (ilyen burst-fegyver jellegű). Ha emellé multiple projectile supportot rakunk, akkor nem 3 különböző irányba fog ilyen burst-öt lőni, hanem megnöveli a kilőtt lövedékek számát, de ugyan úgy viselkedik, mint előtte.

Tehát nehéz minden képességre közös dolgokat találni. Még a pozíció sem ilyen. Nem feltétlen van minden képességnek térbeli megjelenése (pl. akármilyen Heal, Buff, ilyenek), sőt nem is minden képességnek kell, hogy legyen valamilyen Update függvénye (pl. Buff esetén csak on/off van, de nem feltétlen csinál semmit folyamatosan).

Szóval nagyjából odáig jutottam, hogy nagyon alap komponenseket tudok csak csinálni (pl. projectile, ami csak annyit tud, hogy repül egy adott pontból egy adott irányba adott sebességgel), és minden képességet kézzel hegesztek össze, hogy milyen eseménykor mi történik. Ha hazaértem, töltök fel egy kis mintakódot, hogy mire gondolok.

   
Asylum - Törzstag | 5441 hsz       Online status #211094   2017.03.13 10:16 GMT+1 óra  
Nem értem pontosan, hogy mit akarsz csinálni, de én valahogy így állnék neki:

Kód:
class Fireball : public Ability, public Entity
{
public:
    void Advance(float dt) override {
         if (mState == Flying)
             UpdatePostion(dt);
    }

    void Collided(Entity* target) override {
        target->SufferDamage(200);
        mEntityManager->Spawn(new FireballExplosion(mPosition));

        mState = Dead:
    }
};


Majd ha beértem megnézem a kódomban, hogy a plasmagun mit csinál konkrétan.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #211092   2017.03.12 23:51 GMT+1 óra  
Hm, igen, gondoltam ilyen buff-jellegű dolgokra is, és például a block is lehetne ilyen. Végső soron ugyan az, csak az adott abilitybe nem eventen keresztül hívna a karakter, hanem egy listán keresztül.

Közben adódtak más gondok is, kicsit át kell gondolnom ezt a rendszert. Nehéz úgy kitalálni, hogy a képességek elég sokfélék lehetnek. Első megoldásként kicsit sok a redundáns kód, no már olyan szempontból, hogy az adott képességnek kell létrehozni és hozzáadni a komponenseket a megfelelő időben. Ez nem tűnik rossznak, de pl. egy Fireball és Icebolt között csak annyi a különbség, hogy az első tűz sebzés és burn debuffot rakhat a célpontra, a másik viszont jég sebzés és fagyaszthat. Persze lehetne ezeknek egy közös osztályt csinálni, és csak a paramétereit buherálni, de az pont a komponens alapú rendszer által elkerülni kívánt osztályhierarchiához vezetne.

Ráadásul már odáig jutottam, hogy az abilityhez tartozó komponenseknek tulajdonképpen nincs őse. Fölösleges is lenne, mivel úgyis maga az ability hívja meg a komponens egy függvényét. No persze ez egyben gond is, mert pl. egy projectile-t azt updatelni kell framenként, szóval az ability feladata meghívni a Tick(deltaTime) függvényét a Projectile komponensnek. No és ezt minden egyes olyan képességnek, ami lövedéket használ...

Viszont ez az egész azért alakult így, mert rájöttem, hogy nem lehet az adott komponenseket rögtön az ability születésekor létrehozni. Például a Fireball első körben egy projectile, de ha eltalál egy targetet, akkor létrehoz az adott pontban egy robbanást (ami így további célpontokat is eltalálhat). Látszik, hgoy a robbanást csak akkor kell létrehozni, ha a projectile ütközött valamivel, és nem rögtön a képesség használatakor. Így tehát nehéz egy közös dolgot találni, ami igaz az összes komponensre.

Talán a Tick() függvényt lehetne egy ősosztályba tenni, így automatikusan meg tudnám hívni minden létrehozott komponensre. Cserébe magának a komponensnek kellene egy checket futtatnia, hogy ő éppen aktív-e, vagy sem. Sőt, olyan komponens is lenne, aminek nincs is szüksége Tick() függvényre (például ami csak lespawnol egy particle systemet, majd magára hagyja - tipikusan ilyen a robbanás effekt).

Ezt a hozzászólást Instalok módosította (2017.03.12 23:56 GMT+1 óra, 161 nap)

   
Asylum - Törzstag | 5441 hsz       Online status #211091   2017.03.12 11:07 GMT+1 óra  
Én úgy kezelném ezeket mint teljesen független entitásokat. Szóval a karakter rohangál összevissza, aztán vagy ütközik egy projectile-al vagy nem. Ha van block buffja, akkor a bejövő iránytól függően sebződik vagy nem.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #211088   2017.03.10 20:33 GMT+1 óra  
Nem is tudom hova illik igazán ez a kérdés, talán itt jó lesz.

Szóval egy Ability/Skill systemen dolgozok, első körben úgy tűnik, hogy egész jó lesz: komponens alapú, az abilityhez hozzá lehet dobálni mindenféle komponenst, amik akár más komponensek eseményeire is kiváltódhatnak (pl. robbanás egy fireball projectile ütközésekor, stb.).

Mindenféle támadó és egyéb abilityt viszonylag könnyű csinálni, mert maga a komponens csinál valamit (repül, ütközik, sebez targeteket, ilyesmi), azonban kicsit megakadtam az egyéb védekező képességeknél.

Például van egy Block ability, ami a block irányához képest szemből jövő támadásokat megfogja. Adott a játékos, benyomja a block abilityt, szemből pedig egy Fireball repül az irányába. A fireball sebzés komponense annyit tud, hogy meghívja a targetnek a TakeDamage függvényét (vagy valami ilyesmit, egyelőre csak elmélet ).

Azon gondolkoztam, hogy lehetőség lenne a karakter tényleges sebzése előtti időpontra feliratkozni (event, akár abilityből is), és ott úgy beállítani egy értéket válaszként, hogy a sebzés blokkolva van. Valami ilyesmi (nem tényleges kód)
Kód:
class BlockAbility
{
    void Setup(Character character)
    {
        character.OnBeforeTakeDamage += OnCharacterTakingDamage;
    }
   
    void OnCharacterTakingDamage(Damage damage, ref HitResult hitResult)
    {
        if (IsInFrontOf(damage.Source.Origin))
            hitResult = HitResult.Blocked;
    }
}

Ez nekem annyiban tűnik jónak, hogy mindenféle egyéb buffot is meg lehet így csinálni (pl. 3mp sebezhetetlenség, stb.), ami nem feltétlen blockoláshoz kötött.

Első körben ezt találtam ki, de kíváncsi vagyok, hogy létezik-e jobb/szebb megoldás.

   
Asylum - Törzstag | 5441 hsz       Online status #211059   2017.02.27 10:53 GMT+1 óra  
Találtam egy ilyet ami gyanúsan hasonlít az ötletemre, csak nem részletezi túl.

szerk.: igen, ha jól látom ez eltárolja az AO bufferben az aktuális iterációt (van pszeudokód). Csak épp túl sok extra infót használ...

https://developer.nvidia.com/sites/default/files/akamai/gamedev/files/gdc12/GDC12_Bavoil_Stable_SSAO_In_BF3_With_STF.pdf

És még egy, ami szintén megemlíti a konvergencia lebomlasztását:

https://users.cg.tuwien.ac.at/matt/gpupro/tssao_submission.pdf

Ezt a hozzászólást Asylum módosította (2017.02.27 11:33 GMT+1 óra, 174 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #211058   2017.02.27 10:48 GMT+1 óra  
Igen, valahogy jó lenne a hosszát maximalizálni, és akkor lehetne a blendFactor a velocity hosszának a függvénye. Legalább álló kameránál eltűnne a hullámzás. Esetleg lehetne egy olyan f(x) függvényt használni, ahol x a length(velocity) és 0 <= f(x) <= maxBlendFactor, csak kérdéses, hogy megéri-e az erőfeszítést.

   
Asylum - Törzstag | 5441 hsz       Online status #211055   2017.02.27 10:31 GMT+1 óra  
Van ilyen, hogy velocity weighting, de nem látom, hogy az miben segítene. A velocity vektor tetszőlegesen hosszú lehet, ha elég gyorsan forog a kamera.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #211048   2017.02.26 10:28 GMT+1 óra  
Esetleg valahogy a velocity magnitúdójához arányosítani a blend factort?

   
Asylum - Törzstag | 5441 hsz       Online status #211047   2017.02.26 10:01 GMT+1 óra  
Arra gondoltam, hogy ezt a blendfactort is ki lehetne írni éppenséggel a history bufferbe és pixel szinten csökkenteni, hogy ne konvergáljon tovább, mint szükséges. Ezzel persze csak annyi a gond, hogy ahogy forog a kamera tudnom kéne, hogy mik az új pixelek...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5441 hsz       Online status #211042   2017.02.23 14:15 GMT+1 óra  
Innen le tudod klónozni a progimat (jelszót küldöm privátban):

https://Asylum2010@bitbucket.org/Asylum2010/GTAO.git

A main.cpp alján le tudod sleepeltetni ezzel szimulálva az alacosny fps-t (ekkor ghostolni fog).
A blend factor most bele van égetve a shaderbe.

A tekerést a modell felső részén a rudaknál lehet jól látni (főleg alacsony fps-nél).
A hullámzáshoz elég ha mozogsz és/vagy közben rángatod a kamerát.

Ezt a hozzászólást Asylum módosította (2017.02.23 14:32 GMT+1 óra, 178 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5441 hsz       Online status #211041   2017.02.23 14:05 GMT+1 óra  
Álló kameránál "tekeri" az AO-t, mozgó kameránál meg "hullámzik" a kép (bár alig észrevehetően).

Karis jegyzete az az UE4, szerintem a GTAO szerzői megoldották ezt a problémát, Jimenez ennek a témának a legnagyobb szakértője.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
turidoo - Tag | 34 hsz       Online status #211040   2017.02.23 13:55 GMT+1 óra  
Most ez akkor álló kameránál van? Mert mozgó kameránál a history buffer folyamatosan frissül új/más képpel, ott nem kéne, hogy "elavuljon"... vagy nem értem?
Amit utoljára linkeltem (Karis: Temporal AA) 42.oldaltól írnak a flickeringről, és hogy nincs teljesen megoldva nekik sem (45.oldal)

   
Asylum - Törzstag | 5441 hsz       Online status #211039   2017.02.23 13:39 GMT+1 óra  
Powerpointtal meg lehet nézni.

A gond az egyébként, hogy ha alfa elég nagy (0.5 vagy annál nagyobb), akkor nagyon láthatóan előjön ez a "tekerem a konvergenciát" probléma (mondjuk anélkül is...). Hát persze, hiszen ahogy a history buffer elavul, úgy a 6 frame-nyi konvergenciát újrakezdve az AO így "pörög" (nem tudom hogy mondjam). Szóval nem egy adott megoldáshoz konvergál, hanem az elavulás miatt mindig újrakezdi.

Lehet h ezt értik a temporal contrast tracking alatt? A szerző egyelőre megint tojik a fejemre...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
turidoo - Tag | 34 hsz       Online status #211038   2017.02.23 13:28 GMT+1 óra  
Mondjuk ez jó ötlet, hogy figyelembe veszi az FPS-t!
És végre 1-2 óra után rájöttem mit akar jelölni az Rcp: reciprok
Így ha az eddigi 6 frame-edet veszem és 60FPS-t akkor nekem a convergenceTime = 6/60 = 0.1 sec.
x = - 1/60 / 0.1 = -0.1666
alpha = 0.8465
(e, ex miért nincs a windows számológépen??)
De gondolom ez a convergenceTime szabadon választható. Lenne. De a 94. diát elnézve itt számolják ezt is. De ez már kezd sok lenni nekem
Itt meg hivatkoznak Karis2014-re, ez is egy szép diasor:
https://de45xmedrsdbp.cloudfront.net/Resources/files/TemporalAA_small-59732822.pdf
Ez is ír a neighborhood clamping-ról.

(a pptx-ben mintha lenne beágyazott video, azt mivel lehet megnézni? ingyenesen.. open office, power point viewer nem viszi...)

   
Asylum - Törzstag | 5441 hsz       Online status #211037   2017.02.23 10:19 GMT+1 óra  
Igen ez a fajta számolás amit a shaderben is leírtam.
Alkalmazva azt, hogy

Kód:
blendFactor = 2 / (6 + 1); // 6 frame alatt kell konvergáljon


a helyzet jelentősen javul, de egyrészt a kép "hullámzik" (ghosting?), illetve alacsony fps mellett erőteljesen ghostol. Erre a következőt írják:

Kód:
float Alpha(float framesPerSecondRcp, float convergenceTime)
{
    return exp(-framesPerSecondRcp / convergenceTime);
}


A convergenceTime vajon mi lehet? 6 * elapsedtime? Arra elég fura értékeket kapok.

https://en.wikipedia.org/wiki/Exponential_smoothing#Time_Constant

Az első problémára pedig valszeg a neighbourhood clamping lesz a megoldás.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
turidoo - Tag | 34 hsz       Online status #211036   2017.02.23 09:45 GMT+1 óra  
húú, akkor nem lőttem mellé
akkor írom a saját példámat, hátha közelebb visz:
először is kell egy "multiplier" vagy "smoothing constant" (a diákon ez az alpha).
pl vegyünk egy alap esetet: azt szeretnénk, ha az elmúlt 10 frame dominálna főleg:
Multiplier: (2 / (Time periods + 1) ) = (2 / (10 + 1) ) = 0.1818

Kód:
currEMA = alpha*currentValue + (1-alpa)*prevEMA;

vagy máshogy rendezve ahogy tetszik:
Kód:
currEMA = alpha*(currentValue - prevEMA) + prevEMA;

vagy az itteni szóhasználattal:
Kód:
nextExpHistorySample = currentFinalFrame = alpha*currentFrameSample + (1-alpha) * prevExpHistSample;


aztán ez a currEMA egyrészt mehet további feldolgozásra/monitorra, másrészt a következő frame-nél ez lesz a prevEMA, a prev. exp. history sample.

első frame-nél, mivel még nincs history, ezért simán:
currEMA = currentValue;

Aztán folyamatosan beáll.
A 10-es periódusnál (0.1818 szorzó) például az utolsó 10 frame 86%-osan számít bele a végső képbe, az ennél régebbiek meg a maradék 14%.
A jelenlegi képbe tehát gyakorlatilag a végtelenbe nyúlóan sok előző frame számít bele, egyre kisebb súllyal.
Az utolsó 38 frame 99,9%-os súllyal, képlet: 3.45*(N+1).

részletesebb irodalom:
https://en.wikipedia.org/wiki/Moving_average#Exponential_moving_average

   
Asylum - Törzstag | 5441 hsz       Online status #211035   2017.02.23 08:53 GMT+1 óra  
Valahol ez a kulcsa a dolognak, igen. Csak nem részletezik agyon, hogy hogyan kell kiszámolni ezt a faktort.

Itt kicsit jobban le van írva:

https://en.wikipedia.org/wiki/Exponential_smoothing#Time_Constant

Ezt a hozzászólást Asylum módosította (2017.02.23 10:13 GMT+1 óra, 178 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
turidoo - Tag | 34 hsz       Online status #211033   2017.02.22 15:29 GMT+1 óra  
leszögezem, hogy fogalmam sincs miről van szó, szóval bocs ha hülyeséget írok
de nekem kapásból az EMA (Exponential Moving Average) jutott eszembe; én ilyen kontextusban használtam:
http://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:moving_averages

és átlapozva a "FilmicSMAA" doksit, említik is az EMA-t 67-69. dián.

   
Asylum - Törzstag | 5441 hsz       Online status #211028   2017.02.21 17:12 GMT+1 óra  
Felteszek már én is egy kérdést, bár nem valószínű, hogy tudtok válaszolni
A GTAO már majdnem a célegyenesben van; az utolsó simítás, amit még meg akarok csinálni az az ún. "temporal filtering" vagy "temporal reprojection".

Ez röviden arról szól, hogy egy velocity buffer-t felhasználva az aktuális és az előző frame pixelei összepárosíthatóak, így lehet a módszert konvergáltatni (pl. egy path tracerben is meg lehet ezt csinálni). Ehhez a konvergáltatáshoz egy ún. "exponential history buffer"-t használnak, ami tulképp egy ilyen feedback loop-ot jelent (konkrétan: konvergencia). Pl. az alábbi shader ilyesmit csinál:

Kód:
uniform sampler2D historyBuffer;
uniform sampler2D currIteration;
uniform sampler2D velocityBuffer;

uniform float blendFactor;

in vec2 tex;
out float my_FragColor0;

void main()
{
    vec2 velocity = texture(velocityBuffer, tex).rg;

    float curr = texture(currIteration, tex).r;
    float prev = texture(historyBuffer, tex - velocity).r;

    my_FragColor0 = mix(prev, curr, blendFactor);
}


A kérdés tulajdonképpen a "blendFactor" változó, ami persze egy normál konvergencia esetén 1 / aktuális_iteráció, de egy ilyen spéci esetben gőzöm nincs mi kéne legyen. Most konstans 0.5-öt választottam, ami nyilván rossz, és ilyen "helyben konvergálok" (aka. flickering, elölről kezdi 6 framenként) hatást kelt.

Mit gondoltok hogyan lehet ezt megcsinálni? A releváns irodalmak:

https://research.activision.com/t5/Research-Papers/Filmic-SMAA-Sharp-Morphological-and-Temporal-Antialiasing/ba-p/10012720

https://research.activision.com/t5/Research-Papers/Practical-Real-Time-Strategies-for-Accurate-Indirect-Occlusion/ba-p/10002180
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5441 hsz       Online status #211025   2017.02.18 07:08 GMT+1 óra  
Szerintem ez ugyanaz amit a Doom 1 csinált annakidején, de a leírása alapján az nem raycastolt, egyszerűen kiraszterizálta a falakat.

http://fabiensanglard.net/doomIphone/doomClassicRenderer.php
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pixi - Tag | 205 hsz       Online status #211024   2017.02.18 01:57 GMT+1 óra  
Alapvetően az a bajom a raycasting -al, hogy már az eleve lassulást okoz, hogy kiküldjek FPS -ként egy csomó sugarat, ezt utána beleírni a Color tömbbe, majd átadni a textúrának, amit egy darabban rajzolok ki. Persze biztosan én nem csinálok jól valamit, ugyanis a matek sosem volt erősségem. Tegyük fel, hogy csak 60 darab sugarat küldök ki, és nem pixel pontos vonalakat rajzolok, hanem olyan szaggatott kockaszerűség lesz az eredmény, de még így is lassú, főleg akkor, ha teljesen nekimegyek a falnak, és szó szerint az egész 800x600-as tömböt tele kell írni. És itt ezt értem úgy, ha csak egy darab kockám van, amivel ütközés detektálást végzek a sugárral, akkor is lassít. Ha már csak megfelezem az FPS ellenőrzési időt, mondjuk 30-ra, már úgy sokkal gyorsabb (az alap ugye 60 legalább), de ahogy néztem egy csomó videót, ott jól működik, úgy, hogy van padló, meg mennyezet is.

Az meg hogy felosztom több szálra, azt úgy értettem, hogy a kis sprite -ok már előre el vannak készítve, méret szerint, csak módosítani kell a kirajzolandó textúrájukat minden FPS-ben, de úgy gondolom ezt nem így oldották meg, főleg régen, mert akkor meg a sok kis különálló textúra fog lassítani. Ha pixelpontos vonalacskákat készítek el így, az megint csak fura és lassú.

Vagy tényleg az van, hogy ezt kisebb felbontásokon végzik (mondjuk 320x240), és akkor nem annyira lassú, max szétnyújtsák egy nagyobb felbontáshoz. Nem értem régen ez lassú processzorokon hogy tudott olyan gyorsan működni.

Nálam most ez úgy működik, hogy van a kamera (játékos) kezdőpontja, majd a legszélső fokkal kezdem, és itt egy pontot küldök ki, ami pixelenként halad, mindaddig, amíg nincs ütközés, ha igen, akkor újra kezdődik az egész, csak kicsit beljebb, mondjuk 0.01f -el. Ezt egy while ciklussal kezelem, minden FPS-ben végrehajtódik, tehát a 60 darab sugárral, amint ütközés van, ott egyből lekezelem a textúra eltárolását is a tömbben, hogy ne kelljen ahhoz is külön kört lefuttatni. Most gondolom az okozhatja ezt a brutális lassulást nálam, hogy nem pixelenként kellene a látómezőt leellenőrizni, hanem ha mondjuk már talált ütközést egyel, akkor vízszintesen és függőlegesen végigjárni a textúra megfelelő oldalait, így a sugár útja is kevesebb lesz. Itt csak az a gondom, hogy ebben az esetben a sugár honnan tudja, hogy a textúrából mennyit kell kirajzolnia, ugyanis nem biztos, hogy az adott kocka egésze fog látszódni, mivel ha kiküldenék beljebb egy újabb sugarat, akkor az lehet megint ütközést érzékel, vagyis az előző textúrát nem kellett volna végig bejárni, így megint csak fölösleges köröket futok le. Nem értem azt a metszet dolgot...Ez a titka az egésznek, hogy gyors legyen, vagy ez már csak akkor játszik szerepet, ha textúra is kell?

   
Asylum - Törzstag | 5441 hsz       Online status #210982   2017.02.08 09:18 GMT+1 óra  
Szoftveresen aztán feloszthatod szálakra, mikor a procidnak van kb. 8 magja... A videókártyának pedig akár 1000...

Egy raytracerben egyébként ugyanaz a matek érvényesül, mint raszterizálásnál, kivéve, hogy a projekciós mátrix inverzével számolod vissza a sugarat.

Kód:
float4 spos = ...; // aktuális pixel
float4 ndc = float4(0, 0, 0.1f, 1);
float4 wpos;
float3 raydir;

ndc.xy = (spos.xy / screenSize) * float2(2, -2) + float2(-1, 1);

wpos = mul(ndc, matViewProjInv);
wpos /= wpos.w;

raydir = normalize(wpos.xyz - eyePos);

// TODO: metszetkeresés
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #210981   2017.02.08 08:53 GMT+1 óra  
Személy szerint nem nagyon foglalkoztam még ilyesmivel, szóval majd valaki okosabb hozzászól, no de... A szoftveres renderelés mindig is lassabb lesz, mint a hardveres (Gerit ne kérdezd, szerinte néhány éve már megéri szoftveres raytracert írni ).

Az, hogy felosztod több részegységre az főleg arra jó, hogy többszálúsítani tudod, mivel alap esetben a különböző csempék nem függenek egymástól. No persze szerintem nem maga a "tömb feltöltése" lehet lassú, hanem az, hogy magát a raycastot hogy kezeled. Nem mindegy, hogy minden egyes sprite-ra kiszámolod a metszéspontot, vagy valahogyan fel van osztva a jeleneted, és így csak néhányra kell.

   
Pixi - Tag | 205 hsz       Online status #210980   2017.02.08 00:02 GMT+1 óra  
Raycasting (fake 3D) eljárással hogyan történik pontosan a már kész "látott 3d-s kép" kirajzolása?
Ugyan elméletben (vizuálisan) értem én, hogy mi történik, de maga az eljárás nem egyértelmű. Most csak a legegyszerűbb példát veszem alapul, ahol textúra nincs, se padló, se mennyezet, csak egy üres háttér, és a függőleges falakat egy szín alkotja.

Tehát megadok egy foktartományt, amin belül balról - jobbra végigmozgatok a középpontból kifelé egy sugár pontot. Ez ha ütközést érzékel egy 2D -s elemmel (kis négyzetek), megszakad az útvonal, adato(ka)t tárolok el, majd a kezdőponttól újra irányt vesz kissé beljebb. Gondolom itt az sem mindegy, hogy ez az ellenőrzés hány FPS -ként történik, meg az sem, hogy a sugár pontja mekkora léptekkel halad jobbra. Amit leginkább nem értek, az maga a textúra (függőleges vonalak) kirajzolása. Itt van két elképzelésem:

1. A kapott sugár pontok megfelelő kiszámításával egy darab tömbbe (Color[] array) írjuk az összes adatot (színeket pixelenként), majd egy darab textúraként rajzoljuk ki a végén.
2. A képernyő előre fel van darabolva láthatatlanul, amit sok kis külön sprite darabka alkot. Mindez több sorban, több rétegben, és ahogy "befelé halad", sokkal több van belőle egymás mellett, valamint méretre is egyre kisebb. A tárolt sugár adatokból éppen abba a kis sprite-ba rajzolódik ki a textúra vagy szín, ahová kell, de üres is maradhat (átlátszó), így minden FPS -ben minden kis sprite frissül.

Melyik a megfelelő eljárás? Vagy van ezeken kívül más megoldás is? Valamint mik a limitációk? Mekkora képernyő felbontással, és textúra szélességgel érdemes dolgozni, ami még nem eszi meg a procit? Mondjuk az, hogy egy nagy darab szín tömböt pixelenként (pl. 800 x 600) írogatok át FPS -ként, elég bizarrnak és lassúnak tűnik.

Kinézetre valami ilyesmire gondolok, csak nem Game Maker -ben:

https://www.youtube.com/watch?v=wuUXPRzPC3E

   
Asylum - Törzstag | 5441 hsz       Online status #210965   2017.02.05 20:40 GMT+1 óra  
mert vannak karakterek pl. japánban amikhez 4B kell. Meg egszerűbb kezelni.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #210960   2017.02.05 16:39 GMT+1 óra  
Egyébként azon kívül, hogy egy bizonyos számú szimbólum ábrázolásához több byte kellhet (https://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings#Eight-bit_environments) miért csináltak többféle UTF kódolást? Az UTF-8 byte-onként növekszik, ami tök jó, csak ugye a byte-onkénti első 2 bit kárba vész (ezért van az, hogy a hexa 000800 - 00FFFF között 3 byte kell UTF-8 esetén, míg 2 byte UTF-16 esetén).

Láttam már régebben is ezt az ICU dolgot, de első körben biztosan nem kellene annyi minden, amit ad, és nem akarok ezért behúzni egy libet. Na de majd látom.

   
Asylum - Törzstag | 5441 hsz       Online status #210959   2017.02.05 15:38 GMT+1 óra  
http://site.icu-project.org

Ha XML, akkor UTF-8.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 532 hsz       Online status #210957   2017.02.05 12:40 GMT+1 óra  
Elkezdtem gondolkodni a Unicode supporton (c++). Eleve abban nem vagyok biztos, hogy melyik UTF kódolást érdemes választani (UTF-8 / -16 / -32). Másrészt kérdéses, hogy hogyan lehet tárolni a lokalizációs file-t. Nyilván aki fordítja az adott szöveget, annak képesnek kell lennie leírnia az adott értéket a megfelelő szimbólummal / szimbólumokkal mondjuk egy XML file-ban.

   
Elodin - Tag | 172 hsz       Online status #209856   2016.07.17 09:59 GMT+1 óra  
Most valami olyasmin gondolkozom, hogy csinálok class hierarchiát a state-ekhez, de csak két szintűt (közös ős + állapotonként gyerek). Megtartom a flag rendszeremet, és a több state által hasonlóan reagált dolgok kódja a flagekkel lesz ősosztályban implementálva (esetleg template method-al, ha vmi alkalmas rá).

Az inputokhoz/eseményekhez pedig nem definálok eventeket, hogy arra swtich case-eljek az állapot osztályokban, hanem az input callback függvényeknek lesz megfelelője az állapot osztályokban - így talán átláthatóbb, hogy egy gyerek melyik inputokat kezeli hogy speciálisan.

   
zeller - Törzstag | 464 hsz       Online status #209855   2016.07.17 09:20 GMT+1 óra  
pedig a state segitene.
illetve a strategy is.
de a megoldas lenyege az en olvasatom szerint az lenne, ha az egyes allapotok nem pusztan kulcsok lennenek mas adatszerkezetekhez, hanem valodi objektumkent polimorfikusan biztositanak az informaciot, es azokrol lehetle lekerdezni a kozos interface-en.

   
Elodin - Tag | 172 hsz       Online status #209854   2016.07.16 22:52 GMT+1 óra  
Nem tudtok vmi titkos epic módszert játékos karakter input/állapotok/viselkedés kezelésére?

Jelenleg van egy meglehetősen hosszú enum-om (kb. 20 érték, és lesz még több is bőven) az állapotokkal. Kicsit egyszerűsítve a helyzeten minden enum értékhez rendeltem egy flageket tartalmazó változót, amiből gyakran előfordulható tulajdonságokat le tudom kérdezni (IgnoreJump, IgnoreMovement, etc.).

Az egész borzalmas spagetti, a karakter class kódja tele van if-ekkel (jobb esetben csak flagekre) meg switch case-ekkel, maguk az állapotok átláthatatlanok, ha valahova nyúlok, akkor jó esélyel vmi mást elrontok...

Elolvastam a gamedesignpatterns.com -on a state mintát, de nem vagyok benne biztos, hogy sokat segítene.

Unreal engine-ben csinálom a dolgokat, az inputot nem egy event handler függvényem kapja, hanem az egyes eventekre külön feliratkozott callback-ek vannak - lehet, hogy érdemes lenne nem a callback függvényekben kezelni a cuccost, hanem csinálni egy event enum-ot, és azt továbbadni az aktív state-nek, és state-eken belül switchelnék az event-re?

Ami leginkább elrettent, az az, hogy nagyon sok esetben van hasonló viselkedés különböző állapotok között, és nem vagyok benne biztos, hogy hogy lehetne lehető legszebben megoldani ezt a problémát.

Viszont folyamatosan nyúlkálni kell majd az állapotokba, szal fontos lenne a jó design

   
Parallax - Tag | 574 hsz       Online status #208817   2015.12.17 14:48 GMT+1 óra  
Nyílván, ha commodore 64-es felbontásban kell megjeleníteni a Crysis-t, akkor semmi sem fog ugyanolyan jól kinézni, de ez mit sem változtat azon, hogy egy nagy textúrából kicsinyíteni egyszerűbb és jobb képet fog adni még így is, mint a vektoros.

   
ricsi9328 - Tag | 24 hsz       Online status #208816   2015.12.17 14:26 GMT+1 óra  
De van 2160x3840px felbontású kijelző és 320x480px felbontású is, Ha én az előbbire tervezem az összes játékban szereplő képet, akkor azért az a 320x480px felbontású kijelzőre zsugorítva már nem fog olyan szépen kinézni.

   
Parallax - Tag | 574 hsz       Online status #208811   2015.12.16 17:39 GMT+1 óra  
Idézet
ricsi9328 :
Közben kicsit utána néztem és elvileg vektor grafikus képeket szoktak használni és akkor nem kell több méretben megcsinálni.


Jó, de a grafikus kártyának a vektorból is pixel tömböt kell átadnod és azt valahogy kinyerni a vektoros formátumból, amivel max képregény-szerű grafikát hozhatsz létre, Akkor már egyszerűbb egy nagy textúrát készíteni és abból kicsinyíteni.

   
ricsi9328 - Tag | 24 hsz       Online status #208810   2015.12.16 14:05 GMT+1 óra  
Közben kicsit utána néztem és elvileg vektor grafikus képeket szoktak használni és akkor nem kell több méretben megcsinálni.

   
Instalok - Tag | 532 hsz       Online status #208809   2015.12.15 18:32 GMT+1 óra  
Tudtommal azzal a legegyszerűbb megoldani. A felbontás dolog meg egy érdekes kérdés lehet. Vagy azt mondod, hogy felbontástól független lesz az egész, azaz mindig ugyan akkora sprite-ot látsz, akármekkora is legyen a felbontásod (ilyenkor nyilván elég egyetlen spritesheetet készíteni). Ha pedig azt szeretnéd, hogy az adott ablaknak mindig ugyan akkora részét akarod befoglalni az adott sprite-al (azaz nagyobb felbontás esetén nagyobb sprite-ot látsz), akkor talán érdemes lehet néhány több méretű sprite-ot készíteni. No persze nem minden egyes felbontáshoz, viszont kicsinyíteni tudtommal jobb, mint nagyítani (hiszen kicsinyítéskor adatokat dobsz el, nagyításkor viszont generálnod kell). No persze a többiek majd kijavítanak, ha nem így van, nem sokat 2D-ztem még.

   
ricsi9328 - Tag | 24 hsz       Online status #208802   2015.12.14 19:22 GMT+1 óra  
Sziasztok!
Egyszerűbb animált rajzok megjelenítését sprite sheetel szoktak megoldani? És ha igen minden kijelző méretre külön sprite sheetet csinálnak?

   
Korábbi postok
> 1 < [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [16]