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]
DieToBorn - Tag | 32 hsz       Online status #204969   2014.10.07 14:29 GMT+1 óra  
Én azt hittem hogy ez csak a megjelenítést végzi és csak egyszer hozza létre...
Jó tudni :/
Load-ba próbáltam már de akkor meg be se tölti mert grafikus objektum és mindenképpen a paint kell neki...

szerk: e.graphics nem is jó akkor ott mert a load nem ezt kezeli mármint az nem paint event

szerk2: Form load-ba ha ezt beteszem:
Kód:
             this.DoubleBuffered = true;
            Graphics g = this.CreateGraphics();
            Level new_level = new Level(g);
            new_level.init();

akkor nem jeleníti meg :/

Ezt a hozzászólást DieToBorn módosította (2014.10.07 14:47 GMT+1 óra, 988 nap)

   
Instalok - Tag | 530 hsz       Online status #204962   2014.10.07 07:53 GMT+1 óra  
De, pontosan úgy fogod tudni mozgatni. Annyi, hogy betöltéskor kell csak létrehoznod. Az alábbi kódrészlet:
Kód:
// paint event
this.DoubleBuffered = true;
Graphics g = e.Graphics;
Create_Map(g);

Ez tényleg minden egyes paint event esetén lefut? Ha igen, akkor azért nem tudod mozgatni. A pályát csak egyszer hozd létre, még betöltéskor. Gondolj bele: ha mindig újra és újra elkészíted, akkor az értékek "resetelődnek". Statikussal pedig azért működött, mert a statikus érték nem példányhoz tartozik, azaz mindegy, hogy mikor, hol és mennyit hoztál belőle létre.

   
DieToBorn - Tag | 32 hsz       Online status #204960   2014.10.07 07:03 GMT+1 óra  
Ha kiveszem hogy ne legyen statikus akkor meg nem fogom tudni mozgatni :/
pl.: Level a = new Level();
a.imagey +=1; így nem :/ Nem fog akkor mozogni..

   
Instalok - Tag | 530 hsz       Online status #204956   2014.10.06 21:42 GMT+1 óra  
Ehhez tudnod kellene, hogy mit jelent az, hogy valami statikus
Ez így ebben a formában sehogy sem fog működni. Tessék csak külön létrehozni az objektumokat, és azoknak az értékét állítani. A statikus pont azt jelenti, amit te nem szeretnél.

Konstruktívabban: a statikus nem példányhoz tartozik, azaz, ha van 10 példányod, mind a 10-hez ugyan az(ok) az érték(ek) fog(nak) tartozni.

   
Tunyu - Tag | 444 hsz       Online status #204954   2014.10.06 21:14 GMT+1 óra  
Nem mondanám hogy teljesen értem, de általában ilyen esetben egy for ciklussal ki tudod választani a kívánt objektumot.Azt mondják hogy minden objektumhoz tartozik egy ID amivel ki lehet választani, na én ezt nem szoktam használni, hanem a for ciklussal kiválasztom a tömbből a kívánt elemet.

   
DieToBorn - Tag | 32 hsz       Online status #204952   2014.10.06 20:45 GMT+1 óra  
Sziasztok!

Segítség kellene az alábbi problémámhoz:

van egy osztályom pl:
http://pastebin.com/QZ8uqN1f

és így jelenítem meg: (ez már a form-ba van)
http://pastebin.com/Yie0N8RR

alapvetően az osztályra tudok csak hivatkozni és nem pedig az objektumra mert statikus pl a kép x,y és oké hogy megoldom a mozgatását (timert hozok létre és abba pl így néz ki: Level.imagey = Level.imagey ++ de ha csinálok belőle 10et akkor mind a 10 ugyan úgy mozogni fog és nem csak az adott példány

Lövésem sincs hogy hogy lehetne megoldani :/ Mert ezzel a módszerrel alapvetően akármennyi objektumot létre tudok hozni de mivel az imagex és az imagey statikus így az objektum nevének azonosítójával nem tudom elérni pl: Level a = new Level() a.imagex = valami.. ezt így nem tudom.. És így gyakorlatilag nem tudom irányítani az objektumaimat :/

   
Instalok - Tag | 530 hsz       Online status #204734   2014.09.08 23:30 GMT+1 óra  
Az szép megoldás lenne. Én valami sokkal egyszerűbben törtem a fejem. Mégpedig megvizsgálom a kérdéses pozíció távolságát is az adott háromszögtől, ami, ha egy tűréshatáron belül van, akkor azt vegye számításba.

Emellett ki szeretném egészíteni még két dologgal, amelyeknek a közös pontja egy sugár. Mégpedig első körben azt szeretném, hogy ha a sugár * 2 < portal size, akkor arra ne mehessen. Azaz például egy vékony hídon ne akarjon átmenni egy széles tank. Ehhez valószínűleg le kell cserélnem az útkeresésben használt pontokat a háromszög középpontjairól a portalok középpontjaira, hogy meg tudjam vizsgálni, hogy az adott él kellően széles-e. Emellett már csak apróság lesz az, hogy a falaktól tartson egy sugárnyi távolságot. Így a navmesh akár tökéletesen illeszkedhet a falakhoz, mert a mozgó actor sugara határozná meg, hogy mennyivel menjen el mellette.

   
syam - Törzstag | 1491 hsz       Online status #204733   2014.09.08 23:18 GMT+1 óra  
Én a navmesh magassági problémájának megoldására azt látom, hogy a navmesh konvex poligonjaiból konvex testeket kellene készíteni. Ez pedig ugrásra, látás becslésére és egyebekre is felhasználható lenne.
alias aalberik
   
Instalok - Tag | 530 hsz       Online status #204730   2014.09.08 19:41 GMT+1 óra  
No azt hiszem eljutottam valamilyen változatig. Alapvetően működik, valószínűleg nem lett a legoptimálisabb, de egyelőre kielégítő teljesítményt nyújt. Ki kell még egészíteni, hogy az y koordinátával is foglalkozzak. Bővebben itt

Köszönöm a segítséget!

   
Instalok - Tag | 530 hsz       Online status #204722   2014.09.08 09:56 GMT+1 óra  
Remélhetőleg egy utolsó post tőlem ezzel kapcsolatban.

Útkereséskor ugyebár kell a start és goal háromszög, ezt valahogy pozíció alapján meg kell határozni. Tele van az internet point in triangle képletekkel, így még túl okosnak sem kell lenni (a baricentrikus megközelítést használom egyébként). A problémám a magassággal van. Egyrészt, ezek az algoritmusok nem igen foglalkoznak a magassággal. Így, ha mondjuk van egy híd, illetve az alatt is van bejárható terület, akkor kérdéses, hogy melyik háromszöget találja meg.

Ráadásul kicsit félek attól, hogy worst case a teljes navmesh minden háromszögére lefuttassam a point in triangle algoritmust, hogy megtaláljam a megfelelőket.

   
Instalok - Tag | 530 hsz       Online status #204720   2014.09.08 08:11 GMT+1 óra  
Ez tulajdonképpen ugyan azt használja, mint amit második megoldásként leírtam, csak eltárol egy indexet is. Nem tudom mennyivel kifizetődőbb, mint helyben összehasonlítani a 4 vertexet. Adjacency vizsgálatkor az összehasonlítása két 3D-s pontnak legfeljebb 12 float összehasonlításából áll:
Kód:
if ((n1v1 == n2v1 && n1v2 == n2v2) || (n1v1 == n2v2 && n1v2 == n2v1))

Ahol az n1v1 az egyik vizsgált node egyik vertexe. Hasonlóan a többi.

Minden esetre ezt is elmentem, jó ötlet, kellhet még máshova is - például, ha másik modellformátumot akarok használni. Köszi ismét!

   
syam - Törzstag | 1491 hsz       Online status #204717   2014.09.07 23:49 GMT+1 óra  
Szinte mindenre van vmilyen algoritmusom

http://stackoverflow.com/questions/14396788/how-can-i-generate-indices-from-vertex-list-in-linear-time

Nálam az std::set find parancsa néha bugzott (nem tudom, h a bemenő adat vagy esetleg a msvc stl bugija-e).
Mindenesetre több millió vertexre 1-2 mperc alatt lefutott 2 ghz-s gépen.
alias aalberik
   
Instalok - Tag | 530 hsz       Online status #204715   2014.09.07 21:56 GMT+1 óra  
Működött úgy is a dolog. Ahhoz használtam egy mapet és egy vectort.
Kód:
map<Vector3, int32>
vector<map<..>::const_iterator>

Egy új vertexnél megnéztem, hogy benne van-e a mapben, ha igen, akkor visszaadtam a mapben tárolt indexet, ha nem, akkor hozzáadtam először a maphez egy új elemet, majd a vektorban is eltároltam a map iterátorát. Így, ha kellett a pozíció, az index segítségével megindexeltem a vektort, ami megadta az iterátort, aminek meg elkértem a kulcsát. Kicsit nyakatekert lett, de működött.

A másik út pedig az, hogy egyetlen setem van:
Kód:
set<Vector3>

Új vertex felvételekor szintén megvizsgálom, hogy benne van-e, ha nincs, akkor hozzáadom, végül mindenképpen visszaadok erre a setre mutató iterátort. Ezt tárolom el háromszögenként pontok gyanánt. Ekkor viszont a linken látható algoritmus nem működik, marad a brute-force összehasonlítás, pozíciók alapján.

Harmadik megoldás pedig az lenne, hogy az elsőt használjam, csak valamilyen értelmes adatszerkezettel.

   
syam - Törzstag | 1491 hsz       Online status #204714   2014.09.07 20:34 GMT+1 óra  
Jaja brute force, az izgalmas része a szomszédos vertexek felismerése.
alias aalberik
   
Instalok - Tag | 530 hsz       Online status #204713   2014.09.07 20:23 GMT+1 óra  
Ahogy így gyorsan ránéztem, ez is csak annyit csinál. Végigmegy a háromszögeken, és a még meg nem vizsgált háromszögekkel összehasonlítja, hogy van-e közös oldaluk. Végül is előfordulhat, hogy nincs ennél jobb megoldás, jó eséllyel ezt úgy is csak egyszer kell megcsinálni. Köszi a segítséget!

szerk.:
No mondjuk, ha így akarja az ember csinálni, akkor a háromszögekből ki kell menteni a (unique) pontokat, ezeknek megfelelően csak indexeket tárolni a háromszögnél, gondolom erre utaltál, amikor az indexelt vertex buffert írtad. Ennek a 22. oldalán is erről van szó, ha jól értettem.

Ezt a hozzászólást Instalok módosította (2014.09.07 20:36 GMT+1 óra, 1018 nap)

   
syam - Törzstag | 1491 hsz       Online status #204712   2014.09.07 20:15 GMT+1 óra  
Indexelt vertextömb + ahhoz tartozó háromszögek kellenek.

http://lwjgl.org/forum/index.php?topic=2407.0;wap2 - innen a setConnectivity fgv ( a plane itt háromszöget jelent). - ezt azt az algoritmust soha sem akartam megérteni

A végeredmény az, hogy minden háromszögnek tudni fogod a 3 szomszédját. Ahol nincs szomszéd ott -1 lesz a háromszögindex.
alias aalberik
   
Instalok - Tag | 530 hsz       Online status #204711   2014.09.07 19:47 GMT+1 óra  
No még mindig leakadtam valamin. Kézzel megadni nem egy nagy feladat egy navmesht, de első körben egy modellből szeretném betölteni. Azon gondolkozok, hogy a kapcsolatokat hogy a leggyorsabb kiépíteni. Annyit kell ugye megállapítani, hogy melyik két háromszög a szomszédos, ami akkor igaz, ha van azonos oldaluk. Először azon gondolkoztam, hogy megnézem az eddigi háromszögeket, és megkeresem, hogy van-e olyan oldala (két vertexe), ami megegyezik az új háromszög bármely oldalával. Ez viszont egyre növekvő futásidejű lesz, és bizonyára lehet okosabban is csinálni.

Alapvetően inputnak csak egy háromszöglistám van, akár obj-ból, vagy bármi másból.

   
Instalok - Tag | 530 hsz       Online status #204708   2014.09.07 18:03 GMT+1 óra  
Ah, értem már! Köszi!

Nem, egyelőre azt akarom elérni, hogy manuálisan épített navmeshre szépen fusson egy útkereső, lehetőleg még gyorsan is. Szóval még nincs se recast, se detour, meg semmi fancy dolog.

   
syam - Törzstag | 1491 hsz       Online status #204707   2014.09.07 17:27 GMT+1 óra  
Én anno (2012. aug. 9 svn log szerint) megértettem és annyi maradt meg belőle, hogy nem véletlen a tölcsér elnevezés.
Vizsgálandó pontból elindulva a "portálokhoz" két szakaszt készítünk. Ez adja a bizonyos tölcsért, A bal oldali szakasz jobb oldalán van a jobb oldali szakasz bal oldalán pedig a bal.
Ahogy haladunk "előre" a portálokon a tölcsér egyre szűkül. Egyszer pedig elérünk egy olyan "portálhoz", ahol a tölcsér "kifordul" vagyis a bal szakasz bal oldalára kerül a jobb oldali szakasz vagy a jobb oldali szakasz jobb oldalára a bal.
Attól függően hogy melyik következik be a portál bal vagy jobb oldali pontjából lesz "sarok". Ezt a sarkot eltároljuk és innen indítjuk tovább az algoritmust amíg el nem jutunk e végpontba.

És igen, ezt egy A*-gal kiválasztott navmesh poligon-listára kell lefuttatni

Navmeshre a recastnavigation-t használod?
alias aalberik
   
Instalok - Tag | 530 hsz       Online status #204706   2014.09.07 16:13 GMT+1 óra  
Google első találata a simple stupid funnel algorithm. Kicsit nehezen tudtam úgy követni a kódot, ezért gyorsan átfirkantottam c++ra - fogalmam sincs, hogy fordul-e, Notepad++ powa .

Maga az algoritmus még nem jött át teljesen. Ha jól értem, a portalok lesznek a navmesh háromszögeinek azon oldalai, amelyek egy szomszédos háromszöggel közösek. A left-right vertexeket pedig a körüljárási irány határozza meg? Minden esetre ezeket a portalokat mondjuk egy A* útkeresővel találom meg, amit lefuttatok azon gráfra, amely a háromszögek középpontjaiból és azok közötti szomszédossági kapcsolatokból áll.

No, minden esetre ki kellene próbálni, az a biztos. A c++ változat itt:
Kód:
void funnel(const Vector2& _from, const Vector2& _to)
{
    static Portal* fromPortal = new Portal();
    static Portal* toPortal = new Portal();
    static std::vector<Portal*> portals; // input
    static std::vector<Vector2> points; // output
   
    // start from scratch
    portals.clear();
   
    // add start
    fromPortal->left = fromPortal->right = _from;
    portals.push_back(fromPortal);
   
    // add portals between adjacent nodes
    getPortalsFromNavmesh(_from, _to, portals);
   
    // add destination
    toPortal->left = toPortal->right = _to;
    portals.push_back(toPortal);
   
    // get smooth path
    stringPull(portals, points);
}

void stringPull(const std::vector<Portal*>& _portals, std::vector<Vector2>& _result)
{
    _result.clear();

    Vector2 portalApex = portals[0]->left;
    Vector2 portalLeft = portals[0]->left;
    Vector2 portalRight = portals[0]->right;
   
    uint32 apexIndex = 0;
    uint32 leftIndex = 0;
    uint32 rightIndex = 0;
   
    _result.push_back(portalApex);
   
    for (uint32 i = 1; i < _portals.size(); ++i)
    {
        const Vector2& left = portals[i]->left;
        const Vector2& right = portals[i]->right;
       
        // update right vertex
        if (triarea2(portalApex, portalRight, right) <= 0.0f)
        {
            if (Vector2::nearEqual(portalApex, portalRigt) || triarea2(portalApex, portalLeft, right) > 0.0f)
            {
                portalRight = right;
                rightIndex = i;
            }
            else
            {
                _result.push_back(portalLeft);
               
                portalApex = portalLeft;
                apexIndex = leftIndex;
               
                portalRight = portalApex;
                rightIndex = apexIndex;
               
                i = apexIndex;
                continue;
            }
        }
       
        // update left vertex
        if (triarea2(portalApex, portalLeft, left) >= 0.0f)
        {
            if (Vector2::nearEqual(portalApex, portalLeft) || triarea2(portalApex, portalRight, left) < 0.0f)
            {
                portalLeft = left;
                leftIndex = i;
            }
            else
            {
                _result.push_back(portalRight);
               
                portalApex = portalRight;
                apexIndex = rightIndex;
               
                portalLeft = portalApex;
                leftIndex = apexIndex;
               
                i = apexIndex;
                continue;
            }
        }
    }
   
    _result.push_back(portals[portals.size() - 1]->left);
}

struct Vector2
{
    float32 x;
    float32 y;
   
    // ctor, copy ctor, operators, ...
   
    static bool nearEqual(const Vector2& _a, const Vector2& _b);
    static Vector2 operator-(const Vector2& _a, const Vector2& _b);
};

struct Portal
{
    Vector2 left;
    Vector2 right;
};

float32 triarea2(const Vector2& _a, const Vector2& _b, const Vector2& _c)
{
    const Vector2 a(b - a);
    const Vector2 b(c - a);

    return (b.x * a.y - a.x * b.y);
}

   
Instalok - Tag | 530 hsz       Online status #204703   2014.09.07 14:23 GMT+1 óra  
Köszi, rákeresek, bizonyára tele van az internet vele. Elég népszerű ez a navmesh dolog, úgy vettem észre, talán nem is véletlenül.

   
syam - Törzstag | 1491 hsz       Online status #204702   2014.09.07 14:17 GMT+1 óra  
Funnel (tölcsér) algorithm a varázsszó ^^
alias aalberik
   
Instalok - Tag | 530 hsz       Online status #204701   2014.09.07 14:09 GMT+1 óra  
Adott egy navmesh, azaz adottak háromszögek illetve a közöttük lévő kapcsolatok. Alap esetben felépítem a gráfot például a háromszögek középpontját felhasználva (piros gülük). Ezen fut az egyszerű A* útkereső.

A kérdésem az lenne, hogy mi alapján egyszerűsítik az utat? Csak a középpontokat felhasználva a piros utat kapom meg, egyszerűsítés után pedig a zöldet. Nem igazán tudom erre a szakszót, így ötletem sincs, hogy igazából mire keressek.


   
Pretender - Törzstag | 2498 hsz       Online status #202025   2014.03.16 17:39 GMT+1 óra  
Inkább az a kérdéses, hogy az útvonalakat hogy célszerű egyszerűsíteni. Nyilván brute-force megoldást lehet írni, de az nem lesz túl hatékony. Nem is a mesh meghatározása a kérdéses, hanem azok "körbejárása". De egyelőre kikötöttem egy grid-based A* algoritmusnál. Úgyis van térfelosztás, egy max 100x100-as griden kell majd utat keresni, azt meg illik akadás-mentesen tennie.

   
ddbwo - Tag | 1625 hsz       Online status #202023   2014.03.16 16:45 GMT+1 óra  
A vertexekből konvex hull-t csinálsz, kicsit kinagyítod és a külseje lesz az útvonal. Ha csak ilyen körbejárható akadályok vannak, akkor nem annyira érdekes az útkeresés, mindenképpen közelebb jut a célhoz, beakadni nem fog.
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 #202014   2014.03.15 12:09 GMT+1 óra  
Azon gondolkoztam, hogy nem lehetne-e az útkeresést "megfordítani", azaz nem a bejárható területeket jelöljük ki, hanem azt, ahova nem lehet menni.

Csodálatos ábra:


Hirtelen ötletként jutott eszembe, hogy megnézem, hogy az adott pozíciótól a következő pozícióig keresztezne-e az utunk valamilyen bejárhatatlan részt. Ha igen, akkor kiszámolom a metszéspontokat, majd a kisebb kerületű rész lesz az út. (az ábrán kék)

Ez ugye viszont nem tökéletes, mert az út optimalizálható (az ábrán zöld). Amennyire én tudom, ezt navmesh esetén is valahogy meg kell tenni, szóval bizonyára léteznek rá algoritmusok. További problémát jelenthet még az, ha több ilyen tárgyat "keresztezek", de az igazából az út-optimalizálást bonyolítja csak, az alapelv ugyan az.

Ami viszont kevésbé tetszik, hogy ez kb. le is korlátoz 2D-re. Nem nagyon tudom elképzelni, hogy hogyan működhetne 3D-ben (ha egyáltalán 2D-ben lehetséges). Nem tudom... szerintetek? Érdemes elindulni ilyen irányban?

szerk.:
Aha, másnak is eszébe jutott már. Bár az implementáció nem tökéletes, mert ki lehet olyan esetet hozni, hogy a végén egy kis kerülővel megy, mivel azt csinálja, hogy a legközelebbi waypointot keresi meg, ami néha nem túl nyerő.

Ezt a hozzászólást Pretender módosította (2014.03.16 10:24 GMT+1 óra, ---)

   
syam - Törzstag | 1491 hsz       Online status #201951   2014.03.11 16:11 GMT+1 óra  
Próbálkozott már vki inverz kinematikával és tud esetleg szebb, de nem sokkal drágább megoldást a CCD-nél?
alias aalberik
   
Fisher007 - Tag | 94 hsz       Online status #199257   2013.11.19 12:22 GMT+1 óra  
Idézet
versio :
amugy halott technologia, felesleges bele az ido



Ezt miből gondolod?
   
ddbwo - Tag | 1625 hsz       Online status #199253   2013.11.19 11:24 GMT+1 óra  
Idézet
versio :
"Valaki foglalkozott már Oculus Rifttel?"

carmackot kerdezted ?

amugy halott technologia, felesleges bele az ido



Mennyire lehet nehéz?

renderscene();
swapbuffer(&left);
renderscene();
swapbuffer(&right);

A két scene közt a különbség max annyi, hogy a kameravektortól el kell tolni a renderkamerát balra, illetve jobbra a játékegységben megfelelő 2,5 cm-t. Magyarul szem távolságra. Tehát vsz felezi az FPS-t is.
---

Mikor vörös-cián képeket buheráltam crysis-ből oldalazós trükkel, akkor minden úgy nézett ki, mint valami karton doboz. De egyre több poly van, úgyhogy vsz előbb-utóbb bekerülhet a hétköznapi dolgok közé.
A játékosoknak viszont elég gond, ha felezi vmi az fps-t. Hánytató is lenne egy akadozó 3D-s fps.
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
   
syam - Törzstag | 1491 hsz       Online status #199252   2013.11.19 11:20 GMT+1 óra  
Tapasztalatokra lennék inkább kíváncsi, ha vannak :3
alias aalberik
   
versio - Tag | 659 hsz       Online status #199251   2013.11.19 11:09 GMT+1 óra  
"Valaki foglalkozott már Oculus Rifttel?"

carmackot kerdezted ?

amugy halott technologia, felesleges bele az ido
   
syam - Törzstag | 1491 hsz       Online status #199249   2013.11.19 10:39 GMT+1 óra  
Valaki foglalkozott már Oculus Rifttel?
alias aalberik
   
StrykerKKD - Tag | 30 hsz       Online status #198982   2013.11.08 14:46 GMT+1 óra  
Egyébként ha csak appot akarsz, akkor arra bőven jó egy HTML5-ős megoldás.
   
zeller - Törzstag | 464 hsz       Online status #198974   2013.11.08 11:35 GMT+1 óra  
Ezt most talaltam
http://kivy.org/
Borsinak kosz az SO linket.
Erdemes ranezni sztem

   
syam - Törzstag | 1491 hsz       Online status #198972   2013.11.08 11:08 GMT+1 óra  
Gui alatt azt értem amit a wiki is és ahogy nézem elég sok tutorial van, hogy kell sdllel "összetett" guit készíteni ill. a ceguit is össze lehet házasítani vele.
Szó mi szó, jó lehet az sdl "már önmagában" is :3
alias aalberik
   
glezmen - Törzstag | 381 hsz       Online status #198969   2013.11.08 10:14 GMT+1 óra  
Idézet
syam :
Az SDL tudomásom szerint nem tud guit. Jól tudom?



attol fugg mit ertesz GUI alatt. A GUI mozaikszo ugye 'grafikus felhasznalo feluletet' jelent, az SDL meg ad grafikat, szoval ilyen ertelemben nyilvan tudja.
Ha a GUI alatt elore elkeszitett widgeteket (gombok, textedit, stb) ertesz, akkor azt valoban nem tudja alapbol, de vannak ilyen kulso libek is hozza (bar en meg egyet sem probaltam).

Ha egyszeru GUI kell (gombok, tobb kepernyo, ilyesmi) akkor az SDL boven jo.
Ha bonyolult UI (menuk, faszerkezet, texteditorok, stb) akkor inkabb Qt, bar ahogy mondtam, ott nem tudom hogy mennyire teljes koru a tamogatasa mobil platformokon, illetve nullarol indulva azert kell egy kis ido mire az ember atlatja es megtanulja (onnantol viszont Qrva jo )
   
zeller - Törzstag | 464 hsz       Online status #198966   2013.11.08 06:46 GMT+1 óra  
Nem hagyomanyos ertelembe vett jatekot irnek, csak egy gui appot, igaz nem nativ kinezettel.
Lehet, hogy maradok az SDL-nel emiatt, a qt valoban tul nagy, es a sajat widgeteket ugyis meg kell rajzolni...

   
borsi - Tag | 180 hsz       Online status #198963   2013.11.07 22:52 GMT+1 óra  
Még néhány unity alternatíva: http://www.waveengine.net/ http://v-play.net/ http://stackoverflow.com/questions/17584717/2d-cross-platform-game-development-engines. Azért nem véltelen, hogy unity manapság talán a legnépszerűbb indie engine.

   
syam - Törzstag | 1491 hsz       Online status #198961   2013.11.07 22:29 GMT+1 óra  
Az SDL tudomásom szerint nem tud guit. Jól tudom?
alias aalberik
   
glezmen - Törzstag | 381 hsz       Online status #198960   2013.11.07 22:15 GMT+1 óra  
Idézet
zeller :
Azon gondolkoztam, hogy leszamitva a unityt, van-e olyan dolog, ami valoban write once run everywhere, legalabbis andorka, makk, paci, szifon negyszogben. Azaz a relevans platformokon.
A bongeszoben futo alkalmazasokat most elvetem, mert az kevesnek tunik.
Arra jutottam, hogy a c++ az egyetlen mindenhol tamogatott nyelv (ugye iosre is lehet kompilalni?)
Nade
van olyan GUI lib ami hasonlo kvalitasokkal bir?
Qt esetleg? 5.2-vel igerik mindenhova...
Valakinek tapasztalata van ilyen total multiplatform ideakkal?



Qt5 mar alakul, bar pont a heten neztem, azert meg nem teljes a mobilos funkcionalitasa.
Ami nekem tokeletesen bevalt, es szinte tokeletesen igaz ra a 'write once run everywhere' vagy legalabbis a 'write once build everywhere', az az SDL2.
Ugyanaz a kod fordult windowsra, Linuxra, OSX-re, Androidra, iPhone-ra (meg PSP-re, stb).
A specialis dolgok kezelesehez kell egy-ket ifdef (pl. filekezelesnel Android eseteben kell egy fuggvenyhivas ami megmondja hogy mi az SD kartya vagy a belso memorianak az app altal alapban hasznalhato path-a, desktopon ez nyilvan nincs, ott mas a platform logikaja), de ez a komplett projectben is csak kb. tucatnyi sor.
   
syam - Törzstag | 1491 hsz       Online status #198952   2013.11.07 18:12 GMT+1 óra  
A cuccom fut 4 platformon még ha nem is teljesen mature a támogatás mindenhol

Sajnos guit nem igen találtam ami mindenhol lenne - kivéve a qt, de az túl nagy nekem ill. amit használok fltk azt cross-platformnak hívják.
alias aalberik
   
zeller - Törzstag | 464 hsz       Online status #198944   2013.11.07 16:41 GMT+1 óra  
Jobb hijan.
Azon gondolkoztam, hogy leszamitva a unityt, van-e olyan dolog, ami valoban write once run everywhere, legalabbis andorka, makk, paci, szifon negyszogben. Azaz a relevans platformokon.
A bongeszoben futo alkalmazasokat most elvetem, mert az kevesnek tunik.

Arra jutottam, hogy a c++ az egyetlen mindenhol tamogatott nyelv (ugye iosre is lehet kompilalni?)
Nade
van olyan GUI lib ami hasonlo kvalitasokkal bir?
Qt esetleg? 5.2-vel igerik mindenhova...

Valakinek tapasztalata van ilyen total multiplatform ideakkal?
Vagy unity ftw?

   
Pretender - Törzstag | 2498 hsz       Online status #197970   2013.10.05 15:42 GMT+1 óra  
Shadow mapping #1:
- draw geometry into shadowmap
- draw geometry with shadow computation

Shadow mapping #2:
- draw geometry into shadowmap
- draw geometry
- use depth and create shadows
- use a postprocess pass to apply shadows

Problémáim:
#1: ezzel a módszerrel a shadow eredményen nem használható semmilyen postprocessing (pl. blur), cserébe geometriánként meghatározhatom, hogy melyikre hasson árnyék
#2: ez az előzőnek kb. az ellentéte: használható az eredményen postprocessing, cserébe ugye egybe van, így nem tudom meghatározni, hogy melyik geometriára hasson az árnyék

Ez csak azért érdekes, mert ha pl. van olyan alphablendes cuccom, amit pl. nem szeretnék, hogy beárnyékoljon, akkor az 1. tűnik jobb megoldásnak, annak viszont vannak hátrányai.

Esetleg egy shadow mapping #3:
- draw geometry into shadowmap
- draw geometry
- draw geometry again and compute shadows
- use a postprocess pass to apply shadows

Ez a kettőnek a keveréke, cserébe 3x van kirajzolva a jelenet (ha nem akarok MRT-t használni)

   
Pretender - Törzstag | 2498 hsz       Online status #197764   2013.09.30 08:37 GMT+1 óra  
Át fogom gondolni még egyszer ezt a deferredet. Most pl. úgy van, hogy lineáris depthé írom át a depthbuffer tartalmát (hogy ne kelljen külön textúrát feltöltenem). A transparent objecteket pedig úgy renderelem, hogy lekérem a depthet a textúrából, és ha az adott pixel depth > olvasott_depth akkor discard.
Ez ugye a hardwares depth test kiesése miatt lassabb. Ha meg külön targetbe töltöm, akkor azért lassabb az egész renderelés. A forwardnál meg ugye alapvetően nincsenek ilyen transparentes problémák. Arról nem is beszélve, hogy tetszőleges material használható, míg deferrednél trükközni kell.

Syam, esetleg pár szót tudnál az újabb dolgokról írni? Melyik érné meg, stb. Esetleg valami jó kis paper. Köszi!

   
ddbwo - Tag | 1625 hsz       Online status #197749   2013.09.29 21:57 GMT+1 óra  
Erről az a reklám jutott eszembe, hogy:
"megmutatom mit kell tennie a digitális átállás során, ha előfizetéssel rendelkezik".

xD
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
   
syam - Törzstag | 1491 hsz       Online status #197748   2013.09.29 21:48 GMT+1 óra  
Idézet
ddbwo :
Idézet
syam :
Mellesleg a deferred render kezd kimenni a divatból :3



Akkor mit csinálnak helyette? Vagy csak a fényre értve?



Mindenféle módosított forward rendering, mint pl forward +.
alias aalberik
   
ddbwo - Tag | 1625 hsz       Online status #197745   2013.09.29 21:40 GMT+1 óra  
Idézet
syam :
Mellesleg a deferred render kezd kimenni a divatból :3



Akkor mit csinálnak helyette? Vagy csak a fényre értve?
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
   
syam - Törzstag | 1491 hsz       Online status #197744   2013.09.29 21:30 GMT+1 óra  
HDR nélkül az ilyen nehezen megy. Van olyan technika, h RGBM encoding; ez megy additív blendeléssel is.
Mellesleg a deferred render kezd kimenni a divatból :3
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #197741   2013.09.29 21:21 GMT+1 óra  
Az bizony, de lényegesen gyorsabb. A G-buffer így sem bandwidth-barát. És elég fájdalom ez a 64 bites rendertarget is. Negatív fényértékeket meg nem írunk ki, ejj!

   
fpeti - Törzstag | 1280 hsz       Online status #197739   2013.09.29 20:55 GMT+1 óra  
Én régebben úgy csináltam, hogy csak a fény felét írtam ki a bufferbe, a legvégső kompozíciónál (diffúz+fény) felszoroztam a fényt 2-szeresére, így jó fényes lehet a kép. (Ezt még shader nélkül is meg lehet csinálni.)
Most inkább 16bites lebegőpontos textúrát használok, mondjuk ott meg vigyázni kell a negatív színértékekre, mert akkor 'sötét fényt' renderel.. mire rájöttem.
Lehet alfában is lehetne pár extra bitet tárolni r,g,b-nek, de ezt kényelmesen olyan HW-n lehetne, amin egy lebegőpontos textúra sem okoz gondot.

Amúgy legutóbb a Carmack is megmondta, hogy 8bites textúrában tárolni normálokat csúúúúnya dolog.
   
Frissebbek | Korábbi postok
[1] [2] > 3 < [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [27]