Hy
Szerintetek ha csinálok xna-ba egy 3D-s játékot akkor a menüjét xna-val, winform-al vagy wpf-el célszerû csinálni?..., vagy tök mind1...?

Idézet

---

bit.0x8000 :
Szerintem nem kell Unload, mivel a ContentManager-re való hivatkozás érvénytelenné válik, és ez rekurzívan érvényes az általa hivatkozott dolgokra is. A képbõl is csak azért nem lesz garbage, mert van rá másik hivatkozás is.

---

Ha jól értettem így gondoltad. Valóban mûködik is, azonban mindig egy kicsivel több-és-több kell neki.

Idézet

---

M4 :
Te most mobilra fejlesztesz? Vagy lehet, hogy csak nekem vicces, hogy kilobájtokkal bajlódsz, mikor egy kép is több megabájt.

---

Mintha magának akarná bizonygatni, hogy néhány kb miatt érdemtelen ezzel foglalkozni. Egyébként meg azért dícsérik a .NET-et, mert semelyik másik hivatalos rendszerrel és IDE párossal nem lehet olyan hatékonyan webes, vagy desktop programot fejlesztni, mint a VC#-al és a .NET-el. Ehhez az XNA-n kívül nincs semmilyen hivatalos API, vagy bármi, ezért nehézkesebb vele pont a játékfejlesztéssel foglalkozni. Viszont kombinálni lehet. Az alacsonyszintû részek íródhatnak C++ ban saját igényekhez igazodva és erre a játék logika, script rendszer és editor már managed környezetben CLR-el csatolható.

Te most mobilra fejlesztesz? Vagy lehet, hogy csak nekem vicces, hogy kilobájtokkal bajlódsz, mikor egy kép is több megabájt.

Yes sir, csak érdekelt, hogy miért dícsérik annyira - de ezt ne itt, figyelmeztetve lettünk nemrégiben..

Szerintem olvasd át a lentebb említett cikket a garbage collectorról. Sõt, inkább azt mondom, hogy mivel a felfogásod alapján teljesen c++ irányultságú vagy, ne a c#-pal foglalkozz.

Idézet

---

screat :
és úgy nem lehet, hogy lokális content manager létrehoz, betölt, pálya kilépésekor pedig a lokális content managerre egy Unload() (ami töröl midnen resource-t), és aztán null, majd gc.collect()?
(és pontosan u.annyit kaptál vissza, mint betöltés elõtt?)

---

Szerintem nem kell Unload, mivel a ContentManager-re való hivatkozás érvénytelenné válik, és ez rekurzívan érvényes az általa hivatkozott dolgokra is. A képbõl is csak azért nem lesz garbage, mert van rá másik hivatkozás is.

és úgy nem lehet, hogy lokális content manager létrehoz, betölt, pálya kilépésekor pedig a lokális content managerre egy Unload() (ami töröl midnen resource-t), és aztán null, majd gc.collect()?
(és pontosan u.annyit kaptál vissza, mint betöltés elõtt?)

Én úgy csináltam, hogy létrehoztam egy új ContentManager-t lokális változóként, betöltöttem ami kell (egy 40 megás képet), a metódus végén eltûnik a ContentManager-re való hivatkozás, használtam a képet, utána kinulláztam, aztán GC.Collect: és a windows memóriafigyelõje szerint 40 megával megnõtt a szabad hely...

Mondjuk ez jogos, lehet, hogy csak egy kis memory leak, és 1gb-nyi adatnál is csak 4k lesz

Javaslom próbáld ki nagy méretekkel a programot, nem baj, ha dummy adatok vannak benne. Kis méreteknél könnyen csalóka lehet, hogy néhány kb-ot bent tart a memóriában, valami oknál fogva, attól még nem biztos, hogy 300 mb mellett még egy 100at bent tart.
Próbáld ki, hogy betöltesz rengeteg adatot, és ha akkor is ezt produkálja, akkor kezdj aggódni.

Érdekes. 21k volt induláskor, pálya betölt, 28, dispose-s null-os dolog + gc.collect után vissza 21, viszont újra betölteni nem tudtam, mert disposeoltam (milyen hülyeség már ez? )
ha pedig nem volt dispose, akkor 24-25-re ment csak le a memóriahasználat. Oké, nem tûnik soknak ez a 3-4k, viszont ha nem 1 modellt és 2 textúrát töltök be, akkor kicsit több lesz a különbség. (ami egy új pálya betöltésekor kicsit bajos.. hirtelen 512mb helyett 768 kell a játéknak, v. mi? )

Bizony azzal, szó nélkül el kéne hinned amit a c# -ról mesélnek.

Idézet

---

screat :
- használod a beépített model, textúra, effekt, stb.. osztályokat, amiket kb. nem is tudsz üríteni a memóriából (csak ha kilépsz a játékból )

---

Amikor én próbálgattam, akkor nekem sikerült. Valószínûleg a hozzáállásommal van baj.

A gc.Collect() felépíti az elérhetõségi gráfot, és kigyomlálja amiket nem tud elérni a program. Akkor és ott. Lentebb linkeltem cikkeket.

Szerintem agc.Collect() nem csinál semmit, ugyanugy igaz, hogy "fel fog szabadulni", de hogy mikor azt ö dönti el.

bit.0x8000 -be beleköltözött egy hippy. (nem fogom ám sokszor leírni a nevedet )

Amúgy jó is az xna 3d-re mindaddig, amíg minden pályán kb. ugyan azokat a contenteket használod, ugyanis 2 lehetõség van:
- használod a beépített model, textúra, effekt, stb.. osztályokat, amiket kb. nem is tudsz üríteni a memóriából (csak ha kilépsz a játékból )
- írsz saját osztályokat, de akkor meg már inkább egy natív nyelvben, ami bizonyítottan gyorsabb számításigényes feladatoknál. (ami pl. egy komolyabb játékban ott van) - (jó, tudom, az xna egy framework, és nem egy nyelv, alapból hülyeség az összehasonlítás, de értitek... )

Avagy, ha valaki nagyon ügyes esetleg csinálhat olyat, hogy a beépített osztályokat használja, de saját content managerrel, amivel tud kicsit ürítgetni (de ehhez valószínûleg szüksége lesz unsafe kódolásra, vagy nem tudom)

Valaki megcsinálta már úgy, hogy pálya végeztével u.annyi memóriahasználat volt, mint pálya indítása elõtt? Érdekelne a módszer, ugyanis én azt hallottam (bár ez inkább c#-ra igaz), hogy a gc.collect() csak azokat takarítja ki, amik dispose-olva vannak, és null-ok. (amit nemrég bizonyítottam, hogy nem járható út )

Amúgy ha már itt tartunk bit.....: peace

Amúgy az XNA-ás játékokra szerintem hatványozottan igaz, hogy a kevesebb néha több...
Így hírtelen az Echocrome ugrik be, ami nem XNA-ás, de szerintem sok tanulságot le lehet szûrni abból a játékból....

És mivel ma még nem írtam: Peace

Azzal is

Idézet

---

sirpalee :
De a többi makerhez képest, pont azzal van reklámozva, hogy tud rendesen 3d-t .

---

Én azt hittem azzal, hogy lehet vele Dobozra fejleszteni...

De a többi makerhez képest, pont azzal van reklámozva, hogy tud rendesen 3d-t .

Mindegy, nem lesz baja belõle, ha pontosabb idõzítõt használ.

Idézet

---

sirpalee :
Ha már xna akkor 3d

---

Amúgy szerintem XNA-ban eddig inkább 2D fronton születtek jó cuccok (?)

Természetesen XNA általábanról beszéltem

Idézet

---

sirpalee :
Amúgy természetesen általában általában, ha már általában beszélünk akkor az általános problémákat általánosítva oldjuk meg. Szerintem.

---

Ööö... De ez az XNA topik...

2D platformert inkább flashben

Ha már xna akkor 3d

Amúgy természetesen általában általában, ha már általában beszélünk akkor az általános problémákat általánosítva oldjuk meg. Szerintem.

Ok, de az XNA-beli "általában", vagy az általános "általában"?

Idézet

---

bit.0x8000 :

Idézet

---

sirpalee :
egy ezredes bontás nem elég általában

---

Egy 2d platformerhez (meg hasonló játékokhoz)?

---

Idézet

---

sirpalee :
egy ezredes bontás nem elég általában

---

Egy 2d platformerhez (meg hasonló játékokhoz)?

Szerintem meg csak összezavartátok szegényt.

Nyilván, de inkább mondtuk screattal, és késõbb nem lesz baja belõle.

Sima timerrel És csak fps-t kérdezett, nyilván a game logicnál énis high precision timert használok (csak én ugye c++ ban és nem ebben a virágszálban).

Nah és hogyan méred pontosan, hogy eltelt egy másodperc?

No meg gameplay cuccokat nem köthetsz framehez... Szükséges egy pontos timer az esetek nagy részében.

nem kell ide pontos timer...minden frameban növelsz egy számlálót, másodpercenként meg kiirod és reseteled.

Igen, érdemesebb amúgy a pontosabbat megcsinálni (nem valami bonyolult), tick pedig valóban kerülendõ. Anno azt hiszem ebbõl indultam ki: http://www.codeproject.com/KB/cs/highperformancetimercshar.aspx

Nah megelõztek . Annyi pontosítás, hogy a tickcount kerülendõ, vannak letölthetõ timerek c# alá, amik sokkal pontosabbak. (egy ezredes bontás nem elég általában)

írsz egy fps countert,és sprite fonttal kiíratod (vagy az ablak címe mellé)...

http://www.google.hu/search?hl=hu&source=hp&q=fps+counter+c%23&btnG=Google+keres%C3%A9s&meta=&cts=1256499215984&aq=f&oq=
elsõ találat:
http://social.msdn.microsoft.com/forums/en-US/gametechnologiesdirectx101/thread/4ec9a2c0-236f-400c-8eab-75a91040ab0c/

hy
Segítség kellene. A képfrissítést -(FPS)- akarom kiíratni de nem tudom hogyan álljak neki vagy hogy milyen osztály(ok)ba kell matatni ez miatt.

Az a baj, hogy nem vagyok még otthon, és nem tudom neked prezentálni 1-2 screenshottal, hogy miért nem fölösleges az egeres küldetés.

Az elsõt meg totál nem értem. Mit akarok én vágni??? Max jópofát.

Sztem halasszuk el a problémát, mert úgy érzem nem sikerült jól átadnom, hogy az elemek hogyan néznek ki.

Idézet

---

kuzanth :
Nem akarok két képet összeolvasztani, vagy nem értem mire célzol.

---

Akkor viszont mi lenne, ha a menüelemek szélességét (meg egyéb igazítás információkat) olvasnád be kívülrõl, és a képméretnek nem kéne egyformának lennie.

Idézet

---

kuzanth :
Az egér pedig jelenleg még nem változik, egyelõre nem volt rá igény. Amúgy nem tudom ez hogy jön ide? Attól, hogy megváltoztatom a kurzort, a user még nem fogja tudni, hogy az alatta lévõ 'üres' terület már a menüelemhez tartozik.

---

Ha elég közel van hozzá, akkor tudni fogja (szerintem).

Nem akarok két képet összeolvasztani, vagy nem értem mire célzol.
Az egér pedig jelenleg még nem változik, egyelõre nem volt rá igény. Amúgy nem tudom ez hogy jön ide? Attól, hogy megváltoztatom a kurzort, a user még nem fogja tudni, hogy az alatta lévõ 'üres' terület már a menüelemhez tartozik. Vagy ezt a részt sem értem.
De a beolvasás abból a szempontból jó, hogy akkor definiálom, hogy mekkora a szöveg területe, kiegészítem a menüelem classt egy rectangle-lel, és azt vizsgálom, nem a textúra méretét.

Idézet

---

kuzanth :
Ez mûködõ megoldás lehet, csak mindenre beolvasó filet csinálni...

---

Általános esetben az a baj, hogy amikor a kódon kívül "olvasztasz össze" két képet, akkor információ veszik el, tehát ezt nem nagyon lehet megkerülni.

Amúgy az egérkurzor nem változik, amikor aktív terület fölé ér?

Már válaszoltam ezekre a felvetésekre, de akkor még1x. A FF-hez hasonlóan akarom az oldalra nyíló menüt, ehhez az kell, hogy minden image ugyanakkora legyen, tehát a vágás nem megoldás.
Igazából lehet, hogy a designt kellene újragondolni, és valahogy úgy megtervezni a menüelemeket, hogy mégis körbe legyenek rajzolva...

Tehát azt akarod, hogy ha különbözö szélességü menüelemek esetén közelebb vagy távolabb jelenjen meg a lenyilo menü?
Aszondod a szöveg texturákban van, mértnem vágod szét a texturákat a megfelel méretre. Vagy a mûsik, hogy a menüt xml-böl épited fel ahol meg tudod adni a szélességét is (amit aztán a felbontáshoz adaptál).

Nana, a firefox menüelemeinél, ha ráviszed a kurzort a menüelemre, az 'üres' rész is kékes színre vált, ezzel tájékoztatva a usert, hogy maga a menüelem valójában jóval hosszabb, mint maga a szöveg. Ha megnézed a galactic warfare legutolsó menüképét, láthatod, hogy a szövegek alphablendesek, tehát nincs ilyen tájékoztató színû sáv a valós méretrõl. Továbbá nem csak ez a szín tájékoztat téged ff-ben a méretrõl, hanem eleve a lenyíló menünek van egy bizonyos szélessége, ami ugyanakkora, mint az elemek szélessége. Továbbá nekem elõugró menü kell, ami oldalra nyílik (hasonlóan pl a Tiberian Wars-hoz), nem pedig lenyíló menü.

Szerk.:
Itt látható a tib wars menüje
Ennek csak az a hátránya, hogy minden menüelem körbe van rajzolva, kvázi itt értelmét veszti az, amit én akarok, továbbá a menüelemek két íves izé közt vannak, ami szintén a menü méretérõl és elhelyezkedésérõl informál. Nálam viszont ilyenek nincsenek, és mivel nem koppintani akarjuk ezt a designt (bár tetszik), ezért maradnánk a saját elképzelésünknél.

Hu de agyon van bonyolitva ez. Nem kell messzire menni példához, itt van a firefox, ráklikkelsz a fájlra és megjelenik a menü. Nyilván nem minden szöveg ugyanolyan hosszu mégis ha üres területre kattintasz akkoris kijelölödik. Mi ezzel a probléma?

Ezzel az a gond, hogy a menüelemek nincsenek körberajzolva, hogy a user lássa, hogy mekkora is valójában a menüelem. Ha ráviszi az egeret egy nagyon rövid elemre, és megjelenik az elõugró menü 30 pixellel arréb, sztem rögvest uninstallálja a játékot, amit sztem bõven elég azután megtennie, ha már játszott kb 20 másodpercet.

bit : Ez mûködõ megoldás lehet, csak mindenre beolvasó filet csinálni...

Kicsit gondolkozva, talán a legjobb megoldás a jobbra rendezés lenne ezzel a filebeolvasós mûvelettel, mert akkor az imagek vége a szövegek vége lenne, tehát egybõl nyílhatna mellõlük az elõugró menü. Át kell ezt még rágni, mert sajnos ez egyben design kérdés is.

Mi lenne, ha lenne egy területed, ami a menüponté, és ez lenne fix, mellé rakhatnád a legördülõ menüt. Valamint lenne egy textúraméreted, ami azt jelölné, hogy hol aktiválódik a menüpont.

És ha "kézzel" állítanád az aktív területet? A ps-es kép alapján meghatároznál egy téglalapot, aminek a négy adatát fájlból olvasnád be...

De remélem azért az érthetõ, hogy ezzel mi a gond? Jelenleg én is így csinálom, csak most, hogy a menüelemeket balra rendeztük, így nem valami jó. Ok, középre rendezve is hülyén néz ki, ha már 20 pixellel arrébb aktív a kijelölés, de...hmm...nincs de, hülyén néz ki így is, úgy is.
Ja, mielõtt kérdeznétek, hogy 'de akkor miért nem akkora az image, amekkora a szöveg', arra a válaszom, hogy azért, mert a végsõ verzióban elõugró menüt akarok csinálni, és ha nem ugyanakkora minden image, akkor megeshet, hogy egy rövid szöveg elõugró menüje eltakarja az alatt lévõ hosszú menüelemeket.

szerintem is megõrülne minden júzer, ha pont a nyílra kéne kattintani. Én anno megcsináltam úgy a menüt, hogy ami textúra volt, arra a lentebb írt kódot használtam (vagyis ennél szebben volt leírva, de nem ez a lényeg..). Ha a textúrán belül van az egér, akkor rajtavan, azt csá'

és teljesen jó volt..