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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2189
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]
full3nzo - Tag | 17 hsz       Online status #211724   2017.12.06 15:34 GMT+1 óra  
Csak az integritást csekkolom de ha sérült, akkor szó nélkül visszaadom az OS-nak a folyamatot - plusz a képeket titkosítom, de az LVL-ről alapból letettem csak addig érdekelt ameddig láttam, hogy miként működik.
Persze az is meglehet, hogy ezt így leírni eretnekség, de úgy gondolom, hogy Ti is őszinték vagytok.

   
Parallax - Tag | 591 hsz       Online status #211723   2017.12.06 08:25 GMT+1 óra  
Viszont van is igény rá, mivel mindenkinek van mobilja és, ha megun egyet, már keresi is az újat. Inkább mikrotranzakciós modellel próbálkoznék, mert akkor ingyen kipróbálhatja és plusz dolgokért fizet az, aki akar. Jobb, mint egyből mindenféle védelmekkel körbe bástyázni az appot, hogy még véletlenül se töltse le senki.

   
Asylum - Törzstag | 5455 hsz       Online status #211722   2017.12.06 06:00 GMT+1 óra  
Szvsz. amennyi tucatjáték jelenik meg mobilra örülhetsz ha van egyáltalán bevételed
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Parallax - Tag | 591 hsz       Online status #211720   2017.12.04 20:46 GMT+1 óra  
full3nzo: Az obfuszkálásra annyit, hogy nincs értelme, mert akkor például a hibaüzenetek is mindenféle krix-krax-ot fognak tartalmazni, meg lehet a program működését is elrontja, ha mondjuk reflection-t is használsz, meg ilyesmi. Java esetén bele kell törődni, hogy nyílt forrással fejlesztesz.

Egyébként a C++ se egy nagy varázslat, én most Visual Studio-val használom az NDK-t és semmi különös, olyan, mintha Java nem is létezne. Játékhoz amúgy is csak 1-2 API kell, ami egyébként is natív (GL, stb.).

   
full3nzo - Tag | 17 hsz       Online status #211717   2017.12.04 12:57 GMT+1 óra  
Köszi a választ! A lényeget kiszűrtem, akkor elég ha csak szar dolgokat kreálok és abban semmi rizikó..., de ne haragudj majd ha rád hivatkozom!

   
zeller - Törzstag | 470 hsz       Online status #211716   2017.12.04 12:35 GMT+1 óra  
Hat igazabol ugy ertem, hogy semmi sem akadaly.
Ha szar amit csinalsz, ugyse masoljak, nem kell vedeni
Ha jo akkor nehanyan tuti beprobalkoznak, de csak azok akik abbol elnek, hogy napi 100 klont megjelentetetnek a kozepes jatekokbol. Ezektol megvehetnek a custom dolgok (de amugy a custom hasznalata mas szempontbol gyakran zsakutca)
Ha meg tied az uj killer app. Akkor ugyis lemasolnak, akarmilyen patent vagy drm vedi a termekedet. Ekkor a brandingon keresztul tudod megtartani a revenue-t.

   
full3nzo - Tag | 17 hsz       Online status #211715   2017.12.04 12:01 GMT+1 óra  
Úgy érted, hogy az obfuszkált kód sem jelent túl nagy akadályt? Mert akkor lehet, hogy elkezdem kóstolgatni a natív dolgokat, bár olvastam róla, hogy nem kevés többletmunkát jelent ugyanarra a feladatra... Van pár év C++ hobbi szintű tapasztalatom, nem lenne nehéz felmelegíteni a dolgokat, de szakirodalmat sem lenne rossz előásni, akkor.

És még annyit csak, hogy mindenkinek köszönöm az észrevételeket / tanácsokat természetesen.

   
zeller - Törzstag | 470 hsz       Online status #211714   2017.12.04 11:30 GMT+1 óra  
En nem tudom van-e erre vedelem, de teoretikusan ket okossag:
1. A tortenelem azt mutatja, hogy minden DRM-et feltornek.
2. Parallaxnak abban igaza van, hogy ami custom kod, abba kulon energiat kell fektetniuk a feltoreshez.

   
full3nzo - Tag | 17 hsz       Online status #211713   2017.12.04 11:07 GMT+1 óra  
A licence checkinget és az in-app-billing library-ket, akkor is csatolod gondolom és ugyan ott vagy ahol én - nekem sem a saját kódom van veszélyben, hanem az előbb említett modulok nyíltsága. Persze szívesen tanulok, ha natív kóddal másképpen megy a dolog. C++ ban nem kódoltam még Android OS alatt csak a Dalvikot használtam még.

   
Parallax - Tag | 591 hsz       Online status #211712   2017.12.04 08:56 GMT+1 óra  
Ha C++ ban írod meg a programot azzal mit tud kezdeni? Tőlem már kért ügyfél natív programot hasonló okokból.

   
full3nzo - Tag | 17 hsz       Online status #211705   2017.12.02 05:52 GMT+1 óra  
Sziasztok!

Azt szeretném kérdezni tőletek, hogy valaki foglalkozott-e már komolyabban az Android kódok védelmével? Nem az obfuszkálásra és shrinkelésre gondolok, hanem a futásidőben való védelmekre.

Van egy LuckyPatcher nevű agyrém gondolom ismeritek és zokszó nélkül fellehet vele törni az appokat. Pontosabban generál egy újat ami kiüti a licence ellenőrzést és hazavágja az alkalmazáson belüli forgalmat is. Arra már rájöttem, hogy nem a saját kódomat piszkálja, hanem a függvény-könyvtárakban ír át dolgokat - rendkívül rafinált!

Bevallom besötétített szobákban titokban használtam már párszor, de mindig az vezérelt, hogy megismerjem a lélektanát. Köszönöm előre is, ha valaki megtud osztani némi tudást ezzel kapcsolatban!

   
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 | 173 hsz       Online status #211534   2017.08.04 19:30 GMT+1 óra  
fpeti - Törzstag | 1291 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 | 5455 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 | 5455 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 | 35 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 | 545 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ő | 2521 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 | 545 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ő | 2521 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 | 173 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 | 545 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 | 5455 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 | 545 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, 274 nap)

   
Asylum - Törzstag | 5455 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 | 545 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 | 5455 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, 287 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 545 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 | 5455 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 | 545 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 | 5455 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 | 5455 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, 291 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Asylum - Törzstag | 5455 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 | 35 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 | 5455 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 | 35 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 | 5455 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 | 35 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 | 5455 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, 292 nap)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
turidoo - Tag | 35 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 | 5455 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 | 5455 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 | 206 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 | 5455 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 | 545 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 | 206 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 | 5455 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 | 545 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.

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