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
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] > 15 < [20] [25] [27]
Kuz - Törzstag | 4455 hsz       Online status #136073   2010.06.17 19:01 GMT+1 óra  
Idézet
Pretender :
tagokra bontod a felbontast, pl. 1, 2, 0, 4, x, 7, 6, 8, majd ezeket kirajzolod?


Igen, valami ilyenen gondolkodok én is, csak még azt nem tudom hogy mi lenne erre a legszebb megoldás.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Asylum - Törzstag | 5455 hsz       Online status #136051   2010.06.17 17:26 GMT+1 óra  
Szerintem már el is ment
Én sem értem egyébként
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
bit.0x8000 - Törzstag | 574 hsz       Online status #136049   2010.06.17 14:56 GMT+1 óra  
Gondolom a probléma abból ered, hogy a font nem monospace...
Egyébként az megoldható, hogy egy képfájlon egy sorban elhelyezed a betűket, egy szövegfájlban leírod a szélességüket (amiből futásidőben kiszámolod a karakterek pozícióját a képfájlon belül), csinálsz egy karakter tömböt (vagy string-et), ahol a karekterek sorrendje megegyezik a képfájlon bellüliekkel, ezek után már egyszerű tömbindexeléssel használható a dolog.
Végül is ez a megoldás működik, de nem a legszebb, én mobiltelefonos java-ban használtam utoljára...
   
Joga - Törzstag | 1791 hsz       Online status #136048   2010.06.17 14:50 GMT+1 óra  
vagy kirajzolod középree az x-et, aztán jobbra igazítva a szélességet, balra igazítva a magasságot
(ಠ ›ಠ) Stewie!

   
Pretender - Törzstag | 2498 hsz       Online status #136047   2010.06.17 14:45 GMT+1 óra  
tagokra bontod a felbontast, pl. 1, 2, 0, 4, x, 7, 6, 8, majd ezeket kirajzolod?

   
HomeGnome - Szerkesztő | 2919 hsz       Online status #136046   2010.06.17 14:41 GMT+1 óra  
Középre rendezés:

x = ( amennyi_helyed_van - ( karakterek_száma * egy_karakter_szélessége) ) / 2

very easy..

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
Matzi - Szerkesztő | 2521 hsz       Online status #136045   2010.06.17 14:40 GMT+1 óra  
Dictionary? Hashmap? Lista?
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
HomeGnome - Szerkesztő | 2919 hsz       Online status #136043   2010.06.17 14:36 GMT+1 óra  
Kuz
A probléma az, hogy amikor ott van, hogy
"1440 x 900"
azt hogy lehet okosan kiiratni úgy, hogy az 1-es helyére az 1-esnek megfelelő image kerül, a 4-es helyére a 4-esnek megfelelő, etc.

esetleg egy for ciklussal és egy tömbindex-xel?

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
HomeGnome - Szerkesztő | 2919 hsz       Online status #136042   2010.06.17 14:33 GMT+1 óra  
Gondolom a függvény megkap 2 int-et (szélesség, magasság) amiket mondjuk itoa -val sztringgé konvertálsz, azt pedig már könnyű karakterenként kirajzolni, vagy melyik lépés nem megy?

Klikk, a JF.hu bulvárlap.
Klikk #6 WIP: 30% (Kuz, sade, ramoryan...)
   
Kuz - Törzstag | 4455 hsz       Online status #136041   2010.06.17 14:27 GMT+1 óra  
Joga : hát kvázi igen. A gond, hogy a számok designjának meg kellene egyeznie a többi elem designjával, ezért van legyártva 0-9ig az összes egész szám, és külön egy X is. A probléma nyílván nem azzal van, hogy egy számot stringgé alakítsak (talán még azt is meg tudnám oldani, hogy egy x-et közéjük vágjak ). A probléma az, hogy amikor ott van, hogy
"1440 x 900"
azt hogy lehet okosan kiiratni úgy, hogy az 1-es helyére az 1-esnek megfelelő image kerül, a 4-es helyére a 4-esnek megfelelő, etc. A ' < ' és ' > ' felbontásléptető gombok közti középre rendezés megint érdekes lesz, de egyelőre ez legyen meg.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
bit.0x8000 - Törzstag | 574 hsz       Online status #136040   2010.06.17 14:21 GMT+1 óra  
Ha jól emlékszem, az XNA-ban van beépített TTF kezelés, nem lenne egyszerűbb, ha a rajzolt betűkészletből gyártanál egy ttf fájlt? Nem hiszem, hogy túlzottan bonyolult lenne. (Bár az is lehet, hogy igen. )
   
Joga - Törzstag | 1791 hsz       Online status #136039   2010.06.17 14:20 GMT+1 óra  
Mármint a szélesség és magasságból akarsz( 1024, 768 ) stringet( "1024 x 768" ) -at csinálni?
(ಠ ›ಠ) Stewie!

   
Kuz - Törzstag | 4455 hsz       Online status #136038   2010.06.17 14:14 GMT+1 óra  
Az egységes deisgn miatt a menüben használt betűkészelt is rajzolva van, ugyanazzal a stílussal, mint ahogyan a többi menüelem is.
http://yscik.com/jf/kep.php?id=98f31d52e
Sima szövegkiírásnál használok olyan fontot, de az itt most nem játszik.

Szerk.: Na várjatok! Nekem nem azzal van bajom, hogy milyen felbontásban milyen image-eket használok! Nekem a felbontás számszerű kiiratásával van problémám, hogy pl azt, hogy 800 x 600, azt hogy írjam ki úgy, hogy az 1680 x 1050-et is ugyanaz a fgv írja ki.
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
syam - Törzstag | 1491 hsz       Online status #136037   2010.06.17 14:13 GMT+1 óra  
Idézet
bit.0x8000 :
TrueType font-ok használata?



vagy kb. 3-4 féle font textúra elég szokott lenni a különböző felbontásokhoz.
Esetleg egy "intelligens" downsample kell, ami egy db, nagy felbontású font textúrát képes tetszőleges mértékben kicsinyíteni.
alias aalberik
   
bit.0x8000 - Törzstag | 574 hsz       Online status #136036   2010.06.17 14:06 GMT+1 óra  
TrueType font-ok használata?
   
Kuz - Törzstag | 4455 hsz       Online status #136034   2010.06.17 13:59 GMT+1 óra  
Elnézést, ha megszakítok egy témát, de nekem is lenne egy kérdésem.
Tegnap buzgálkodtam a settings beállító kódommal a játékomban, és eljutottam odáig, hogy tök jó lenne a felbontást is állíthatóra csinálni. Amikor kiírom, hogy pl : 800 x 600, az karakterenként egy image (0-9ig vannak image-ek erre a célra, illetve az x is egy külön image). Namármost, ha a kártyám támogat 20 féle felbontást, akkor valami dinamikus módszer kellene arra, hogy egy ilyen értéket ki tudjak írni (olyat nem akarok, hogy if(width == 800) ...). Szóval mi lenne erre a legkézenfekvőbb módszer? Valahogy osszam fel a szélesség/magasság értékeket karakterekre? Vagy van valami szebb megoldás is?
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
Pretender - Törzstag | 2498 hsz       Online status #136013   2010.06.16 23:27 GMT+1 óra  
Valoban van neki, xbox live premium accounttal mukodik is
Talaltam viszont egy nagyon jo kis sample codet (en valahogy kodbol hamarabb megertem ), holnap nezegetem majd, most csak kiprobaltam

   
bit.0x8000 - Törzstag | 574 hsz       Online status #136012   2010.06.16 23:12 GMT+1 óra  
Pretender: Ha jól emlékszem, az XNA-nak van valami magas-szintű hálózatkezelő része (az már más kérdés, hogy milyen feltételekkel működik).
   
Pretender - Törzstag | 2498 hsz       Online status #136010   2010.06.16 22:58 GMT+1 óra  
Hat igen, karba biztosan nem fog veszni a megszerzett tudas es/vagy tapasztalat. Ugy nez ki, hogy itt van egy rovid osszefoglalo, nem nagyon olvastam bele, lehet, hogy nem is erre lesz szuksegem, de ahogy nezem, nem lesz annyira veszes (talan)

   
gaborlabor - Moderátor | 4449 hsz       Online status #136009   2010.06.16 22:56 GMT+1 óra  
Én amiket mondtam, azok mind arra vonatkoztak, hogy ha a lehető legalacsonyabb szinten (socketekkel) programozod a hálózati részt.
Ha már használsz valami wrappert, vagy magas szintű objektumorientált cuccot, akkor sok mindenben könnyebb dolgod lesz. Kismillió dolgot nem kell lekódolnod, hanem megoldják helyetted. Fogalmam nincs, hogy a .net-ben mi van, de a RakNet pl igen jó dolgokat tud (habár nekem felére sem lenne szükségem).
Én azért választottam a WinSock-ot, mert így legalább megtanulom közben a hálózat alacsonyabb szintű működését, aminek akkor is hasznát veszem, ha később magas szintű libet használok majd.

   
Pretender - Törzstag | 2498 hsz       Online status #136007   2010.06.16 22:51 GMT+1 óra  
Nem tudom melyik a bonyolultabb. Most meg nem latom at, azt se tudom mit kell megirni es mit nem, de remelem a fele bennevan a .net-ben

   
gaborlabor - Moderátor | 4449 hsz       Online status #136006   2010.06.16 22:49 GMT+1 óra  
Én így csináltam. De UDP-n is lehet küldözgetni, mert ha megírod a visszaigazolós-újraküldős dolgot, akkor tulajdonképpen UDP-n megoldod azt, ami miatt TCP-t használnál.

   
Pretender - Törzstag | 2498 hsz       Online status #136005   2010.06.16 22:43 GMT+1 óra  
Tehat erdemes hybrid megoldast hasznalni Ingame udp az adatkuldesre (es nemszamit, ha elveszik par csomag, mert ugyis eleg gyakran kuldi), de az ilyen nem sebessegigenyes muveleteknel (palyavaltas, chat uzenet /*bar ez relativ*/) meg TCP. Olle

   
gaborlabor - Moderátor | 4449 hsz       Online status #136004   2010.06.16 22:38 GMT+1 óra  
Asylum: ami nagyon gyakran jön a szervertől (tehát pl pozíció és sebesség vektor, ami fps-nél minimum olyan 20 Hz-el jön), annál természetesen nem számít, ha elveszik pár csomag. De pl chat üzenetek, meg vezérlő üzenetek a szervertől (töltsd be ezt és azt a pályát, alkalmazd ezeket a beállításokat stb.), azokat vagy TCP-n küldöd, vagy ha írtál UDP fölé egy saját protokollt akkor alkalmazni kell visszaigazolás-újraküldéses mókát mert az eléggé ciki ha egyik-másik kliens nem kap meg ilyen fontosabb üzeneteket.
A WoW megoldása a mozgásra szerintem multi fps-nél idegesítő lenne. Ha valakinek tré a kapcsolata, nem tudnád lelőni, mindenki másnál ugrálna. Ráadásul sokkal nehezebb lenne kiszűrni a csítelést. Szóval érdemes a mozgást is szerver oldalon számolni ilyen játékoknál.

   
Asylum - Törzstag | 5455 hsz       Online status #136002   2010.06.16 22:22 GMT+1 óra  
Nekem a wow megoldása szimpatikusabb: a mozgást a kliens számolja, tehát nagy lagg esetén is tudsz futkorászni, csak a többi player számára tünik ugy mintha ugrálnál.

Packet loss: érdemes foglalkozni ezzel? Tegyük fel hogy megérkezett az 1 2 3 6 7 számu csomag, tehát a 4 és 5 elveszett. Érdemes foglalkozni vele? Szerintem nem. Akkor viszont ezt ugy kell megoldani, hogy egy információegység az egy csomag legyen, tehát egy adatot ne darabokban küldjél mert az ugy már télleg szopás.

Egy kezdeti implementáciom nekem is van, csak mindig elfelejtem hogy müködik
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #136001   2010.06.16 22:01 GMT+1 óra  
Ejha, latom mar egy kicsit elmerultel a temaban, ami tenyleg eleg tagnak tunik. Akkor keresek majd valami papert, hatha irnak okos dolgokat (es hatha .net alatt konnyebb megcsinalni ), de igy elsore eleg bonyolultnak tunik, felek is tole

Ja, meg en valahogy ugy kepzelem el, hogy:
- a kliens elkuldi az inputokat (billentyu, eger, ..)
- a szerver ebbol kiszamol minden ugyes dolgot (mi lesz frissites utan a pozicioja, forgatas, utkozes stb.)
- a szerver visszakuldi a kliensnek az infot, ami beallitgat mindent, majd render.
Mint mondtad, erdemes kliens oldalon is szamolni a poziciot, forgatast, ilyesmit:
- szamolja a kliens is a kov. poziciot, es a tobbit
- ameg nem erkezik packet a szervertol, addig a kliens altal szamoltat hasznalja
- amikor megerkezik a packet, a szerver altal szamolt adatok felulirjak a kliens altal szamoltakat. (nagy latency eseten ez olyasmi lehet, hogy halad elore a jatekos, es vissza-vissza ugral )
Vagy valamit nagyon nem jol kepzelek el

   
gaborlabor - Moderátor | 4449 hsz       Online status #136000   2010.06.16 21:44 GMT+1 óra  
Mérlegelni kell, hogy mikor melyiket éri meg.
Egy gyors folyású multiplayer játékban a TCP még LAN-on is lassú. (Carmack a doom2 multis részét eredetileg TCP-vel írta meg, szoptak is vele az emberek...) Viszont a TCP megbízható(bb) átvitelt biztosít, így sok kódolástól kímél meg. Garantálja a csomagok átvitelét, sorban érkeznek meg, stb. Pl. egy körökre osztott stratégiai játékban még simán okés, viszont amikor ezredmásodpercek számítanak akkor felejtős.
Én megpróbáltam azt, hogy a játékomban az input állapotokat a kliensek TCP-n küldik a szervernek, hogy biztosan odaérjen, minden mást meg UDP-n. Nem vált be, ahogy átraktam azt is UDP-re, látni lehetett a különbséget.
Na hát ezért van az hogy az UDP fölé építeni kell egy egyszerűbb protokollt. Pl. sorszámozni kell a csomagokat, hogy ha rossz sorrendben érkeznek meg, akkor le tudd azt is kezelni, aztán meg kell oldani hogy a fontos csomagok elveszítéséről a feladó tudomást szerezzen, hogy újraküldhesse azokat. (A válasz-üzenetek amúgy is kellenek az RTT méréséhez.)
Nem kétnapos munka az biztos, főleg ha stabil hálózatkezelést akarsz. Nagyon nagyban függenek az elvárások attól, hogy mennyire gyors folyású a játék. Kb úgy van a sorrend, hogy az autós játékoknak kell a legböszmébb hálózati kód, aztán fps/tps realtime lövöldözés, és utána jön minden más. Meg aztán ezt az egészet össze kell hozni pl a fizikai számításokkal, az megint érdekes. (Egy jó darabig a Quake3-ban is sebességfüggő volt a fizika, aztán valami patch kijavította).

   
Pretender - Törzstag | 2498 hsz       Online status #135999   2010.06.16 21:12 GMT+1 óra  
Ejha, bonyolultabbnak hangzik, mint amilyen..
TCP-t azt max. Lan halozathoz erdemes hasznalni, mert lassu?

   
gaborlabor - Moderátor | 4449 hsz       Online status #135998   2010.06.16 20:47 GMT+1 óra  
Igen, az ilyen játékoknál minden fontosabb dolgot szerver oldalon kell számolni, viszont néhány dolgot (pl mozgásokat) kliens oldalon is kell (client side prediction) már a doom2 óta , különben nagyon ramaty lesz az egész. De persze a szerver oldalon számolt értékeket kell mindig helyesnek tekinteni, azzal felül kell írni a klienseknek a helyben számolt adatokat. A probléma ott jön be a képbe, hogy ha nagy a latency, akkor ugyebár a szervertől kapott adatok nem a jelenlegi hanem az x ezredmásodperccel ezelőtti állapotot írják le. Ezt az időt viszont mérni kell... UDP fölé írni kell egy saját protokollt, ami lehetővé teszi hogy mérd a hálózati átvitel sebességét az eltelt idővel (RTT, round trip time), és ezt fel kell használni jó pár helyen, pl a szervernek is ez alapján kell meghatároznia a frissítési rátát az egyes kliensek felé. (Ha túl nagy az RTT, akkor valszeg túl gyorsan küldte az adatokat a szerver -> lefloodolta a klienst, vissza kell venni a frissítési gyakoriságot, stb...)

Ez az egyik lehetőség (én ezt választottam), a másik, hogy elkezdesz használni valami magasabb szintű network libraryt, ami megoldja helyetted a csomagok eldobálását / sorbarendezését (mert ugye UDP ilyet nem csinál), meg még egy csomó mindent.

   
Pretender - Törzstag | 2498 hsz       Online status #135996   2010.06.16 20:30 GMT+1 óra  
Oke, koszi, azt majd megnezem akkor Valami kis egyszeru TPS jatekhoz kellene network kommunikacio. Ha jol sejtem az ilyen utkozesdetekt, meg hogy ki kit talal el azt szerveroldalon szamoljak, es packetbol minel kevesebbet kell kuldeni (mind a kliensnek, mind a szervernek)

   
gaborlabor - Moderátor | 4449 hsz       Online status #135994   2010.06.16 20:22 GMT+1 óra  
"Kicsit" tág témakör, mire vagy kíváncsi konkrétan?

Természetesen UDP alapú kommunikáció, szerver-kliens architektúrával, ez az alap.
Érdemes elolvasni a gaffer on games oldalon a networking-es irományokat....

   
Pretender - Törzstag | 2498 hsz       Online status #135993   2010.06.16 20:14 GMT+1 óra  
Ki milyen modszert ajanl multis jatekokhoz? (interneten keresztul, pl. CoD4 multi ) Valami olyasmi lenne jo, amihez van valami paper

   
Matzi - Szerkesztő | 2521 hsz       Online status #135838   2010.06.12 23:55 GMT+1 óra  
Az alapötlet működni látszik, de akadt 1-2 probléma.
A térbeliséget még csak-csak megoldom, mert ugye nem találkoznak pontosan, de ezzel nincs is gond. Mármint ugye mondjuk az egyik sík vízszintes, a másik meg szögben emelkedik, ugyan metszik egymást, de nem a határoló vonalat, hanem a belső területet, ami a következő miatt jelent problémát.
A probléma sokkal inkább az, hogy az egész logikája fordított kicsit. Hagyományos esetben ha az ember bármelyik falnak nekimegy, akkor ott meg kell állnia (illetve elcsúszik a mentén), itt viszont az egybelógó poligonok miatt nem így van, hiszen ami az egyiknek fal, a másiknak még belső terület is lehet. Ha csak annyit vizsgálok, hogy bármelyik sokszög területén tartózkodunk e, akkor nincs gond, de ez ugye nem számol kiterjedéssel. Sőt, még csak elegánsan elcsúsztatni sem nagyon lehet a fal mentén a karaktert. Könnyebb lenne a helyzet, ha a ténylegesen akadályozó szakaszokat ki lehetne nyerni, de a nem tökéletes térbeli illeszkedés miatt ez nagyjából lehetetlen.

Erre valami ötlet esetleg?
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Matzi - Szerkesztő | 2521 hsz       Online status #135777   2010.06.11 09:46 GMT+1 óra  
Azért írtam ide a kérdést, mert csak homályos elképzeléseim voltak a dologról, szóval leszámítva az itteni társalgásból nyert ötleteket, a dolog saját elgondolás. Persze ez nem jelenti azt, hogy jól működik, vagy hogy ne találhatta volna ki más is. A működőképességét majd ki fogom próbálni, ha érdekel valakit, majd bepostolom ide, hogy mire jutottam.

A gráf mérete szerintem nem fog nagy gondot jelenteni, mert csak a szomszédok érdekesek, vagyis a legnagyobb fokszám. Elvben egy normális térképen ez sem lesz túl nagy.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5455 hsz       Online status #135773   2010.06.10 23:51 GMT+1 óra  
Ez saját 5let? Mert igy leirva egész jol hangzik. Feltéve ha a gráfod nem túl nagy.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2521 hsz       Online status #135771   2010.06.10 22:53 GMT+1 óra  
No, az lesz, hogy lesz minden elemnek egy minimális mesh, ami a járható felületet szimbolizálja. A terep egy speciális elem lesz, állni fog egy magasságmezőből, és a járható területeket alkotó poligonokból. A terepen a poligon minden ponton a magasságmezőhöz igazodik (valójában nem, mert feleslegesen minek törjem is magasságeltérés miatt, de a játék úgy fogja tekinteni), a lerakott egyéb elemeknél meg beállítható lesz. Amikor odamegy a karakter két ilyen dolog találkozásához, akkor megnézem, hogy melyik utasítja magasabb szintre, arra illeszti rá. Itt lesz egy tűrés küszöb, amire még "fellép". Az elején ezekből a poligonokból generálok egy szomszédossági gráfot, az alapján, hogy melyikek metszik egymást, és csak a szomszédos sokszögekre vizsgálom meg, hogy átmegy e az emberünk. Így egy magasságtérképre könnyen illeszthető híd, amin át is lehet menni, meg el is lehet menni alatta.

Legalábbis elvben...
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Asylum - Törzstag | 5455 hsz       Online status #135748   2010.06.10 16:14 GMT+1 óra  
A Prey is hasonlo a mágneses izéivel.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2521 hsz       Online status #135742   2010.06.10 15:59 GMT+1 óra  
M4:
A legófigurákat leszámítva már van ilyen játék. Ha jól rémlik Sin-nek hívják, és egy elég régi FPS. Na jó, csak egy multiplayer pálya, de multiban vicces tud lenni.

syam:
Nem gáz, csak szakmai ártalom.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
syam - Törzstag | 1491 hsz       Online status #135740   2010.06.10 15:52 GMT+1 óra  
Idézet
M4 :
Hehe, ilyen engine van már?: http://www.davidairey.com/escher-loves-lego/
Meg kéne csinálni. +portálokat bele rakni
(A diablo 2-ben volt vizuális illúzió az arcane sanctuary-ben)



Gáz, ha a honlapon lévő alsó képről azt hittem első ránézésre, h a felső kép SSAO only rendere?
alias aalberik
   
M4 - Tag | 187 hsz       Online status #135738   2010.06.10 15:46 GMT+1 óra  
Hehe, ilyen engine van már?: http://www.davidairey.com/escher-loves-lego/
Meg kéne csinálni. +portálokat bele rakni
(A diablo 2-ben volt vizuális illúzió az arcane sanctuary-ben)

   
syam - Törzstag | 1491 hsz       Online status #135735   2010.06.10 15:15 GMT+1 óra  
A mesh tipusnak pont ez lenne a lényege: a meshhez tartozik a geometria és a magasság számoló algoritmus. A mesht teljesen szabadon bárhová és bármennyi példányban lehelyezheted az algo ugymond transzformálná a mesh koord. rendszerébe a játékost, megállapítaná tényleg ott van-e és kiszámolná a magasságot.
Az algoritmus legprimitivebb esetben egy "sima" matematikai függvény, legbonyolultabb esetben egy sweep teszt lenne.
A mesheket pedig ki lehetne gyüjteni octreebe, hogy gyors legyen a keresés.
alias aalberik
   
dvorgaz - Törzstag | 575 hsz       Online status #135733   2010.06.10 15:00 GMT+1 óra  
Ja hogy arra gondolsz, hogy lehetne hézagmentesen egymás mellé illeszteni két különböző objektumot?
Hát én azzal próbálkoznék meg, hogy valami csatlakozási pontokat adnék meg a modellekhez (egy vertex, vagy csont, vagy akármi), és két modell esetén úgy igazítanám őket, hogy ezek a "csatlakozók" egybeessenek. Szóval a gyakorlatban az aktuális elemet hozzá "snappelné" a már lerakott cucchoz. Bár valszeg kelleni fog valami orientáció is, hogy rendesen össze lehessen őket illeszteni.
   
Matzi - Szerkesztő | 2521 hsz       Online status #135731   2010.06.10 14:55 GMT+1 óra  
dvorgaz:
Ez eddig nyilvánvaló, de sajnos a különböző darabok közötti átmenetnél nehéz meghatározni, azok hogy tartoznak össze. És nem akarok gridet, lehetőleg szeretném elkerülni.

syam:
Szeretném egy adott grafikai elemre (pl híd) egyszer meghatározni, és onnan ha berakom egy pályára, akkor jó lenne ha működne mindig. Fontos, hogy nem szeretném az elemeket diszkrét pontokhoz igazítani, hanem jó lenne, ha teljesen tetszőleges helyre és irányba állítva működőképes lenne.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
syam - Törzstag | 1491 hsz       Online status #135723   2010.06.10 14:31 GMT+1 óra  
Nem kell raycastolni (csak hasonló algoritmus előbb ugy látszik nem fogalmaztam pontosan^^), hanem lenne egy algoritmus ami adott meshre meg tudja mondani, hogy elmozdulás és pozicio alapján megmondja, hogy milyen magasra kerültél. Akár előre is definiálhatsz mesh tipusokat (kocka, gömb, alagút, híd stb), amikre kitalálod a specializált magasság számoló eljárást:3
alias aalberik
   
dvorgaz - Törzstag | 575 hsz       Online status #135721   2010.06.10 14:27 GMT+1 óra  
A padló mesh háromszögeinek pl középpontját használod a gráf csomópontjaiként, és a szomszédos poligonok vannak a gráfban összekötve. Persze ha megvan az útvonal, akkor kicsit simítani kell rajta valahogy, mert cakkosan fognak rajta mozogni a karakterek.

Ami az editort illeti, gondolom a modellek nem önmagukban fognak szerepelni benne, hanem lesz hozzá valami egyéb információ, mondjuk xml-ben, pl tile alapú pálya esetén hogy hány mezőt foglal az az objektum stb. Ebben az esetben ebbe a fájlba el tudod tárolni a látható és az ütköző mesht is.
   
Matzi - Szerkesztő | 2521 hsz       Online status #135718   2010.06.10 14:12 GMT+1 óra  
dvorgaz:
Lényegében valami ilyesmire gondoltam, csak mivel elemekből editorban lehetne összreakni a pályát, jó lenne, ha az elemekre külön lehetne ezt a mesht definiálni, és a végén valahogy ezeket összekapcsolni. Csak nem tudom, hogy ez hatékony megoldás e, vagy van e valami jobb módszer.

M4:
A sok heihgtmap egy kicsit pazarlás, elvégre nem is igazán használná ki a lehetőségeket, és keresni benne is kicsit problémás.

syam:
Ez meg kicsit költséges minden objektumra mindig raycastolni. Ha lenne ergy egyszerűsített mesh, akkor arra még csak oké...


Hm... lehet, hogy az lesz, hogy a meshből kijelölök pár polygont, mint járható felület, némileg redukálom, vagy valahogy származtatok egy lowpoly mesht. Amikor a karakter megy, kicsit a pozíciója feletti magasságból raycastolok lefelé, így nem kerülhet feljebb, de esetleg lejjebb eshet... Nem is rossz ötlet, köszi srácok.
Már csak az útvonal kereséshez használatos gráfot kéne ebből leszármaztatni...
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
syam - Törzstag | 1491 hsz       Online status #135707   2010.06.10 12:02 GMT+1 óra  
Umm,
Lehetne olyasmi, hogy a tereptárgyakhoz elkészíteni egy üktözésvizsgáló jellegű raycast algoritmust, ami egy magassággal térne vissza. Ha nincs olyan tereptárgy ami lekezelné a főhőst akkor a heightmaptól lehetne kérni egy magasságot.
alias aalberik
   
M4 - Tag | 187 hsz       Online status #135706   2010.06.10 12:02 GMT+1 óra  
Az elején nem értettem mi a problémád, de így pl. csigalépcsővel már tényleg bonyolultabb. Most így hirtelen nem jut eszembe más, mint hogy több 2D-s ábra, a járható területekbe lenne rajzolva határvonal, amit ha átlép, megnézhetnénk melyik másik 2D-s ábrát kell majd használni.

   
dvorgaz - Törzstag | 575 hsz       Online status #135705   2010.06.10 11:56 GMT+1 óra  
Csinálhatnál egy láthatatlan lowpoly mesht, ami a járható talajfelületeket reprezentálná, aztán arra lehetne raycastelni, meg megoldani, hogy a karakterek ne tudjanak lemenni ezekről a poligonokról. Ezt pl lehetne úgy, hogy mozgatáskor ú pozíción raycastelsz, és a kapott magasság csak kicsit tér el az aktuálistól akkor odamehet, amúgy nem; vagy el lehetne tárolni mondjuk a poligonok szomszédait.

Mellesleg ezt a mesht akár útvonalkereséshez is lehetne használni.
   
Matzi - Szerkesztő | 2521 hsz       Online status #135703   2010.06.10 11:32 GMT+1 óra  
Ugrani illetve más módon magasságot változtatni nem lehetne, az említett játékban sem lehet.
De nem csak heightmapos terepet akarok, akár belső területeket is, vagy más grafikai objektumokat, például egy tornyot csigalépcsővel... Így egy adott ponton többször is átmehet a karakter, csak más magasságban.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] > 15 < [20] [25] [27]