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] [30] [35] [40] [45] [50] > 55 < [60] [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [141]
Germo - Tag | 40 hsz       Online status #128819   2010.03.12 09:41 GMT+1 óra  
Szerintem sokszor hasznos lehet belemenni ilyen elméleti programozásokba. Tetszik a kód tömörsége ... és nyilvánvalóvá teszi számomra a tényt amit jól tudok: lövésem sincs a C-hez.
Sikerült egy Z80 as, Turbo-Pascal ... nagy szünet ... flash vonalon elkerülnöm.
A végtelenbe és tovább!
   
bit.0x8000 - Törzstag | 574 hsz       Online status #128812   2010.03.12 01:05 GMT+1 óra  
Idézet
glezmen :
indithatnek most f*sza kis flame-et, de inkabb nem teszem, piisz



Miattam ne fogd vissza magad.
(Qt és GTK tekintetében amúgy teljesen pártatlan vagyok.)
   
glezmen - Törzstag | 381 hsz       Online status #128806   2010.03.12 00:02 GMT+1 óra  
Idézet
bit.0x8000 :
Mindent ésszel kell alkalmazni: A Qt biztosan sokkal fejlettebb, de ahova elég a GTK, oda azt kell használni...



indithatnek most f*sza kis flame-et, de inkabb nem teszem, piisz
   
bit.0x8000 - Törzstag | 574 hsz       Online status #128805   2010.03.11 23:39 GMT+1 óra  
Idézet
glezmen :
hat az egyszeruseggel vitaba szallnek, borzalmasan agyon van bonyolitva (mondjuk ahhoz kepest hogy OOP-t csinaltak 'C-ul' meg egesz OK)
gyorsnak valoban gyors azert en maradok a Qt-nal...



Mindent ésszel kell alkalmazni: A Qt biztosan sokkal fejlettebb, de ahova elég a GTK, oda azt kell használni...

písz
   
glezmen - Törzstag | 381 hsz       Online status #128804   2010.03.11 23:29 GMT+1 óra  
hat az egyszeruseggel vitaba szallnek, borzalmasan agyon van bonyolitva (mondjuk ahhoz kepest hogy OOP-t csinaltak 'C-ul' meg egesz OK)
gyorsnak valoban gyors azert en maradok a Qt-nal...
   
bit.0x8000 - Törzstag | 574 hsz       Online status #128802   2010.03.11 23:24 GMT+1 óra  
Idézet
glezmen :
ezt mar kitalaltak, ugy hivjak hogy GTK es szornyu



Az viszont legalább gyors és egyszerű, ahhoz képest mit számíthat az, hogy "szornyu" ?
   
glezmen - Törzstag | 381 hsz       Online status #128800   2010.03.11 23:09 GMT+1 óra  
Idézet
Most agyon fogtok vágni de oop "szimulálás" C-ben (unatkoztam):


ezt mar kitalaltak, ugy hivjak hogy GTK es szornyu
   
bit.0x8000 - Törzstag | 574 hsz       Online status #128799   2010.03.11 22:50 GMT+1 óra  
Idézet
Matzi :
A lag csökkentése szerintem túlságosan számolás igényes feladat, de érdemes megnézni, csak valószínűleg nem nyersz vele sokat.



Szerintem ha folyamatosan nagy a válaszidő, akkor egy "gyors" játéknál megfeszülhetsz, akkor sem lesz rendesen játszható (magánvélemény persze)...
   
Matzi - Szerkesztő | 2521 hsz       Online status #128791   2010.03.11 21:46 GMT+1 óra  
gaborlabor:
Alapvetően a karakter mozgását számolod a klienseden, és a szerver számolja a találatot, vagyis hogy ki hal meg, az mindig csak a szerveren múlik. És ha megnézed a legtöbb játékot, ott simán előfordul, hogy lagol a játék, de amíg a késleltetés kicsi, addig nem baj.

A lag csökkentése szerintem túlságosan számolás igényes feladat, de érdemes megnézni, csak valószínűleg nem nyersz vele sokat.

Amúgy meg ott ahol 10-20 ember gépfegyverrel lövi egymást (netán még botok is vannak), ott a lövedékek egyesével mozgatása nem szerencsés taktika.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
bit.0x8000 - Törzstag | 574 hsz       Online status #128787   2010.03.11 20:29 GMT+1 óra  
Idézet
Asylum :
Most agyon fogtok vágni de oop "szimulálás" C-ben (unatkoztam):

http://people.inf.elte.hu/asylum/programming/C/oop/



Még mindig hasznosabb, mintha flémeltél volna...

szerk: Nekem régebben olyan jutott eszembe, hogy unix socket-ek használatával külön futó programokat összehangolni oop-szerűen... Aztán másnapra kijózanodtam.

Ezt a hozzászólást bit.0x8000 módosította (2010.03.11 20:37 GMT+1 óra, ---)
   
gaborlabor - Moderátor | 4449 hsz       Online status #128781   2010.03.11 19:34 GMT+1 óra  
Sharp: köszi szépen a linkeket, valami ilyesmit kerestem!

   
Asylum - Törzstag | 5455 hsz       Online status #128777   2010.03.11 19:14 GMT+1 óra  
Most agyon fogtok vágni de oop "szimulálás" C-ben (unatkoztam):

http://people.inf.elte.hu/asylum/programming/C/oop/
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Sharp - Tag | 130 hsz       Online status #128776   2010.03.11 19:12 GMT+1 óra  
Ezt a véletlent, pont tegnap olvastam utána, hogy is működik ez.

http://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking ( ennek van magyar megfelelője is, most nem találom )

Itt le van írva, hogy bizony a kommunikáló felek küldözgetik az idejüket (tick!, diszkrét időintervallumokban történő frissitéskor), és még sok ínyencség: történeti tábla karbantartása, annak érdekében, hogy egy nagyobb latencyvel rendelkező játékos számára a szerver vissza tudja állítani minden objektum pozicióját abba a pillanatba, amikor a szóban forgó játékos például tüzelt. Inter- és extrapoláció, és a már elhangzott kliens oldali predikció( ahol is a szerver !nem! bízik a kliensben).

QuakeWorld, Quake 2, Quake 3 forráskódja elérhető, ezek mind megtalálhatóak bennük. Sőt a neten számos doksi van, ami segíti a forráskódok gyors megértését.

   
gaborlabor - Moderátor | 4449 hsz       Online status #128775   2010.03.11 19:07 GMT+1 óra  
A lentebb linkelt cikkben viszont azt írják (logikusnak is tűnik), hogy a szervernek van elsőbbsége, mindig a "szervernek van igaza", amit a kliensek látnak a világból, az mindig egy nagyon kicsit eltér a valós helyzettől, de nem baj, mivel a számítások is szerver oldalon történnek.
Ahogy Asylum leírta, úgy szerintem minden kliensen az összes többi kliens karaktere eléggé eltérő helyen lenne (lehetne), mint a szerveren, így például elég hülyén nézne ki, hogy te lősz, úgy tűnik hogy eltalálsz egy ellenfelet, de valójában meg nem, ezért nálad meghal/sebződik, szerver oldalon viszont nem, őnála meg megint más látszik.
Az a fajta megközelítés szerintem jobb, hogy a kliensek csak az input adatokat küldik el a szervernek, az számolgat amit kell, és az eredményt szétbroadcastolja az összes kliensnek. Ez az alapfelállás, erre jönnek a trükközések, pl az, hogy a kliens is számol, hogy ne legyen nagy latency mire megmozdulnak a dolgok, viszont a szervertől kapott adatokkal felülírja a saját számításainak eredményét. Így elméletileg mindig, minden kliens csak egy kicsit lesz lemaradva a valós helyzethez képest. Na, és itt jönne be a még durvább trükközés, hogy a kliens a szervertől kapott adatok alapján újra számol. Ezzel elméletileg akár 1-2 másodperces késleltetés esetén sem lenne nagyon durva a lagolás.

De mindegy, egyelőre megírom timestamp-ek nélkül, aztán majd meglátom, hogy kell-e kiegészítés. Már írtam pár egyszerű tesztet, helyi hálózaton (max 10-20 ms latency) semmi késleltetés nem látszik, gondolom neten keresztül lehetne észrevenni a lagolást.

   
Asylum - Törzstag | 5455 hsz       Online status #128771   2010.03.11 17:53 GMT+1 óra  
A lehető legnagyobb hiba amit elkövethetsz, hogy küldözgeted az időket...nincs két ugyanolyan óra a világon.

Én a következőket csinálnám:

karaktermozgás: a kliens ugy mozgatja a saját karakterét mintha egy single player játék lenne, a pozicioját pedig fix idöközönként elküldi a szervernek (nem muszáj minden frameben).
A szerver ezt elküldi a többi kliensnek, azok pedig a régi és az új pozicio között interpolálnak. Ha egy csomag elveszett, nem érdekes.

lövedék: hasonlóan mint fent, a kliens elküldi a lövedék pozicioját, a szerver az aktuális állapotok alapján megnézi, hogy eltalált-e valakit, de közben a kliens is nézi, hogy például nem ütközött-e falba a lövedék.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Matzi - Szerkesztő | 2521 hsz       Online status #128764   2010.03.11 15:58 GMT+1 óra  
Idézet
ne várja meg a kliens->szerver->kliens kommunikációt

Ha te nyomod le a gombot, az nem járja meg ezt az utat, elmozdulsz és kész. Ilyenkor a szerver jobban bízik a kliensben, hogy a saját pozícióját hogy kezeli (ezért lehet csalni), az meg hogy am ásik ember hogy nyomja a gombot, és te hogy látod, az más kérdés.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Pretender - Törzstag | 2498 hsz       Online status #128762   2010.03.11 15:35 GMT+1 óra  
"[...] és amíg nem jön újabb csomag, a régi alapján számol. A legtöbb esetben ez bőven elég. [...]"
Mostanaban tolom a cs-t neten, es abban bizony igy van megcsinalva
Eleg lassunak kell lennie ahhoz, hogy egy csomagot, ami tartalmazza, h milyen gombot nyomtal le, (v. esetleg a klines oldalon kiszamolod a velocity-t, es azt kuldod el) elkuld, majd fogadd a szamitott mozgast (avagy collision test eredmenyt) nem lehet tul sok ido. Ha valaki laggol (magas ping ugyebar), akkor bizony elofordul, hogy kesobb indul el, mint szeretne.

   
gaborlabor - Moderátor | 4449 hsz       Online status #128761   2010.03.11 15:09 GMT+1 óra  
Idézet
Matzi :
IGazából teljesen mindegy, hogy amit megkaptál, az mennyire régi állapot, az más problémákat vetne föl, így csak simán késik minden, de amíg ez alacsony, nem lesz zavaró.


Szerintem nem mindegy, hogy mennyire régi állapot. Ha azt akarod, hogy a gomb lenyomásakor rögtön reagáljon a karaktered, ne várja meg a kliens->szerver->kliens kommunikációt (ami internet esetén "sok" idő is lehet), akkor mindenképp számolnod kell kliens oldalon is. Majd pedig a szervertől kapott adatokkal folyamatosan felülírod a helyben számolt dolgokat. De ha túlságosan ritkán kapsz adatokat, magyarul nagyon lassan érkeznek az adatok, akkor már látható különbség lesz a helyben számolt adatok és a szerver adatai között

Amúgy lövedékekből meg lesz többféle is, néhányuk meglehetősen lassan mozog (lövedékhez képest), pl rakéta. Ezért úgy döntöttem, hogy kód szinten egységesen kezelem a lövedékeket, rendesen sebességvektorral mozgatva, animálva stb. Az már más kérdés, hogy bizonyos típusú lövedékek 1-2 frame után ütköznek valamivel, ezért megsemmisülnek.

Egyébként, ebben a cikkben egész korrekten leírják a dolgokat:
http://gafferongames.com/game-physics/networked-physics/

Én is itt olvastam azokról a technikákról, amiket lentebb már említettem - épp csak a timestamping részét nem tudom implementálni.

   
Matzi - Szerkesztő | 2521 hsz       Online status #128760   2010.03.11 14:52 GMT+1 óra  
Egy átlagos lövedék mondjuk 1 frame erejéig él. Erre nem érdemes mozgást számolni, a szerver megnézi kit talál el, és elküldi mindenkinek, hogy innen ide ment (ha ki akarod rajzolni egy pillanatra), XY meghalt tőle. Túl gyors objektumoknál úgysem látod.

A sorrendiség megoldható, monoton sorszámozod, ha kapsz egy kisebb számút, akkor eldobod.
A karaktermozgást tipikusan úgy oldják meg, hogy elküldik a karakter pozíciót, és a mozgását leíró legfőbb jellemzőket (irány, sebesség, stb), és amíg nem jön újabb csomag, a régi alapján számol. A legtöbb esetben ez bőven elég.

IGazából teljesen mindegy, hogy amit megkaptál, az mennyire régi állapot, az más problémákat vetne föl, így csak simán késik minden, de amíg ez alacsony, nem lesz zavaró.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Pretender - Törzstag | 2498 hsz       Online status #128759   2010.03.11 14:49 GMT+1 óra  
En nem nagyon ertek (meg) a halozatokhoz, de amit osszeolvastam + kitalaltam, a lovedeket nem lehet ugy megoldani, hogy:
- elkuldod az input infot a szervernek (ugyertem h pl. tuzelt-e), meg a kello dolgokat nyilvan, hogy mennyit sebez az adott fegyoval, stb.
- a szerver szepen letrehozza a golyokat, illetve a letezoket mozgatja es nezi ra a ray-akarmi utkozest. ha utkozik valakivel megallapitja, hogy meghalt-e, ha igen, akkor csak azt az infot kuldi vissza a kliensnek, hogy megserult/talalt/nemtalalt/meghalt/stb.
?
(bar ez inkabb server-client eseten mukodik | kicsit nehezkesen fogalmazok most |)

ha pedig a mozgas: az is inputkuldes, szerver mozgat. Ha nagy a pingje a tagnak, akkor erdekesen mozog, de ez meg a nagy jatekoknal is igy van

   
gaborlabor - Moderátor | 4449 hsz       Online status #128757   2010.03.11 14:45 GMT+1 óra  
Idézet
Matzi :
Lövedék koordinátát ne küldjél senkinek. Az csak egy sugár, nem egy objektum.


Most ezt nem egészen értem... Szerver oldalon számolódik a mozgatás, az ütközésvizsgálat.
Akkor csak annyit csináljak, hogy amikor egy lövedék létrejön, akkor a pozícióját meg sebességvektorát elküldöm az összes kliensnek, és azok csak mozgatják + renderelik, de nem korrigálják a dolgokat a szerver számításai alapján?

Viszont timestamp a karakter mozgatása miatt is kell. Az is a szerveren számolódik, de hogy ne legyen nagy késleltetés, kliens oldalon is számolódik, és a szervertől érkező adatokkal felülíródik. Viszont ha nem tudom, hogy a szervertől kapott adatok mennyi idővel ezelőtti állapotot írják le (vagyis hogy mennyi idő alatt érkezett meg a csomag a szervertől), akkor nem tudom újraszámolni a dolgokat, csak felülírni a kliens oldalon kiszámolt adatokat. Ettől ugrálna és szaggatott lenne a karakter mozgása, ha relatíve sok idő telik el a csomag megérkezéséig. Arról nem is beszélve, hogy az UDP miatt az is lehet, hogy rossz sorrendben érkeznek meg a csomagok.

Idézet
Matzi :
Tipikusan az ilyen időzítés problémák csak szigorúan realtime rendszerekben oldható meg, de ott is vért izzadnak vele. Nem véletlenül. Ahol csak lehet, kerüld ki.


Na igen, de a magasabb szintű hálózati librarykben (pl raknet, zoidcom) is van timestamping, valahogy biztosan megoldható.
Meg nagyon úgy néz ki, hogy a NTP (network time protocol) többek között erre is jó, csak éppen fogalmam nincs, hogy azt hogy s mint lehet használni.

   
Matzi - Szerkesztő | 2521 hsz       Online status #128756   2010.03.11 14:33 GMT+1 óra  
Lövedék koordinátát ne küldjél senkinek. Az csak egy sugár, nem egy objektum.

Tipikusan az ilyen időzítés problémák csak szigorúan realtime rendszerekben oldható meg, de ott is vért izzadnak vele. Nem véletlenül. Ahol csak lehet, kerüld ki.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
gaborlabor - Moderátor | 4449 hsz       Online status #128754   2010.03.11 14:06 GMT+1 óra  
Germo: igen, valami ilyesmire gondoltam én is, hogy valamiféle pingpongozást az elején lejátszanak (kb mint pingelésnél), aztán akkor lehet átlagsebességet mérni.
De szerintem ez nem valami jó megoldás, többek között az UDP (elméleti) megbízhatatlansága miatt sem, meg amúgy is, jó lenne minden érkező csomagról tudni, hogy az mikori. Tehát pl ha egy lövedék pozícióját küldöm el, akkor nagyon nem mindegy, hogy az 10 ms-mal ezelőtti állapotot jelenti, vagy a 100 ms-mal ezelőttit, a nagy sebesség miatt.
Kliens -> szerver oldalú kommunikációnál még azt mondom, hogy csak-csak elhanyagolható a latency, mivel csak az input állapotát küldöm el (UDP fejléccel együtt 12 bájt)...
De a korrekt timestamp-es megoldás több szempontból is nagyon hasznos, pl. csomagok sorba rendezése / régi csomagok eldobása stb.

Az a baj, hogy még egy normális, gyakorlatias cikket, leírást sem találok a neten.

   
Germo - Tag | 40 hsz       Online status #128752   2010.03.11 13:18 GMT+1 óra  
Én most fogok hasonló dologgal szembesülni - igaz javaban. Talán érdemes egy idő egyeztető class-t készíteni, ami időről időre méri, hogy mennyi a user válaszideje.

Elküldöd a szerveridőt, visszakapod, a játékos gépidejét.
A játékos relatív ideje pedig:

userTimeOnSzerver = visszaErkezettSzerverTime - elkuldottSzerverTime / 2 + elkuldottSzerverTime

És a userTimeOnSzerver - jatekosGepideje lesz az időeltérés viszonyszáma.

Ha azt feltételezem, hogy az üzenet ugyanannyi ideig megy, mint jön.

Időről időre le lehet ellenőrizni az időeltérést, hogy a program alkalmazkodjon a hálózat váltakozó sebességéhez.
A végtelenbe és tovább!
   
proof88 - Törzstag | 530 hsz       Online status #128751   2010.03.11 12:58 GMT+1 óra  
szörnyű ez az időhöz igazítósdi ... múltkoriban nézegettem az rFactor force feedback cfg fájlját, és olyat is láttam benne, hogy valahogy előre kell tudni, milyen erőhatásokat kell szimulálni a kormányon, mert bizonyos modellek esetén kis késedelemmel jelenik ez meg a kormányon.
   
Seeting - Törzstag | 2306 hsz       Online status #128749   2010.03.11 12:44 GMT+1 óra  
A szervergép játékidejét vedd alapul. Mikor egy kliens csatlakozik a játékhoz, kérje le az időt a szervertől. Hmm, bár ez is bizonytalan mert ki tudja mennyi idő telik el amíg ez megérkezik...
   
Wolfee - Törzstag | 1336 hsz       Online status #128748   2010.03.11 12:44 GMT+1 óra  
a servergépen a játék indulásától eltelt időt is belefűzném a csomagba
FZoli jóváhagyásával XD

   
gaborlabor - Moderátor | 4449 hsz       Online status #128747   2010.03.11 12:36 GMT+1 óra  
Wolfee, az nem jó, mert az csak az adott gépen eltelt időt mutatja meg, ami gépenként különbözik. A rendszeridő is különbözhet gépenként, tehát azt sem lehet használni. Valami közös, egyeztetett alapnak lennie kell mindenképp.

   
Wolfee - Törzstag | 1336 hsz       Online status #128746   2010.03.11 12:30 GMT+1 óra  
hááát... én a játékindulástól eltelt időt küldeném el a csomag részeként.
FZoli jóváhagyásával XD

   
gaborlabor - Moderátor | 4449 hsz       Online status #128745   2010.03.11 11:23 GMT+1 óra  
Nem egészen ide passzol a kérdés, de mindegy...

Hálózati játékon dolgozom, winsockot használok, UDP-vel. A kérdés az, hogy a timestamp-ek használatát hogyan tudnám megvalósítani.
Végeredményben, amikor megérkezik egy csomag egy klienshez (ami ugye egy múltbeli állapotát írja le a játéknak), tudnom kell, hogy mennyi idő alatt ért oda a csomag, azaz, hogy mennyi idővel ezelőtti adatokat kapott meg. Ez alapján már kliens oldalon is újra lehet futtatni a szimulációt...

Ez elméletben szép és jó, de nem találtam használható példakódot/tutorialt a neten.
Az NTP-t szokták erre használni, vagy mit?

   
Asylum - Törzstag | 5455 hsz       Online status #128694   2010.03.09 21:57 GMT+1 óra  
Egyébként private örökléssel is mennie kéne...
Szóval valamit nagyon elkúrsz.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #128688   2010.03.09 21:04 GMT+1 óra  
Kód:
class Banan : public Alma<T>
? - avagy nem ertem a problemat

szerk.: Aha, amikor irtam, akkor meg nem volt itt az uzid.

   
Joga - Törzstag | 1791 hsz       Online status #128687   2010.03.09 21:04 GMT+1 óra  
jó, ez azért van, emrt az előző példát írtam át, az eredeti kódban public öröklődés van már, és mégis kell hatókör neki
(ಠ ›ಠ) Stewie!

   
Wolfee - Törzstag | 1336 hsz       Online status #128682   2010.03.09 20:53 GMT+1 óra  
mert még mindig private-ként örökölsz
FZoli jóváhagyásával XD

   
Joga - Törzstag | 1791 hsz       Online status #128674   2010.03.09 18:39 GMT+1 óra  
nah szuper, így már megy neki, csak nem tudom, hogy hatókör operátor nélkül miért nem veszi észre az öröklött tagot

Kód:
namespace Pista{

template<typename T>
class Banán : Alma<T>{

// Elvileg csak öröklött tagok vannak

public:
void set( T x, T y ){
Alma<T>::a = x; Alma<T>::b = y;
}

};

}
(ಠ ›ಠ) Stewie!

   
Joga - Törzstag | 1791 hsz       Online status #128653   2010.03.09 05:52 GMT+1 óra  
Na igen, utána olvastam, és így jobban belegondolva public öröklődést kell alkalmaznom.
A headert pedig beinclude-oltam, anélkül a fordító már a származtatásnál sem ismerné fel az almát


Ennek ellenére valami hülyeség van még a kódomban( az sem kizárt, hogy az egyszerűsítés következtében kikerült belőle a hiba )
(ಠ ›ಠ) Stewie!

   
Asylum - Törzstag | 5455 hsz       Online status #128651   2010.03.08 23:55 GMT+1 óra  
Alma.h be van inkludolva?
A private öröklés szándékos?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Joga - Törzstag | 1791 hsz       Online status #128650   2010.03.08 22:40 GMT+1 óra  
Na szóval lenne valami ilyesmi szerkezetem:


egyik fájl:

Kód:
namespace Pista{

template<typename T>
class Alma{

protected:
T a, b;

};


}


másik fájl:

Kód:
namespace Pista{

template<typename T>
class Banán : Alma<T>{

// Elvileg csak öröklött tagok vannak

public:
void set( T x, T y ){
a = x; b = y;
}

};

}



Ezt viszont a fordító egyszerűen nem tudja értelmezni, mert nem találja az a és b tagot
most akkor:
1.) Hülye vagyok és rosszul értelmeztem az öröklődést
2.) Valami olyat csináltam, ami nem szokás, és ezért nem ismeri fel a fordító
3.) Mivel ez csak egy egyszerűsített példa, ezért lehet, hogy a bonyolultabban van valami
kis rejtett hiba


Szerintetek?
(ಠ ›ಠ) Stewie!

   
Pretender - Törzstag | 2498 hsz       Online status #128644   2010.03.08 20:13 GMT+1 óra  
hat vegulis gondoltam hogy ez nem fog levenni a teljesitmenybol tizen fps-eket
nyilvan if (currKeyState & 0x80 ) lesz (ha erre gondoltal)
//en minden frameben lekerdezem. Tancsak nem lesz tole 183-mal kevesebb fps-em

   
Asylum - Törzstag | 5455 hsz       Online status #128643   2010.03.08 20:12 GMT+1 óra  
255-re még nem lassu, csak ne fvhivás legyen hanem tömbindexelés ahogy már irtam (és konstans idejü). Az inputot amugy se szokás minden frameben lekérdezni.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
proof88 - Törzstag | 530 hsz       Online status #128642   2010.03.08 20:11 GMT+1 óra  
inputbeállításnál csak egy gomb, de most nehogy ezen gondolkodj, hogy itt hogy gyorsabb .... feltételezem a játék rajzolni fog a képernyőre, ne itt optimalizálj
   
Pretender - Törzstag | 2498 hsz       Online status #128641   2010.03.08 19:49 GMT+1 óra  
viszont csak azt a billentyut kell eltarolnom, amelyik akciohoz van rendelve. Tehat ha a "T" betut nem hasznalom, akkor nem is kell vizsgalnom. Ha tevednek, akkor kicserelem.

ja es koszi az 5letet

szerk.:
Ja es hogy erdemes lekerdezni, hogy melyik indexu gombot nyomtam le?
Kód:
for (int i = 0; i < 255; i++)
{
    if (KeyIsPress(i))
        lenyomottgombindex = i;
}

nyilvan 1xre az inputbeallitasnal csak egy gombot fogadunk el, szoval ha igaz a feltetel, akkor kilepunk a ciklusbol. Ez mondjuk nagyon szep es jo, de elkepzelheto, hogy lassu 255x megvizsgalni, h lenyomtam-e egy gombot (bar, ahogy Asy mar tobbszor irta, a WINAPI a hatterben hasonlo dolgot muvelhet)

Ezt a hozzászólást Pretender módosította (2010.03.08 19:58 GMT+1 óra, ---)

   
Asylum - Törzstag | 5455 hsz       Online status #128639   2010.03.08 19:34 GMT+1 óra  
És ez biztos, hogy jó lesz igy? Mármint hogy megcserélted a kulcsot meg az értéket?
Valoszinüleg akcióból kevesebb van mint billentyüböl.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #128638   2010.03.08 19:19 GMT+1 óra  
Hm. Most nezem, hogy nem is kell ragaszkodni a DWORD-hoz. Azt figyeltem, hogy:
Kód:
inline bool KeyIsPress(const int& key) throw()
{
    if (currKeyState[key] & 0x80)
        return true;

    return false;
}

Mivel ugyis menubol lehet majd allitani az opciokat, siman le tudom kerdezni, hogy a 256-os elemszamu billentyukbol hanyadikat nyomtuk le. A config fajlba elmentem ezt, tehat ugy nezne ki, hogy pl.:
Kód:
47 Forward

es akkor a beolvasasnal:
Kód:
std::map<int, std::string> keymappings;
//nyilvan foreach keys, vagy ilyesmi
int key ;
std::string action;

//key, action beolvas

keymappings.push_back(key, action);

vagy akar ugy, hogy van egy std::vector<std::string> commands-om. es akkor beolvasasnal 2 int-et behuzok. Az elso a billentyu indexe, a masodik a commands indexe (hiszen a parancsok egy jatekon belul ugyis elore definialtak)
pl.:
Kód:
command Backward
command Forward

key 10 1  //a 10. indexu billentyuzethez a forward command tartozik

es akkor pl.:
Kód:
//csak annyi, hogy ismerni kell a command index-et
if (keydown(keymapping[1]))
    //move forward

   
Asylum - Törzstag | 5455 hsz       Online status #128637   2010.03.08 19:02 GMT+1 óra  
A DIK_W az egy makró...nem biztos, hogy pont a 'w' karakter, vigyázz.
Esetleg ez megoldható:

Kód:
DWORD bill[256] =
{
    DIK_VALAMI,
    // ...
    DIK_W,  // nyilván a 'w' indexü helyen
    // ...
};


Persze ez csak ascii-kat fogad el, ha például az 'í' betűt is akarod akkor elöszöris wifstream, és locale beállitás (és nemtudom, hogy dinput tud-e unicode-ot).

Kód:
std::map<std::string, DWORD> keymappings;

keymappings["forward"] = DIK_W;  // mondjuk a default
// ...


// beolvasás
std::ifstream if("config.txt");
std::string key, action;

if >> key >> action;

keymappings[action] = bill[key[0]];


A gyorsabb keresés érdekében még akár lehet egy közbülsö dolog is, és nem string lesz a keymappings kulcsa, hanem mondjuk egy integer:

Kód:
enum Actions
{
    // ...
    Forward = 6,
    // ...
};
std::map<std::string, int> kozbulso;

kozbulso["forward"] = Forward;

// ...

std::map<int, DWORD> keymappings;
// és igy keresésnél nem stringeket kell összehasonlitani

void bill_lenyomva()
{
    if( billentyük[keymappings[Forward]] & 0x80 )
        // menj elöre
}
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #128635   2010.03.08 18:29 GMT+1 óra  
Hogy lenne a legcelszerubb megoldani az input beolvasasat config fajlbol? Ahogy neztem Dinput DWORD-ot eszik billentyuvizsgalatra. Talan valahogy ugy kellene, hogy pl. van egy ilyen sorom a config fajlban:
Kód:
W Forward //esetleg DIK_W (?)

- beolvasom, es valahogyan az elso karaktert DWORD-e kellene castolni (?)
- betoltom oket egy-egy dinamikus listaba, emellett krealok mondjuk egy commands listat is
minden egyes update-ben:
- torlom a commands listat
- vegigmegyek a billentyukon (amiket beolvastunk, tehat amiket lehet hasznalni ingame), megnezem le van-e nyomva, ha igen akkor commands.push_back(a gombhoz tartozo command [jelen esetben Forward])
- a jatekosnal pedig megnezem, hogy a "Forward" command benne van-e a listaban, ha igen, akkor megyunk elore...

(a masik gondolatom hasonlo. az annyiban kulonbozik, hogy a config fajlban van egy elore leirt commands list [tehat jatekbeli parancsok] es a billentyuk id alapjan hivatkoznanak a parancsokra. Xnaban igy csinaltam meg)

Eleg kesze-kusza megoldas, de eppen ezert mielott nekialltam volna, megkerdezlek titeket, hogy valami otlet? Hogy szoktak/erdemes csinalni?

   
gaborlabor - Moderátor | 4449 hsz       Online status #128571   2010.03.07 13:31 GMT+1 óra  
Doxygen kirajzolja az include dependency-t is, grafikus formában.

   
Pretender - Törzstag | 2498 hsz       Online status #128558   2010.03.07 10:58 GMT+1 óra  
#pramga once az van termeszetesen. Jo, akkor folosleges azzal torodnom, hogy ne includeoljak valamit 100x

   
Joga - Törzstag | 1791 hsz       Online status #128557   2010.03.07 10:38 GMT+1 óra  
hát, ha van valami, amivel kivéded a többszörös include-olást( #ifndef - #define - #endif, vagy #pragma once ), akkor nem gondolom, hogy annyira belassulna tőle a fordítás.
(ಠ ›ಠ) Stewie!

   
Pretender - Törzstag | 2498 hsz       Online status #128553   2010.03.07 07:41 GMT+1 óra  
Gondolj csak bele. Tobb headerben hasznalhatod az engine-ed namespace-et, megse lesz semmi baj (hal'istennek)
Mellesleg include halozatot azt igy manualisan szoktak figyelni, vagy van valami program, ami esetleg kirajzolja grafikusan? (bar gondolom az sem baj, ha pl. A osztalyba a B tobbszor be van includeolva - nyilvan a B.h egyszer, de mondjuk a C.h-t is includeolom, amiben mar includeoltam a B.h-t, na szoval igy )
Kód:
//B.h
class B
{
};

//C.h
#include "B.h"
class C
{
};

//A.h
#include "B.h"
#include "C.h"
class A
{
};

Nyilvan forditasi hibat nem kapok, viszont lassit (??) a forditasi idon.

   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [45] [50] > 55 < [60] [65] [70] [75] [80] [85] [90] [95] [100] [105] [110] [115] [120] [125] [130] [135] [140] [141]