|
|
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...?
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
|
|
|
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.
Kód: ContentManager content;
Texture2D t;
void LoadContent()
{
content = new ContentManager(game.Services, game.Content.RootDirectory);
//...
t = content.Load<Texture2D>("lol");
content = null;
}
void UnloadContent()
{
t = null;
GC.Collect();
}
Ha jól értettem így gondoltad. Valóban működik is, azonban mindig egy kicsivel több-és-több kell neki.
még csak padawan...
Dont worry, be hippy - Fanni :)
|
|
|
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ó.
Ne sajnáld a vak embert, aki nem látja e világ látványát, inkább sajnáld magad, mert ő előbb látja meg a megvilágosodás útját.
natív vs managed
|
|
|
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..
még csak padawan...
Dont worry, be hippy - Fanni :)
|
|
|
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.
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???
|
|
|
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?  )
még csak padawan...
Dont worry, be hippy - Fanni :)
|
|
|
É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
még csak padawan...
Dont worry, be hippy - Fanni :)
|
|
|
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.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
|
|
|
É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?  )
még csak padawan...
Dont worry, be hippy - Fanni :)
|
|
|
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.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
|
|
|
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
még csak padawan...
Dont worry, be hippy - Fanni :)
|
|
|
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
raytraceisten és übermedic
|
|
|
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.
raytraceisten és übermedic
|
|
|
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
raytraceisten és übermedic
|
|
|
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.
raytraceisten és übermedic
|
|
|
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)?
raytraceisten és übermedic
|
|
|
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.
raytraceisten és übermedic
|
|
|
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.
raytraceisten és übermedic
|
|
|
nem kell ide pontos timer...minden frameban növelsz egy számlálót, másodpercenként meg kiirod és reseteled.
|
|
|
még csak padawan...
Dont worry, be hippy - Fanni :)
|
|
|
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)
raytraceisten és übermedic
|
|
|
még csak padawan...
Dont worry, be hippy - Fanni :)
|
|
|
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.
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
|
|
|
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.
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???
|
|
|
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).
Ezt a hozzászólást bit.0x8000 módosította (2009.10.21 08:25 GMT+1 óra, ---)
|
|
|
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.
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???
|
|
|
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...
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???
|
|
|
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.
Ezt a hozzászólást kuzanth módosította (2009.10.21 07:40 GMT+1 óra, ---)
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???
|
|
|
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.
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???
|
|
|
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.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
|
|
|
É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.
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???
|
|
|
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..
még csak padawan...
Dont worry, be hippy - Fanni :)
|
|
|
Legújabb project:
Szókirakó 3
Legutóbb frissített project:
Szókirakó 3
Friss kép a galériából:
|