Reklámok
Kezdőlap > Általános cikkek > Performance profiling

Performance profiling

2012. augusztus 17. Hozzászólás Go to comments

Sziasztok. Ritkán szoktam ide postolni, de a grafikai/FPS problémák kapcsán úgy döntöttem, hogy tollat ragadok és egy picit bevezetem az érdeklődő közönséget a performance profiling rejtelmeibe. A cél a következő: Megérteni, hogy miért nem fut elfogadható FPS-en egy játék, miközben közel sem használja ki a rendelkezésre álló erőforrásokat. Szép és jó azt várni, hogy majd az ArenaNet egy szempillantás alatt megoldja a problémát és hirtelen a játék tökéletesen fog futni a kávéfőzőkön is, de valójában az esetek nagy részében itt nem arról van szó, hogy maga a játék/grafikai engine van rosszul programozva, hanem sokkal inkább az, hogy a PC konfigurációk végtelen variálhatóságára nem tud egyetlen fejlesztő cég sem felkészülni. Ez különösen igaz, ha az adott játék valami egyedileg fejlesztett grafikai enginen fut, nem pedig egy széles körben elterjedt és sok-sok játékban használt grafikai alap motoron (pl. cry, unreal, stb.) Ha jól tudom, akkor a GW2 esetén az előbbi eset áll fenn. Nézzük hogyan is tudsz TE tenni azért, hogy a ‘Nincs elég FPS-em’ kikiáltásán túl értékes információkkal tudd segíteni a hibabejelentéseket:

  • Ha egy játék a lehetséges erőforrásoknak csak egy részét használja ki és így nem képes az elvárható szintet nyújtani, az rendszerint annak az eredménye, hogy valamilyen bottleneck van a rendszerben.
  •  Ez a legtöbb esetben az adott software/játék hibás programozásából adódó probléma, de mivel itt a GW2-ről van szó,ezért ezt egyelőre vessük el. Nyilván szorul a játék bizonyos optimalizálásra, de ennek mértéke közel sem azonos azzal a szinttel, amilyen problémák most jelentkeznek a játékosok egy részénél.
  • Ha ezen túl lendültünk, akkor érdemes nekiesni megkeresni a bottlenecket.
  • Ha egy játékprogram úgy generál elvárható alatti FPS-t, hogy közben a GPU nincs 100%-on, az annak köszönhető, hogy a GPU nem kap elég adatot amit megjelenítsem. Ez egyértelműen azt jelenti, hogy CPU-ban gyenge a gép.
  • Ha mindemellett a CPU is csak relatív pihen (overal 50% körül), az azt jelenti, hogy valahol mélyebben van a bottleneck.
  • Ilyenkor a következőt érdemes megnézni: Fogod magad és megnézed, hogy ez az ~50% ez vajon miből fakad. Az első tipp amit érdemes megnézni: A CPU core-k egyenkénti terhelését. A programok (különösen a játékprogramok) úgy érik el azt, hogy a lehető legtöbb CPU magot használni tudjanak, hogy un. multi-threading módban futnak. Ennek az a lényege, hogy a különböző feldolgozó folyamatok külön-külön szálon futnak, amik ennél fogva külön magra kerülnek. Ha egy program lineárisan van programozva, akkor hiába van a gépedben 4 CPU mag, akkor is csak egyetlen magon fog futni. Ennek az az eredménye, hogy az overal CPU terhelésed alig lesz 25%, miközben az az egy CPU mag kvázi szétizzadja magát.
  • Konklúzió 1: Ha a magonkénti CPU terhelésénél azt látod, hogy egy-két mag 100%-on van, miközben a többi magon alig van terhelés az azt jelenti, hogy az adott szoftver nincs megfelelően optimalizálva a több magos CPU-kra. Ilyen pl. a TERA online, aminél bár a grafikai engine multi-core-ra van optimalizálva, de az azt meghajtó alap kód viszont nem.
  • Ilyenkor érdemes megnézni, hogy mi is okozza ezt a bizonyos bottlenecket. Erre érdemes bevetni a sysinternal process explorer alkalmazását. Google-ben keress rá, meglesz gyorsan. Ha letöltötted, akkor mindenféleképpen adminisztrátorként indítsd el (jobb gomb->Run as Administrator) ez fontos lesz a call stack/symbolok betöltése miatt.
  • Elindítod a játékot és elmész arra a helyre ahol nagyon szaggat a játék, majd kiválasztod process explorerből az adott játék PID-jét (én most ezt a TERA-val tudom nektek prezentálni, de esetetekben nyilván a GW2 saját processzét kell megnyitni, majd a Properties panelen egyből nézzetek el a “Threads” fülre. Ezen valami ilyesmit fogtok látni:

Hogyan tudod értelmezni az itt látottakat:

  • Bár látszólag a TERA igen sok szálon fut, de ebből érdemben ami használja is a CPU-t az összesen 5-6 szál. Tehát az összes többi thread csak valamilyen pooling tevékenységet lát el, vagy valamilyen system eventre vár. Ezekkel nem kell törődni.
  • Az az izgalmas, amik használják is a CPU-t, hiszen ezek között rejtőzik az, ami a CPU bottlenecket okozza.
  • Egy directX alapú játéknál az adott alkalmazás threadjei mellett ott futnak a directX threadek is. Ezeket olyan néven látod a listában mint pl: DSOUND.dll, DINPUT.dll, d3d9.dll, stb. Normál esetben ezeknek nem szabad 5-6%-nál többet zabálnia, hiszen ezek pooling threadek. Ha mégis bármelyik ennél jelentősebb mennyiségű CPU-t használ, akkor ott biztos valami gond van. Tipikusan amivel találkoztam: DINPUT.dll zabálta a CPU-t, mert egy béta állapotú egér driver volt a gépre telepítve, amiben volt egy memleak. Ha ilyen gondod van, akkor az adott DLL-hez kapcsolódó drivereket frissítsd, vagy pl. nemes egyszerűséggel válts eszközt (pl. kérd el haverok keyboard/egerét egy tesztre ha a DINPUT van a plafonon), vagy ha a DSOUND zabál sokat, akkor vedd ki a hangkártyát és nézd meg az alaplapi hangkártyával… stb.
  • Miért gond az, ha valamelyik directX komponens zabál sokat, hiszen az overal CPU terhelésem még így sem megy 50% felé. A gond az, hogy a windows alap esetben a threadeket arányosan osztja el a CPU magokon. Ha pl. ugyanarra a magra kerül egy directX komponens, ahol a játék alap feldolgozó threadje is van, akkor a directX konkrétan elzabálja az erőforrást a játéktól… és ez nem jó.
  • Ha ezzel nincs gond. Akkor nézd meg az aktív terhelés mellett a játék saját threadjeit. Egy megfelelően optimalizált játéknál legalább annyi threadnek kéne aktívan futnia (aktív = nem 0-1% CPU-n), amennyi mag van a gépben. Ha ennél kevesebb fut (lásd pl. a fenti screenshoton, ahol jól látható, hogy a 8 magos gépen mindösszesen 2 aktív thread fut. Az annyit jelent, hogy az adott játék egyszerűen nincs megfelelően optimalizálva több magos környezetre. Tehát ebben az esetben tökre lényegtelen hogy a két magos gépedet lecseréled-e négy magosra.

Ilyenkor hogyan tovább?

  • Az, hogy egy játék mondjuk csak 1-2 magot használ lényegében az még nem feltétlenül kell, hogy FPS problémát okozzon.
  • Ha viszont azt látod, hogy az az 1-2 thread a plafonon van (közel 100% CPU-t használ), akkor érdemes az adott threadeken dupla klikkelni. Ilyenkor megkapod az adott thread call stackjét. Ebben döntően már olyan adatok lesznek, amikről fogalmad sem lesz megfelelő tudás hiányában, hogy mire is jó ez, de pl. a 100%-on pörgő threadek call stackjének bemásolása egy bugreportba komoly segítséget nyújthat az ArenaNetnek, hogy megértse miért pörög 100%-on pl. egy feldolgozó thread, aminek egyébként 0%-on kéne mennie.

Mi van akkor, ha a CPU-t, mint bottlenecket kizártad, hiszen a CPU magok megfelelően vannak terhelve, mindenhol van megfelelő erőforrás terhelés és mégis szaggat a játék Ez az a pont, ahol még inkább csak példákkal lehet dobálózni. Amikkel eddig én találkoztam:

  • Hűtés probléma: A játék teljesen jól indul, de 1-2-5-10 perc után elkezd szaggatni. Ez tipikusan notebookoknál fordul elő, de az asztali gépek eszközei is rendelkezhetnek thermal protection funkcióval. Ennek a lényege, hogyha az egyes aktív elemek túlmelegszenek, akkor inkább leveszik a saját órajelüket és ezzel ‘hűtik’ magukat, ez a gyakorlatban azt jelenti, hogy leesik az FPS. Ennek a mérésére többféle eszköz is van. Én javaslom a GPU-Z nevű szoftvert. A screenshoton jól látszik, hogy a GPU üzemi hőmérsékleten megy (55 fok), a GPU load alig 54% és a lénye a felső három szenzor érték, mely mutatja, hogy maxon van a GPU, GPU memory és GPU sharedek órajele. Az azt látod, hogy ezek az értékek a játék indítása után lezuhannak, akkor ott hűtési probléma van.
  • Hogyan tudsz pl. egy notebook hűtésén javítani? Ugye vannak az alap megoldások, mint pl. kipucoltatni, rakni alá cooling boardot, stb. Viszont van ezek mellett még egy érdekes megoldás: a notebookokra jellemző (különösen ha gamer notebookról beszélünk), hogy a CPU-n vagy csak valami passzív hűtés van, vagy a CPU/GPU valami közös hűtést kap. Ennek az az alap filozófiája, hogy játék közben úgyis a GPU terheli a több hőt ezért annak úgyis pörög a ventillátora és az kiviszi a CPU hőt is. Namost az MMORPG játékoknál ez sok esetben pont nem a legjobb választás. Ha egy négy magos CPU egyik magja 100%-on fut, annak annak az üzemi hője felmelegíti a többi magot is és összességében a CPU közel olyan meleg lesz, mintha az összes mag zakatolna. Ezért bár látszólag a CPU csak 25-50%-on megy, de kvázi izzik miatta a teljes gép. Emiatt a GPU-ban bekapcsol a thermal protection és szépen jön a szaggatás. Az ilyen problémák kezelésére a legjobb az, ha a CPU alatt visszafogod a ‘lovakat’. Hogy hogyan? Fogod a Power Mangement-et a control panelben és megszerkeszted az aktuális power management plan-t (change plan settings). Azon belül Change Advanced power settings. Azon belül pedig “Processor power management-> Maximum power stat”. Itt normál esetben 100%-ot fogsz találni. Szépen vedd vissza 85%-ra. Ez hülyeségnek hangzik? Lehet, hogy ezzel a 60 FPS-en futó játékból csinálsz 45-50 FPS-t, viszont cserébe 5-10 perc után is megmarad ez az FPS, hiszen a CPU hő nem melegíti túl a GPU-t.

Apropó power plan:

  • Ha már az előző pontban szóba került ez: A legtöbb gépben a Balanced és a High performance között nincs érdemi különbség, azonban az elmúlt években találkoztunk néhány olyan (főleg brand) PC-kkel, ahol mégis volt érdemi különbség a két power plan között és ez a különbség pont annyi volt, ami miatt balanceon még játszhatatlan volt a játék, azonban high-on már kólával elment.
  • Ha már minden más kötél elszakadt, akkor próbáld ki a high performance-t a power managementen belül… Hátha.

Inkompatibilis memória modulok:

  • Ez már ilyen utolsó fűszál,de mivel találkoztam ilyennel is. A probléma detektálása: letöltöd a CPU-Z programot és megnézed az “SPD” fület, ami mutatja a memory modulok információit. A lényeg a következő a memória modulok ugyanazokkal a paraméterekkel kell rendelkeznie és a Serial Number kivételével nem lehet semmi eltérés. Ez különösen igaz a part numberre, annak minden modul esetén ugyanannak kell lennie. Ha nem ugyanaz, az nemfeltétlenül baj, bár különböző gyártók memóriái, esetleg különböző típusú memóriák esetén lehetnek szinkronizálási problémák, amik olyan időzítési gondokhoz vezethetnek, ami akár kihathat a játékélményre is.

‘Röviden ennyi’, ha eszembe jut még valami konkrétum, akkor updatelem a postot. Sok sikert mindenkinek a bottleneck vadászatban. Remélem tudtam segíteni egy-két embernek, akkor már megérte begépelni mindezt.

Reklámok
Kategóriák:Általános cikkek Címke: , ,
  1. 2012. augusztus 17. - 10:10

    Nagyon jó cikk. Köszi. :)

  2. Kovács Péter
    2012. augusztus 17. - 10:21

    Hűűű! Nagyon tetszik amit írtál, egy embernek már biztosan segítettél! Köszi :)

  3. csigusz
    2012. augusztus 17. - 10:30

    Jól összeszedett cikk!
    Annyit fűznék hozzá, hogy windowsos feladatkezelő is megjeleníti a magok terhelését és, hogy memórát illetve cpu -t mennyit használnak a progik. És win7 már dinamikusan kezeli a szálakat, nem fog két erőforrás igényes szálat egy magra ráterhelni, ha van más lehetősége!

    • 2012. augusztus 17. - 10:42

      Ahogy én tudom ennek inkább power management okai vannak, mintsem performancia okai. Azért pakolgatja a core-ok között a threadeket, hogy ha nincs nagy terhelés, akkor egyik másik CPU core át kerülhessen C-statebe, ami kvázi azt jelenti, hogy nincs használva/le van kapcsolva. Ehhez ugye alapfeltétel, hogy az alaplap/proci ezt támogassa és az is, hogy a thread managernek oka legyen hozzányulni a threadek core affinitásához.
      Ráadásul úgy tudom, hogy ennek előfeltétele a NUMA support is a CPU-ban, amit pl. a bodaster által is említett Core 2, Core Quad procik még nem támogattak.

      • csigusz
        2012. augusztus 17. - 10:58

        Elég összetett a dolog, nem csak power menedzsment. Persze az is benne van. Ha egy mag forró a venti is jobban pereg, tokon belül a többi mag is melegszik, akkor inkább beállít a munkába +1 magot, ami igaz kevesebb energiveszteséggel jár.
        Állapotok között a processzor saját magán belül állítgat, és annak amit te írtál csak az új generációs lapkák tesznek eleget, ami nem sok embernek van, és ott sem egész úgy, ahogy terjesztik. Egyrészt, mert pl 3 vagy több magnál van értelme, mert 1 mag mindig “fel van fűtve”, ha gyorsan át kell rá pakolni valamit, akkor az tényleg gyors legyen, a többi álló mag ettől függetlenül pihizhet.
        NUMA támogatás? Az úgy sacc per kb ősidőktől van. Mióta cache van a procikban… NUMA azt írja le, hogy van a procinak egy közvetlen elérésű memória blokkja, ami a cache (L1/L2/L3 stb… gyorsítótár). Ráadásul már elég régóta huzalozott a memória a számítógépekben, és csak egy összekötő híd (AMD-nél még az sem ,mert a menedzsment a prociban van) van a proci és a memóriák között, de persze attól még lasabb mint a cache, akár ECC akár nem.

      • 2012. augusztus 17. - 11:04

        Igazából itt lenne jó látni, hogy hogyan épül fel a GW2 thread szerkezete. De összességében igaz, hogy a Windows 7 bizonyos esetekben sokat segíthet.

      • csigusz
        2012. augusztus 17. - 11:11

        Na igen, most, hogy felhoztad majd rápillantok én is.
        Mekkora öröm lenne kézzel pakolgászni őket! :-DDDD

  4. chuckygwzik
    2012. augusztus 17. - 10:32

    Az biztos, hogy tudtál, kerek cikk köszi!

  5. paprika
    2012. augusztus 17. - 10:38

    Szia! Tök jó amit írtál, akkor lett volna még nagyobb értéke a cikknek szerintem az itteni közösségnek számára hogy ha a módszereddel ránéztél volna a gw2-re is és megpróbáltad volna megnézni egy rendes configgal mennyire optimalizált szerinted a játék. Köszi a cikket!

    • 2012. augusztus 17. - 10:45

      A fentebb leírt praktikákat úgy raktam össze, hogy azokat lényegében bárki végre tudja hajtani, akinek van egy minimális helyismerete a windows erőforrás managementjében. Ha lesz még ilyen stress teszt, akkor zongorázzátok végig ezeket a dolgokat és osszátok meg egymással a tapasztalatokat, hátha kijön belőle valami.

  6. foldes
    2012. augusztus 17. - 10:50

    Kösz, tényleg hasznos olvasmány ! Menorel jössz te is játszani a GW2-vel ? :) Látom követed azért a GW2-t is :)

    • 2012. augusztus 17. - 10:55

      Nincs tervbe véve. A híreket természetesen követem, bár koránt sem olyan szinten, mint a GW2 Variance bloggerek. Az én szívem inkább a koreai játékok felé húz. Kinek a pap, kinek a papné…

      • keksz
        2012. augusztus 17. - 11:58

        Nagyon jó!!

      • SaGaIn
        2012. augusztus 17. - 12:37

        Ha egyszer nem lesz havidíjas a tera vagy mondjuk egy év kijön 15k ból akkor tuti kipróbálom.

  7. Vad Kan
    2012. augusztus 17. - 11:52

    Köszi szépen ezt a cikket, nagyon sok új dolgot tudtam meg és ezek közül jó pár hiba nálam is befigyel. Én notebookon játszom és kb 15-20 perc múlva elkezd szaggatni a játék. Volt amikor nagyon durván szaggatott, de akkor kiderült, hogy vmi meghibásodott a vinyóban és kicserélték, de mostanában megint kezdi azóta visszaküldtem még egyszer, de azt mondták semmi baja, pedig még olyat is csinál, hogy kb 10 percenként 2mp-re befagy az egész gép és közben baromi hülye hangot ad ki. de ez előfordul még youtube videók nézégetése közben is, pedig akkor igazán nicns nagy terhelés alatt a gép. windowst újra húztam meg drivereket is mindd frissítgettem, de nem oldódott meg a probléma. esetleg valami tipp nincsen, hogy mitől fagy be a a gép teljesen 2-3 mpre? amúgy cooling board abban sokat segített, hogy nagy melegben késleltesse,alapból pedig megszűntesse a konstans fps csökkenést.

    • csigusz
      2012. augusztus 17. - 11:58

      Specifikáció nélkül én arra gondolok, hogy valamit tölt éppen. Túlmelegedést ilyennél kizárhatod, mert akkor a gép kikapcsol, esetleg még sípol is.

      • Vad Kan
        2012. augusztus 17. - 13:08

        de amég kifagy még enyhén ilyen”krákogó” hangot is kiad. én inkább hangkártyára gondolok, de azt szervízben csak kiszűrték volna. meg volt már benne egy alaplap csere is, mert alaplaphibásan kaptam a gépet. amúgy egy lenovo y570-ről van szó

      • csigusz
        2012. augusztus 17. - 14:21

        Meg akar enni! :-D Laptopban nem vagyok otthon, így arra sem buzdítnálak, hogy szedd szét magad. Ha garis vidd vissza, és mutasd meg nekik a problémát, mert egyébként ők nem végeznek áthatóbb teszteket. Ha nem garis… Na majd valaki más azt is megmondja, akkor mi van.

  8. Madee
    2012. augusztus 17. - 11:55

    Látom mindenhol feltűnsz néha :D
    Héj tényleg én ide nem tudok postolni ez csalás :P
    ui.: (Egy ilyen cikk Terába is elfért volna a népnek anno :D)

  9. zEEbra
    2012. augusztus 17. - 12:07

    Muszáj néha olyan helyre is postolni ahol “pozitívak” az emberek :D

    • Doby
      2012. augusztus 17. - 14:40

      Hát tessék ennyit a pozitivitásról, a következő hozzáoszlások már csak negatívok :D
      De hát mit várjunk itt magyarok vannak (2/3 cry 1/3 reménykedés):D

  10. SaGaIn
    2012. augusztus 17. - 12:27

    “Ez a legtöbb esetben az adott software/játék hibás programozásából adódó probléma, de mivel itt a GW2-ről van szó,ezért ezt egyelőre vessük el. Nyilván szorul a játék bizonyos optimalizálásra, de ennek mértéke közel sem azonos azzal a szinttel, amilyen problémák most jelentkeznek a játékosok egy részénél.”

    Tök jó hogy mint mionden cikknél egyből a felhasználó gépében keresiteka problémát holott pl azokon a gépken más játék röccenés nélkül fut… éS még te is leírod hogy nem az elterjedt egine-ek egyikét használja… de azért elveted hogy abban lenne a hiba holott pl egy 4 magos prockóval hd6850 en 8gb rammal szaggat néhol 10-15 fpst produkálva… Abban szerintem egyet értünk hogy egy ilyen grafikánál ami sokkal gyengébb mint a mai csúcsjátékok és melleslega a procinak nem kell AI-t meg sebzés dolgokat meg egyéb mász szálolni mert megteszi helyette a szerver nem így kéne menni… Ergó szar a motor hogy van… (ezt mért kéne egyből lesöpörni az asztalról csakazért mert GW2 ? Elfogultságból? ) Meg miylen duma az hogy sok fajta gépen fut… az összes játék ami pcre jelenik meg sokfajata konfigon fut… És persze vanolyan hogy egy engine jobban fut valamelyik gyártó videókártyájával de hoyg mindkét gyártó két legujabb modelljável szaggason ilen mértékben… Az nem pici optimaizálatlanság.

    Amiket leírtál lehetséges hibaokként hogy felhasználó gépében vana hiba ez mind csak felelősség áttolás a userre… “szara géped azért nem fut nem azért mert elcsesztük az enginet… Á mi az anet vagyunki ilyet nem csinálnunk…” Jah kérdem én akkor mások hogy képesek az én gépmre is optimalizálni? Ügyesebbek picit? Vagy nem ragaszkodnak nagyképűen a saját kis motorjukhoz? Vagy ha igen meg tudják csinálni hogy legyen erőforrás zabáló? Nehogy már a bútorhoz tervezzük a házat… Majd szólok az nvidiának hoyg legyenek szivesek külön a gw2 höz egy videókártyát tervezni megy az intelnek hoyg dobjon meg egy 6GHZ pörgő 20 magos xeon procival mert nem futa gw2… Meg hogy szar az egér driver…. jah más játék alatt nem szar mi? na hagyjukmár… amúgy jó a cikk lehet valakinek segít de hogy a többségnek nem az tuti…

    • csigusz
      2012. augusztus 17. - 12:40

      Nyilván a cikk írója valamelyest bele lát a szoftver fejlesztés menetébe/mikéntjébe.
      A hozzászólásaitokból pedig látszik, hogy ti nem.

    • Polarr
      2012. augusztus 17. - 15:05

      Ha ennyire szar a játék engine-je, ahogy mondtad, akkor a tieddel szinte egy szinten lévő géppel ultrán nekem miért fut 40-50fpsel? Hoppá, akkor mégiscsak nálad a baki nemde? Amúgymeg ottvan, hogy egyenlőre vessük el. Azért veti el azt a felvetést, hogy rosszúl lennének megírva a gw2 kódjai, mert ha nem 1 embernek jól fut a játék (ráadásul anet nem csak úgy összedobta a játékot 1 év alatt), akkor ezt szinte ki is zárhatjuk. Valaki csinál egy ilyen postot és te ahelyett, hogy megnéznéd, hogy hátha télleg ez a probléma áll fent nálad is, helyette inkább makacskodol és elkezdessz fújjogni. Nem szeretem az ilyen embereket …

      • csigusz
        2012. augusztus 17. - 15:34

        Szerintem a kizárásba még az si bejátszik, hogy béta. Tudom sokakon nem segít ez a kijelentés, de béta… Valószínűleg játék indulása után 1 héttel kivesznek minden debug kódot, ill. frissítéssel kikapcsolnak, és lesz javulás. (A próféta szóljon belőlem.)

    • 2012. augusztus 18. - 07:09

      Tökéletesen egyet értek az előttem szólóval. Azért azt ne felejtsük már el hogy az átlag mezei felhasználó FIZET ezért a szolgáltatásért és nem is keveset. Az elfogadtatatlan hiba, hogy reaktor erejű PC-ken szaggat a játék, mert nem használja az erőforrásokat, és valami rosszul értelmezett hype-os elfogultság, és felfokozott játékváró hangulat miatt, illendőségből nem mondjuk ki hogy ez igen is tervezési hiba és bas*zák meg, ha van pofájuk ezt így hagyni, és igen is, a játékfejlesztő dolga ezt a hibát kijavítani nem pedig a vásárló dolga feltakarítani az ő sarukat.
      Ne essünk már át a nagy hype-téboly túloldalára és írjunk olyan cikket, hogy ez a kapitális fail miért NEM a fejlesztő hibája, (miért kell őket alapból és “ösztönösen” automatikusan védeni ha tényleg elbaltáztak valamit? Mert “megszentségtelenítjük” a GW2-őt? És azt nem illik, mikor tombol a hype?),” és miért is a mi készülékünkben van a gond. Óriási pofáraesés lesz ha ezt a gondot nem oldják meg. Más a játékról készült videókritikában is láttam már említeni ezt a hibát. (Az otherworld-os srácok a videokritikájukban ugyanezt hozták fel alapvető hibaként.)

      • csigusz
        2012. augusztus 18. - 07:29

        Itt mindig mindenki elfelejtei, hogy BÉTA teszteken alapuló élmenyek vannak. Itt a hibákra mennek rá, és a kliens is úgy van felvértezve, hogy ezt kielégítse.

        Amúgy TE és senki más nem fizetett még egyetlen szolgáltatásukért sem. A béta hozzáférést ajándékba kapod, mert voltál olyan kedves, és előre megvetted a gémet. 28-án van a “rendes” start. Onnantól kezdve számít az, hogy te fizettél nekik (egyébként nem a játékot vetted meg, hanem jogot arra, hogy az általuk fejlesztett játékkal játszhass a szervereiken, tulajdon képpen te csak az accért fizettél). Persze, ha béták alatt gondjaid voltak, meghallgatnak, mert nekik is érdekük, hogy neked is jó legyen, továbbá értékelik a pre-purchase-t, de per pillanat semmi nem kötelezi őket.

        Ha hivatalos indulás után is gondjaid vannak 2 megoldás van:
        1: A hibáról pontos dokumentációk küldesz nekik és megvárod a végeredményt.
        2: A fiókodat eladod valakinek.

  11. Grünn
    2012. augusztus 17. - 12:29

    Mint mondtam én gépemen játszhatóan fut egy minimum követelmények felett álló cpu val!
    Intel Dual Core 3.3 ghz egésszen pontossan.
    és egy régi belépő szériás nvidia a kártyával 25-30 fps.

    Öcsémnek ugyan ezene a configon csak egy vadonat új Ati Radeon HD 6670 es kártyával 10 fps van. OK? GPU 0% Ha kihúznám a videókártyát is ugyanúgy futna. Írtam aréna netnek remélem tárgyalnak az amd vel és jön majd valami frissítés ami megoldja ezt mert ez nein gut.

    • csigusz
      2012. augusztus 17. - 12:46

      Igazad van, biztos ők rontottak el valamit.
      Elgondolkoztál már azon, hogy ha a két gép között csak a videókártya a különbség, akkor az ATi-s gépben keresd a hibát? A driver MAX! 5%-ot javít mert a motor DX9-et használ nem valami legújabb könyvtárat.

      • Grünn
        2012. augusztus 17. - 12:49

        Elgondolkoztál azon hogy te most egy olyan videókártyát szapulsz amin minden highon, ultrán elfut? :)

      • Grünn
        2012. augusztus 17. - 12:51

        Nincs azzal a géppel semmi gond, minden más játék tudja használni a kártyát. Nem hiszem hogy egy újonnan vett vidikártyánál egyáltalán ne kéne használni a gw2 nek a GPU-t. Pardon

      • csigusz
        2012. augusztus 17. - 13:00

        Ez esetben rossz kártya tipust adtál meg mert, hogy egy 5670-en (igen a 6670 csak egy átnevezést és biosfrissítést takar) nem fut minden újabb játék maxon meg ultrán 1024 feletti felbontáson az is biztos.

        De ilyen nagy különbség akkor sem lehet. A 4650-em nem produkál ilyen alacson fps-t. És ha végigolvasod a kommenteket nem pedig vérpistikéskedsz, rájössz, hogy hasonló konfiggal nincsenek ekkora gondok, csak nálad!

      • Grünn
        2012. augusztus 17. - 13:39

        csigusz :
        Igazad van, biztos ők rontottak el valamit.
        Elgondolkoztál már azon, hogy ha a két gép között csak a videókártya a különbség, akkor az ATi-s gépben keresd a hibát? A driver MAX! 5%-ot javít mert a motor DX9-et használ nem valami legújabb könyvtárat.

        Talán ha ezt nem így írod meg akkor baráti kezet kapsz.
        Ha segíteni próbálsz legyen agyad és ésszel tedd.
        Ne arroganciából és felsőbbrendűségi öntudatból.
        Nem tanították meg a szüleid a fogalmakat.

      • csigusz
        2012. augusztus 17. - 14:02

        Nos tudod mint fejlesztőt eléggé fel tudnak húzni az olyan egyének, akik mindjárt (általában minket prog.terv.infósokat/prog.matosokat) a fejlesztőket szidják. Nem írtad, hogy átesett frissítésen, szűz oprendszeren futott, stb. Innentől kezdve igenis a te hibád, ha arra sem mutatsz hajlandóságot, hogy átnézd a gépet.

      • Grünn
        2012. augusztus 17. - 18:17

        átnéztem. De neked nemhiszem hogy ilyen szemtelen modorú kis takonypócnak kéne mindent elmesélnem. Nem számodra írtam hanem az értelmesebb rétegnek.

      • MaDFoX
        2012. augusztus 17. - 18:24

        Grünn, csak egy javaslat: Mielõtt bannolnak, szerintem érdemes lenne kicsit magadba szállnod… Csak szólok.

  12. SaGaIn
    2012. augusztus 17. - 12:29

    Kimaradt egy Ne a legyen elől

  13. Solefald
    2012. augusztus 17. - 12:38

    Jó azért ne nyeljétek le csak segíteni akar, ami jó és értékelendő, hogy erre szánja az idejét. Viszont abban egyet értek hogy nem a usernél kell keresni a problémát, hisz ha minden más jól fut akkor ez a program miért nem? Itt valami a játéknál nincs rendben.

    • Grünn
      2012. augusztus 17. - 12:43

      Csak fognak tenni valamit, mert oké ahol vannak fps gondok de játszható, ott még lesznek kisebb javulások.
      De az hogy totálisan nem csinál semmit egy zsír új kártyával ilyesztő.

      UI: A cikk rendes a variance-től de nem vártam volna én se mást mint hogy a felhasználókra hárítsák az amúgy egyértelműen játékfejlesztési problémát. Kösz nem a hátamon van elég. Legyen azén aki okozza a gondot!

  14. k4csa
    2012. augusztus 17. - 12:43

    valaki egy tl;drt? :$

    • saulosman
      2012. augusztus 17. - 15:07

      Számítógépek.

  15. zEEbra
    2012. augusztus 17. - 12:49

    Az összes ismerősömnek beleértve magamat is rendesen fut a játék. Mindegyikünknek más a configja van rosszabb, jobb, ati, nvidia, amd, intel…csak egyetlen közös tényező van, az összes gép karban van tartva.
    Lehet hogy a hibát nem a usernél kell kereseni, de szerintem a megoldást meg lehet találni.

  16. SaGaIn
    2012. augusztus 17. - 12:49

    Én például a Skyrimmal kapcsoltban olvastam modder oldalon hogy például írtak egy másik d3d9.dll-t és azzal elértek 15-25 fps növekedést ugyan olyan grafikai szint mellett… vagy plédául másik srác meg játék enginvezérlő ini jébe nyúlt bele és azzal ért el 10-15 fps plust… rengeteg ilyen lehetőség rejlik programokban csak hoyg mmo-nak a kilensébe nem engednek belenyúlni pedig lehet hoyg sokkal teetségesebb programozók ülnek néha a modder oldalon… (vagy csak elhivatottabbak és jobban ráérnek) Legalább egy 64bites verziót kiadhatnának… ha más nem… legalább kihasználná a 4gb memóriát mert így nem teszi…

    • MaDFoX
      2012. augusztus 17. - 12:59

      “legalább kihasználná a 4gb memóriát mert így nem teszi…”
      De teszi! :) Nekem is tegnap lett világos. Large Address Aware enabled, 64bites oprendszerrel 4GB ramot tud mappolni (és akkor kapcsolható be a texture high opció)… Bár egyelőre csak ennyi a külömbség (és nem ajánlatos 4GB alatt mert fagy)…

  17. SaGaIn
    2012. augusztus 17. - 13:01

    Nekem eddig is bekapcolható volt minden… mégis mikor letettem csak 3GB volt csak terketa gépen vagyis pontosan 2,96 asszem de majd leelllenőrzöm mégegyszer…

    • MaDFoX
      2012. augusztus 17. - 13:06

      Bekapcsolható 64 bites OS-sel (ennyi a kitétel) de nem javasolt 4GB alatt, mert fagy(hat) (ezért is nem kapcsolható high-ra 32 biten – ott a max 2GB a ram/process ami úgy néz ki kevés)

    • MaDFoX
      2012. augusztus 17. - 13:11

      BTW ez természetesen nem jelenti azt hogy annyit is fog enni – szép is lenne ha minden progi lefoglalná magának előre a maximumot.
      WvW-n egy nagyobb tömegben érdemes megnézni sok textúrával. Majd amikor nem mindenkin ugyanaz lesz, kb 2-3 hét múlva… De részemről imádkozom tovább a 64 bites kliensért… :)

      • csigusz
        2012. augusztus 17. - 13:18

        Ha választható a 64-bites opció akkor már 64-bit kompatibilis a progi.

      • MaDFoX
        2012. augusztus 17. - 13:31

        NEM! :) Olyan nincs hogy “64-bit kompatibilis” :D Minden 64 bit kompatibilis végülis :)
        A GW2 csak LAA-t tud használni ami engedi a 32 bites proginak, hogy 64 bites oprendszerrel max. 4GB ramot foglalhasson, a 2GB helyett… Ami már az előszoba! :D
        Megjegyzés: Ha 64 bites lenne 8TERRABYTE-ot foglalhatna… =D

      • csigusz
        2012. augusztus 17. - 13:38

        64-bites annyit tesz, hogy 64 bit hosszúságú memóriacímet tud kezelni, egy progi vagy 64-bites, vagy nem, vannak hibridek, mert dinamikusan válthat a két mód között. De a játék mérete ettől nem változik.

      • MaDFoX
        2012. augusztus 17. - 13:51

        Nem is mondtam hogy változik a mérete…
        Csak annyit hogy GW2 32-bites ÉS LAA enabled. Ezért képes 4GB-t foglalni 2GB helyett.. RAM-ot!

        http://support.microsoft.com/default.aspx?scid=889654
        Konkétan a “Virtual address space” részt nézd…

      • csigusz
        2012. augusztus 17. - 14:05

        Bocsesz, engem megtévesztett az utolsó sor: “Ha 64 bites lenne 8TERRABYTE-ot foglalhatna… “!

      • csigusz
        2012. augusztus 17. - 14:12

        Végigolvastam az oldalt, amúgy tök jó, meg pontos.
        De 32-bites szálnál csak akkor van, ha azzal a flaggel fordítják le, te pedg egy előre lefordított kódot kapsz, akkor nem tudod kapcsolagtni, ha JAVA alkalmazás lenne, ami indításnál fordul le, akkor oké, de GW2.exe nem használ JAVA környezetet.

      • MaDFoX
        2012. augusztus 17. - 15:03

        De azzal forditjak :D külömben 32-biten is be tudnád kapcsolni a texture high-ot, nem lenne külömbség…
        Szóval 32 bites OS-en nem tudod kapcsolni high-ra a texture-t.
        A azért kapcsolták ki, mert kevés a 2GB RAM hozzá, fagyott / kilépett.
        64 biten be tudod kapcsolni, mert a LAA miatt már 4GB ramot tudnak használni.

      • MaDFoX
      • csigusz
        2012. augusztus 17. - 15:24

        Nincs 32-bites oprendszerem, nem tudom kipróbálni, csak tapasztalatból mondtam, hogy ha lefordítanak egy progit valahogy, akkor nincs kapcsolgatási lehetőség amivel ilyen mélyen nyúlhatsz bele a cuccba.
        Én azt tudom elképzelni, hogy 32-bites utasítás készlete van, de tudja kezelni a 64 hosszú címeket is ezzel a kapcsolóval, mert az megoldható, oprendszert le tudja kérdezni, címhosszúság pedig lehet malloc, és akkor olyat használ ami neki tetszik és nem kell külöm 64-es verzió. És amúgy okos ötlet, mert 64-es opin had használja, amúgy ne szórakozzon dupla akkora címekkel, mert azok is helyet foglalnak, ha alig valamit is.

        Nem is néztem, hogy nekem volt -e ilyen kapcsoló. Ha kapcsolgattad meg tudod mondani, hogy újra kellett-e indítania gémet utána? Csak úgy kíváncsiságból érdekel!

      • csigusz
        2012. augusztus 17. - 15:27

        Nincs 32-bites oprendszerem, a tapasztalat beszél belőlem.
        Hosszú lenne leírni a miérteket, és nem is tenném.
        De egy kérdésem lenne… Én nem is néztem az opciót, ki/be kapcsolásnál újra kellett indítani a gémet? Csak úgy kíváncsiságból.

      • MaDFoX
        2012. augusztus 17. - 16:05

        :D Nekem sincs 32-bites gépem, pedig 4 is van :D
        Én néztem az opciót és nem kellett újraindítani. De 32 biten nem lehet highra tenni…

        Pckalóz :
        Azért kell a gw2 nek a 64 bit mert a texturát medium fölé húzni csak azon engedi.Lehet akármien high tech géped 32 bites windows-on nem fogja engedni.

      • MaDFoX
        2012. augusztus 17. - 16:19

        Mint itt pl látszik is:

      • Kozzy
        2012. augusztus 18. - 09:58

        csigusz : hiába van 64 bites op. rendszer a 32 bites alkalmazás sehogy se tud 64 bites címeket használni. Ha egy alkalmazás az LAA kapcsolóval van fordítva az azt jelenti hogy egy 32 bites alkalmazás a virtuális címterében az alap 2GB-os userspace (ring3) helyett (a maradék 2 GB az kernel-ring0 és IOspace) a 32 bit által kihasználható mind a 4 GB-ot megkapja. (32 bites op. rendszer esetében is működik a kapcsoló és ott a 2 GB helyett 3 GB jár). Ajánlom figyelmedbe a WoW64 tanulmányozását. (itt nem a world of warcraft-ról van szó)
        De feleslegesen vitatkozunk addig erről amíg a játék nem használ kb 1,5GB-nál többet (még ha lehetősége van rá se). Ki kell próbálni, letesztelni hogy valóban használ-e valamelyen helyzetben többet.

      • csigusz
        2012. augusztus 18. - 10:14

        Pont ez az ami izgat. Most vagy azzal a kapcsolóval fordítják, és akkor nem tudod kapcsolagni a címhosszúságot mert ez csak egy flag fordításnál és mint olyan futás időben nem lehet már módosítani, vagy nem és marad az alap 32.
        Akkor viszont jöhet majd 64-es változat.

        WoW64 nem tudom hogy jön ide, én eddig úgy tudtam, hogy windowson belüli szösszenet, ami 64-es oprendszeren kezeli a 32-es címeket, ezért nem sír, hogy 64-eset vár.

      • Kozzy
        2012. augusztus 18. - 10:48

        32 bites alkalmazás a 32bit révén natívan nem tud 64 bites címeket használni. Sehogy. Ezért nem lehet 4GB-nál többet sehogy se használni, mert nem tudja megcímezni. A kapcsoló annyit segít hogy indulás előtt a Windows úgy rendezi át az alkalmazás virtuális címterét hogy mind a 4 GB az alkalmazásé lehessen (a hagyományos 2GB helyett). Ehhez előtte úgy kell fordítani. A WoW64 az az alrendszer ami 64 bites op. rendszeren emulálja az alkalmazások számára a 32bites környezetet. (eljárások, adatszerkezetek, vagy pl. registry, file system…)

      • csigusz
        2012. augusztus 18. - 11:42

        Ugyanazt mondanám, hogy nem itt kell ezt megvitatni.
        WoW64 eddig is világos volt, és ahogy te is leírtad az a flag fordításnál van benne, nem tudod kapcsolgatni futásnál, mert egy kapcsoló, egy flag a fordító számára. Majd utána nézek, mert nekem most az ugrik be, hogy azzal fordítják és te nem a címzést kapcsolgatod, hanem, kvázi textúrákat váltasz, hogy melyiket használja.
        Béke?

  18. Mazsola
    2012. augusztus 17. - 13:12

    Mindenképp a user-nél van a hiba. Ha a játékkal van baj, akkor is nálatok jelentkezik.
    Ez a cikk abban segít, hogy kideríthesd hol bukik a dolog és ezt küld el Anetnek. Sokkal hatékonyabban tudnak fellépni ismert hibajelenségek ellen mint az ellen, hogy “szar”, “nincs optimalizálva”, “szaggat”. Ezzel nem mennek semmire. Persze a legkönnyebb hátradőlni és fikázni.
    Minden tiszteletem Menorelé, amiért megírta ezt a cikket és próbál segíteni. A laikusok mint én kicsit tisztábban látják így, hogy miről is van szó.

  19. Arallion
    2012. augusztus 17. - 13:37

    Az, hogy bizonyos (főleg újabb, pl radeon 6-7000 sorozatú kártyákon jelentkezik a probléma, az igenis azt jelenti hogy a GW2vel van a gond. Mégis, ha pl a Skyrim meg BF3 meg hasonlók simán futnak rajta, tehát kihasználják a kártyát, akkor a GW2 miért nem? Annyira nem veszi igénybe őket, hogy fel se pörgeti a ventijüket.
    Ha XYnek megy az előbb említett 2 játék maxon akadás nélkül, és GW2 bármilyen grafon akad, akkor egyértelmű hogy a GW2vel van a baj, nem a géppel magával, mert ha a a gép lenne rossz akkor a BF3t se bírná sehogy.

    • csigusz
      2012. augusztus 17. - 13:44

      Lényegében azért akad jobban mert GW2 egy online játék. És ha venti fel sem pörög akkor a processzor fogja vissza, esetleg net. A cikk is ezért született, nem megy? Teszteld le mi a baja, melyik alkatrásznél akad fenn, és ha közben nem jössz rá, hogy nálad a hiba, mert az is előfordulhat, akkor küldd el ANetnek a screenshotot stb!

    • Polarr
      2012. augusztus 17. - 15:16

      6790-em van és ultrán 40-50fpsel fut szóval atival sincs baj :)

    • radoxx
      2012. augusztus 18. - 10:05

      Nekem 6970-es kártyám van és nem volt semmi gond vele. Az első, illetve a harmadik béta során tudtam tesztelni a játékot és mindkét alkalommal gond nélkül futott.
      A jövőben tervezem egy ütős 7000-es családba tartozó kártya vásárlását, de egyelőre bőven jó ez is :)

  20. Lenopapa
    2012. augusztus 17. - 13:38

    Tudjátok miért megváltás minden évben a szeptember az online játékok világában és miért várom én is messiásként nagyjából májustól és nyaldosom az Arenanet tökeit a megjelenési dátumért?

    Látom, ahogy könnyáztatta szemekkel, elégedett mosollyal az arcukon rezzennek meg azok az emberek, akik tudják a kérdésre a választ, ami nem más, mint bizony

    – az iskolakezdés. Oh yeah!

    • Degnar
      2012. augusztus 17. - 13:56

      +1 :)

  21. -.-
    2012. augusztus 17. - 13:39

    Egy valamit nem értek… majd aug 25 után már teljesen jogos lenne a panasz. De egyik 4 órás teszten mindenkinek hú de faja, aztán a másikon hú de rossz. Fene se tudhatja Anet is mivel próbálkozik és kísérletezik, esetlegesen, hogy keményebben leterhelje a saját szervereit is teszt vonalon.

    Kis olvasás és kiderülne, mi az ami csak élesben lesz támogatva/berakva/aktiválva.

    Nem értem az ilyen embereket, előre temetik a játékot.

    Modolás esetében meg otthon a sajátodba nyúlsz bele, persze, lehet a te configod nyugisan képes kezelni, de esetleg egy teljesen más configon összehányná magát a dolog.
    Meg egy single player játék teljesen más, egyszerűbb a dolog ott.

    De egyszerűen ez az áthárítás duma itt ezen a poszton belül, über trollkodás… másnak segít, másnak hasznos, neked nem… ez van. Megint csak az jön, hogy config függő a dolog.
    Tehát van akinek ez egy nagyon hasznos tétel itt, neked meg natúr pofára esés. Majd megjelenés után ha továbbra is gondod van, teljesen jogos a panasz. Vagy esetleg, ha kikerülne egy poszt, ami a te problémád orvosolja, én se vonulok oda trollkodni, hogy nekem nem ez a bajom/ nincs is bajom.

    De addig még van idő/lehetőség nekik is orvosolni a dolgokat. Persze, mint nekem is egy “programozó” ismerősöm, jöhet a duma, hogy á, kevés az idejük, ahoz hónapok kellenek…
    Nem tudhatjuk, nem vagyunk programozók, ha mégis nem ismerjük az enginet meg hát azt se nekik már mi van kész és a tesztek alatt mit sasoltak leginkább és mivel próbáltak nagyobb terhelést magukra rakni. Na de tényleg mindenki szakember….
    Addig érdemes foglalkozni persze a gondal, de nem leugatni azt, aki segíteni akar a másikon.

    Lehet megjelenés után rendben lesz, lehet megjelenéskor el se indul… de azért legyünk türelemmel és reméljük javítva lesz minden/sok probléma. De előre ne temessünk semmit. Ne fikázzuk le aki reményteljesen áll a dologhoz. Ne küldjük el a fenébe azt akinek esetleg gond nélkül fut, kijelentve, hogy Anet hátsót fényesít… nem fényesítek én se, csak szerencsére nekem nincsenek problémáim ezidáig a játékkal.

    Más fejlesztők még fél évvel/évvel a megjelenés után se szoktak ilyen állapotban lenni.
    (nem átkozott single player játékra gondolok, mmo kategóriára)

    • Lenopapa
      2012. augusztus 17. - 13:49

      Ha nő lennél, megkérném a kezed.

    • Polarr
      2012. augusztus 17. - 15:20

      +1
      Ráadásul akik idejárnak “trollkodni” végig se nézik, hogy ez-e a baj…, mert hogy nekik tökéletes gépük van, mert az egyik újabb játék az elindul rajta akkor ez miért nem? hogylehetnek ennyire bénák? stb ..

    • hopp
      2012. augusztus 17. - 15:32

      Pontosan. Legutóbbi stressz teszten max beállítás mellett 60-80 fps-em volt, aztán jött egy új build, újraindult a játék, és onnantól ugyanazokkal a beállításokkal 30-40. Erre vannak ezek a tesztek, csak a sok fotelharcos ezt nem képes felfogni.

      (Ettől függetlenül azért van még mit optimalizálni.)

  22. 2012. augusztus 17. - 13:41

    Csak a tisztánlátás kedvéért: Mint a post szerzője ezennek kijelentem, hogy soha egy percet sem játszottam még a GW2-vel, sem bármilyen egyéb ArenaNet producttal és nem tervezem, hogy ezen bármikor is változtatni szeretnék. Éppen ezért elég beteg dolog engem elfogult arenanet rajongónak beállítani és azt gondolni, hogy én szándékosan torzítanám el a tényeket abba az irányba, hogy ők nem tehetnek semmiről mert ők az istenek.
    Ez a post nem a GW2-ről szól, hanem arról, hogy mint játékos mit tehetsz annak érdekében, hogy vagy kiküszöböld az FPS problémát vagy legalább értékelhető információval szolgálhass a hiba bejelentéséhez. Akinek ez nem állt össze, az vagy el sem olvasta a postot, vagy képtelen felfogni a leírtakat.

  23. Morn
    2012. augusztus 17. - 13:58

    Üdv,
    kicsit eltávolodnék a témától és megszólítanám a szerkesztőket!

    Tehát tisztelt szerkesztőség, véleményem szerint ideje lenne nekiállni moderálni. Az utóbbi 3 ezzel kapcsolatos poszt tele van személyeskedő, retardált, bunkó hozzászólásokkal. Komolyan, mintha óvodás kölkök játszótere lenne a blog. Az ember nem azért jön ide, hogy ezt olvassa, hanem információért. Az ilyen írtsa ki a családját és hasonlók nem idevalóak, de egyéb megnyílvánulások sem, függetlenül attól, hogy ki írja, idegen vagy haver.
    Ossza meg az ember a tapasztalatait, a véleményét, stb de kultúrált hangnemben.
    És nem, nem vagyok sem szent sem prűd, de ami sok az sok. Mellesleg ez a blog színvonalát erősen csökkenti.
    Mielőtt bárki cenzúrával vádolna, senki nem mondta, hogy nem lehet Anet-ről vagy a GW2-ről negatívan megnyílvánulni, simán hibáznak ők is eleget, a játék sem tökéletes, nem is lehet az, de ezt lehet emberi nyelven és egymást tiszteletben tartva is tenni.
    A moderációt pedig mindenhol alkalmazzák, az nem egyenlő a cenzúrával.

    Köszönöm,
    Zsolt

    • Degnar
      2012. augusztus 17. - 14:02

      Így van,
      +1

    • ShikY
      2012. augusztus 17. - 16:34

      Mennyire igaz.. +1

  24. 2012. augusztus 17. - 14:09

    Nem akartam korábbi alpári stílusba beleszólni, nekem is 6670-esem van, és tényleg szaggatott a játék. E5700-es procim van (ami nem világbajnok, de bőven min. felett van). A gond ott volt, hogy minden beállításom voltak gondok, teljesen low-n is 17 FPS volt kezdő területeken, ahol sok ember volt. Keresgéltem a hibát, átnéztem a CPU terhelés, ott minden rendben volt, de a GPU-t tényleg nem használta ki rendesen (>40%, <60-60%-os mag használat mellett). Sajnos screenshotot nem csináltam, de ha lesz megint test, és fennáll a gond, ezzel fogom kezdeni.

    Egyébként király a játék, és ha közel optimális lesz 3 hónap múlva, én már akkor is boldog leszek, addig maximum felhúzok egy újabb altot :)

    • csigusz
      2012. augusztus 17. - 14:38

      Ha a cikk alapján készítesz nekik screenshotokat, vagy ha a progi tud valami log fájlt, és elküldöd nekik biztos foglalkoznak vele. Akár indulás után is, sőt főleg akkor.
      Rendes csapat, hamar válaszolnak, még ha csak annyit is, hogy köszi, megkaptuk a levelet, iktattuk!

      • Spíler
        2012. augusztus 17. - 14:42

        Hali! Nekem is ilyen kártyám van és 15 fps en ment low on is és kb highon is.
        Szintén DualCore 3 GHZ CPU
        Nem tudom hová forduljak, hol írhatnák aréna netnek. Meg vásároltam a játékot megnéztem a gépigényt, gondoltam játszható lesz ha nem is highon. Sajnos teszten csalódnom kellett.

        Köszi a választ előre is!

      • csigusz
        2012. augusztus 17. - 15:00

        Én megírnám a konfigom részletes adatait, hozzáfűzve, az oprendszer frissítési dátumát (updanél benne szokott lenni, hogy utolsó frissítés dátuma), hogy mikor, hol szaggatott, milyen körülmények között, pl.: Rata Sum mikor sokan voltak ott és épp csak mászkáltam, nézelődtem.

        De tekintve, hogy tényleges adatot a hibáról nem tudsz küldeni, akár egy feladatkezelő printscreen-t, maximum bekerüsz egy várólistára, ami azt jelenti, hogy ha majd végeztek azokkal a problémákkal, ahol pl. tudják melyik szál akadt be, akkor veszik elő a tiedet. Amúgy addig írogass nekik, míg nem válaszolnak (+3-4 nap a küldéstől).

        Fórumra is írhatsz, ott látják, hogy már megvetted a gémet, és nem dobják kukába a levelet, hogy “áhh minek foglalkozzunk vele, nem is vette meg egy termékünket sem”.

      • csigusz
        2012. augusztus 17. - 15:04

        Hovának pedig “http://en.support.guildwars2.com” itt kell csinálni egy support accot. Ebben nem vagyok biztos, nekem régóta privát levelezésem van, valaki kisegíthetne, hogy ez a felület tulajdonképpen mi is, és hogy működik. De fórum biztos pont!

      • 2012. augusztus 17. - 15:31

        Tényleg, log file! Otthon meg is nézem, ez így hirtelen nem jutott eszembe :)
        Egyébként én nem izgulok, csak leírtam, hogy adódtak gondok nálam is. De találtam hozzászólást már a arenanetes fb oldalon is, ami ezzel foglalkozik, tuti észlelték rajtunk kívül is. Elég sok MMO-val játszottam, legutóbb (meg még mindig) pl. a D3, ott is voltak gondok az első héten, de k.-ra nem értettem akkor sem, hogy mit kell izgulni: tervek szerint 1-2-6-10 évig játszani fogunk, akkor nem mindegy, hogy 1-2 héttel később lesz minden tökéletes?

        De ha már szóba került: regisztráltam ugye, meg minden, még sem látok semmit a fórumon. Nem jó helyen nézem? (https://forum-en.guildwars2.com/forum)

      • csigusz
        2012. augusztus 17. - 15:38

        Fórumot lehet azért nem látod, mert béta és stressz teszt híján ki van kapcsolva, és csak olvasni lehet, amúgy nem tudom. Lehet várni kell míg acchoz rendelik, vagy lassúzik a regisztrációs e-mail.

  25. Doby
    2012. augusztus 17. - 14:50

    Grünn :
    nem értem a cikk minek jött ki legtöbb embernél nem ilyen jellegűek a problémák. Bocs hogy hozzászóltam. És példaként megint az igazságot hoztam fel.

    Tehát ha egy cikk nem segít mindenkinek a gondján csak az emberek egy részének akkor már nincs is értelme?
    Vagy inkább azt akarod mondani ha neked nem segít akkor nincs értelme? :)
    Látom mindenki csak a saját érdekeit nézi.. nehogy már másoknak segítsünk ha neked nem, milyen gáz már másoknak segíteni.. :D

  26. saulosman
    2012. augusztus 17. - 15:14

    menorel :
    soha egy percet sem játszottam még a GW2-vel, sem bármilyen egyéb ArenaNet producttal és nem tervezem, hogy ezen bármikor is változtatni szeretnék.

    Na ez egy nagy hiba:D Nem tudod milyen mókából maradsz ki

  27. Lenopapa
    2012. augusztus 17. - 15:16

    Szinte meghatódtam, hogy az összes hozzászólásom megmaradt ma. :D

  28. nathriel01
    2012. augusztus 17. - 15:20

    Alapvetően nem szeretünk kommenteket, beszélgetéseket törölni, sőt, támogatjuk az értelmes, építő vitát. De itt nem az ment. Éppen ezért több komment/beszélgetés törlésre került. Kérjük, hogy a jövőben próbáljatok meg az elvárt színvonalon hozzászólni (vagy felette, az még jobb) és akkor nem lesz több ilyen. Ha valaki úgy érzi, hogy erre nem képes, akkor inkább menjen ki és fusson pár kört. Akinek nem inge, az adja vissza, köszönöm!

    • csigusz
      2012. augusztus 17. - 15:41

      Tudom, hogy én vagyok az egyik ludas, de kössz a moderálást! Most elszaladt velem az a bizonyos…

  29. saulosman
    2012. augusztus 17. - 15:23

    Doby :
    Ez a hozzászólás hogy került lentebb mint az enyém amivel erre reagáltam? :D

    Sajnos néha összezavarodik a rendszer. Feltételezhetően a komment törlések miatt.

    • Doby
      2012. augusztus 17. - 15:24

      Aha látom már, hát ez durva :D

    • saulosman
      2012. augusztus 17. - 15:27

      Oh és sejtem is hogy miért! A kommentek számozva vannak, néhány szám törlésre kerül amikor törlik a hozzátartozó kommentet. Ha ezután küldessz hozzászólást akkor előbb a kitöröltek számait kapják meg. Ha elég hozzászólás jön be (vagyis az kitörölt helyére kerül új) akkor helyre áll. Ezért érdemes a normáknak nem megfelelő kommenteket cenzúrázni, törlés helyett, így elkerülhető ez a zavar (már ha tényleg úgy működik a rendszer ahogy leírtam az előbb)

  30. Siritee
    2012. augusztus 17. - 15:28

    Nálam a fent leirtak nagyon összejöttek. GPU-t alig használja a program 10-15% a procin meg egy magon olyan 35% körül.
    Ebböl az lesz hogy 5-10 max 15 fps kb mindenhol.
    Ugy érzem én ezzel nem tudok mint tenni ha minden más tudja használni az eröforrásokat akkor a játék a hibás ebben csak egyedül.
    A legutolsó 4 órás teszten sem javult semmit a dolog. Bűvészkedhetek én itt a ezzel a utilityvel de nem tudom van -e értelme.
    Küldtem már be a hivatalos fórumon is dxdiag logot meg ilyeneket nem tudom értek-e vele valamit.
    Még mindig remélem hogy 25-én nem az lesz hogy elinditom és 20 perc mulva törlöm is le mert nem fut a gépemen.

    • csigusz
      2012. augusztus 17. - 15:45

      Cikkben leírt módon történő hibabeküldés sokat segít, ha 25-én vagy ha lesz még teszt akkor is fennál ez a dolog, akkor feltétlenül küldd el a printscreen-eket! Egy ilyen melyik szál hibás dolog nagyon sokat tud segíteni!! Viszont DXDiagtól óva intenék mindenkit! Az a directx könyvtárat ellenőrzi, futás közbeni problémákat nem! (Jó olyat igen, hogy az alkalmazás d3d96 dll-t akart futtatni, de csak d3d25 volt telepítve, de ez vajmi kevés segítség.)

  31. MaDFoX
    2012. augusztus 17. - 15:29

    Ugyan oroszul van, de a képek, különösen a cikk közepén az VGA összehasonlítások magukért beszélnek:
    http://gamegpu.ru/mmorpg-/-onlayn-igry/guild-wars-2-beta-test-gpu.html
    GW2 RENGETEG VGA-n és CPU-n kipróbálva és összehasonlítva… Nézzétek meg érdemes.

    • MaDFoX
      2012. augusztus 17. - 15:32

      Érdekes megfigyelni hogy XP (SP3) komp. módban futtatják Win7 alatt a játékot, az AMD (ATI?) kártyáknál…

    • Siritee
      2012. augusztus 17. - 15:41

      Ez a táblázat nagyon elkeseritő.
      1920ban 60-70 et kellene menni de nálam csak 10 van.
      Én ezt nem értem már. 2 hete ujra letöltöttem mindent de nem javult meg.

      • hopp
        2012. augusztus 17. - 15:49

        Legközelebbi teszten próbáld meg xp kompatibilitási módban futtatni. Ezeket a teszteket úgy csinálták.

    • Doby
      2012. augusztus 17. - 15:42

      Ez a kép mindent elmondd! go a boltba GTX690-ért :D laza 300.000forintbol megvan :D

      • MaDFoX
        2012. augusztus 17. - 16:00

        Nem értelek! Meglepődtél hogy a legerősebb kártyán lett a leggyorsabb a játék? Vagy miért írod ezt?

      • paprika
        2012. augusztus 17. - 16:02

        680 csak 150.000. Fő a kompromisszum.:D

      • paprika
        2012. augusztus 17. - 16:03

        Egyébként engem tényleg meg lepett hogy a 680 és 690 között ekkora különbség van!

      • MaDFoX
        2012. augusztus 17. - 16:11

        Árban vagy teljesítményben? :D
        Végülis a 690 tulajdonképpen 2db 680-as kártya egybegyúrva…
        Látszik hogy nem bírnak teljesíteni az erős chipek (sok a CPU bound dolog), csak a nagyobb felbontásokban lesz igazán nagy külömbség…

      • paprika
        2012. augusztus 17. - 16:13

        A poén az hogy egy 670 és 680 között van 7-10FPS különbség, de egy 680 és 690 között 50-70FPS. lol.

  32. SaGaIn
    2012. augusztus 17. - 17:14

    Kérdés ha az előbb írtak szerint 64 bit kell a játéknak (nekem az van de ez most lényegtelen.) akkor miért nincs/vagy nem lesz 64 bites verzió? mert így mondjuk totál feleslegesen van 8GB memróriája valakinek ami most sem kiugróan sok és két év múlva még inkább nem lesz az.
    vagy hiába van 64 bites új utasításokat támogató processora ha nem használjuki ki.

    Amúgy elnézést kérek a korábbi személyekedésért kissé túlzás volt de azt még mindíg tartom hogy egyesek elfogultak és tulzottan védika fejlesztőket holott ők vannak értünk és nem fordítva.

    Nem tudom ki írta mert nem írt nevet de mindegy is lényeg hogy nem értek egyet vele

    “hogy egy single player játék más ott sokkal egyszerűbb dolog ”
    és : “(nem átkozott single player játékra gondolok, mmo kategóriára)”

    Mért lenne egy singel player más és átkozott…(mostanában már nem is jelenik szinte hadcore singe player játék legtöbbhoz van valami online mód vagy multi és itt AAA kategóriáról beszélek nem sufnifejlesztésről ) Azok is rengeteg féle gépen futnak. (Ott is belefutottak ilyen optimaizálási gondokba lásd SettlersVII vagy GTA4(ami konzolátirat voltának köszönheti a dolgot de ez mindegy is.) Az sem kevesebb meló fejleszteni. Az hogy az MMO-k at általában kevéssé optimalizálják illetve nem annyira grafika orientáltak az tény de nem szükésges és örvendetes dolog. Főleg ha egy Szintén Nc-soft játékból idulok ki ahol a grafikai és szerver optimailzálatlansági hibákat évek óta nem sikerült megoldani. Mondhatok példákat de szerintem senki nem érdekel. és Ott nem 10-20% nak van gondja hanem ezeka hibák globálisak és ki is használták őket sajnos.

    Ne mondom hogy fejlesztőnek úgy kéne viselkedni mint a 3drelams ahol 14 évig fejlesztettek egy végül csalódást okozó játékot mert mindíg haladni akartaka korral.
    De azért egy 64bites, új kártyákat, procikat kihasználó, skálázható 2012ben elvárható garfikával megáldott motor jó lenne. Mert mindent maxra húzva jól nézett ki supersamligel azt tény de annyira nem hogy ehhez egy 150k hufos videókártya és processzor kelljen 40 fps el futtatva.
    Szóval nagy javulást szeretnék de nem számítok rá mert az eddigi negatív tapasztalok a játékok terén ezt sugallják.

    • csigusz
      2012. augusztus 17. - 17:32

      64 bites futtatható állomány több okból lehet nem lesz, ha nem kell, mert 4 gb untig elég lesz, akkor minek, stbstb. Offline is játszható játék azért más, mert ott nem kell szinkronizálni mással. Multiban sem, mert nincs akkora multi pálya mint GW2-ben egy terület amit szinkronizál, sem annyi játékos. Ezért egy mmo sokkal többet eszik egy offline játéknál ezért nem is néz ki úgy.

      • SaGaIn
        2012. augusztus 17. - 20:41

        Mért kerül egy szinkronzálás több erőforrásba mint egy komoly AI számolás vagy mondjuk egy fizikai szimuláció? Másik példa Ha veszzük a Starcraft2 őt ahol 4v4 ek vannak hatalmas pályán több száz egységgel? Az is szerver komunkáció és garfikailag sem gyengébb szerintem. Ráadásul ott nincs olyan hogy egy fal eltakar valami és nem kell számonli…
        Azt ne kérdezzétek hoyg mért iylan példákat hozok mert a GW2 iis AAA kategóriás szerintem és Starcraft2 skyrim crysis Tera is
        De hozhatok ezer példát még… meggyőzni addig úgysem tudtok jólvan ez így míg nem hoztok tényeket/számokon alapuló példákat hoyg mért kéne egy GW2 kilensnek kétszer többet számolnia egy Másik AAA kategóriás 2011-12-es címnél

      • csigusz
        2012. augusztus 18. - 06:28

        Egy online játék UGYANAZOKAT a feladatokat végzi el mint egy offline + szinkronizálás. Az AI-t, reflexciókat, stbstb mind számolja. De mivel online játék neki folyton beszélgetnie kell a kiszolgáló géppel, hogy szia a felhasználóm ezt a parancsot küldi, várom a te parancsaidat. És állandóan fülelni az adott csatornát, van-e rajta adás, és ha van feldolgozni azt.

        Részletesebben:
        – Renderelés:
        Minden objektum mindig le renderelődik egy adott scene-en belül, akár takarja valami akár nem. Azért nem látszódnak a kitakart objektumok, mert a renderelés 1 db képet csinál. Olyan, mint ha festesz egy képet, és rájössz, hogy hoppá, van ott valami, és ráfestesz. A régi festés ugye nem fog látszódni.
        – Kommunikáció:
        Angol nyelvű példáért írd be: “1500 archers”
        A szinkronizálásnál nem szinkronizál minden elemet minden egyes pillanatban. Szépen is nézne ki, a procit is leterhelné, meg kb gigabites tényleges kapcsolat kéne a két gép között. Az okos programozók kitalálták, hogy ha csak felhasználó parancsokat küldenek
        (pl. x=1y=1 és x=2y=2 koordináták között minden egységet kijelöltél és elküldted őket x=7y=4 koordinátára. Az, hogy a kijelölt koordinátákon belül neked milyen és hány egységed van, az teljesen mindegy, mert a másik gépen is ugyanott állnak azok az egységek, és ő majd kiszámolja, hogy mik vannak benne, és meg is mozgatja őket.)
        akkor is a parancsnak minden gépen ugyanúgy kell lefutnia, persze azért egy idő szinkronizációt beraktak a lagg miatt.

        Példák amiket kértél:
        – Starwars: The Old Republic (MMO) : A világa nem olyan változatos, mert pl. az épületek burkolata ugyanaz a kép ismételve és alig vannak (városon kívül) dinamikus elemek, amik számolással terhelnék a gépet, stb… Nálam csontra ugyanazt a színvonalat hozza mint GW2. Remélem az, hogy BioWare termék, és nem kis név, tehát erőforrás nem kicsi áll még most is mögöttük, továbbá AAA név elég neked.
        – Aion 2.0: Kalandozás közben megint nincs különbség ugyanazért mint az előző példánál, de városokban, vagy nagyobb siege-oknál olyanokat szaggatok mint sehol máshol, még itt GW2-ben sem WvW közben. Aion közben csak azt veszem észre, hogy megjelenik az ellen horda, kövi kép, hogy már fekszem.

        Olyan játékkal meg kár és fölösleges összehasonlítani ami merőben más programozói és tervezési szemléletet igényel.

        Remélem minden kérdésedre sikerült válaszolnom!

      • Kozzy
        2012. augusztus 18. - 09:41

        Itt is eléggé félre informálod a többieket. Jobb ha inkább fejleszted még a “szakértelmed”.
        Pl.
        -renderelés: pont hogy nem fognak mindent (pl takarásban lévő illetve túl messzi dolgot) kiszámolni, ezzel gyorsítanak a legtöbbet. Olvasd el mit csinál az Umbra Software amit a GW2 is használ.
        – a kommunikációs részt nagyjából jól írtad, de azért amit írtál kb a starcraft-ra vagy az age of empire-re ráhúzható, egy MMO azért ettől jóval eltérő net-kódot alkalmaz.
        -egy MMO-ban az AI és a “reflexiók” (ez inkább szerintem reakciók) nagy részét a szerver számolja és csak elküldi az eredményt (a reakciót) a klienseknek.

      • csigusz
        2012. augusztus 18. - 12:28

        – Renderelésnél egy szoftver nem tud különbséget tenni az objektumok “mérete” között, z indexen persze, de azt nem az umbra motor csinálja, akármilyen view mátrix van megadva, van z-indexre benne egy tól-ig érték. Forgásnál persze ott angle miatt lehet számolni, hogy mi kell és mi nem, de ott sem valami nagyon ésszerű dolog, mert kiszámolni, hogy a középpontól ahol ki kell rajzolni melyik pontja esik esetleg a view-ba majdnem ugyanannyi idő, mint kirajzolni. És akkor még szó sem volt arról, hogy amíg proci csekkol, addig vidikari áll, így a scene lerendelése több időt karol fel, mintha nem válogat. Én annó azt próbáltam, hogy minden objektumra számoltam egy ranget ami pl max szélesség*scale volt, hogy ne kelljen minden pontot végignézni, de nem volt javulás, viszont procira plusz feladatot küldtem.

        – Kommunikációnál pont RTS-ekre akartam rávilágítani, hogy azok nem használnak több netet szinkronizálásra csak mert rengeteg egység van bennük.

        – Megint csak azt tudom mondani, hogy akkor elég szép sávszélesség kéne, és reflexiók alatt azokat is értem. Itt arra akartam kitérni, hogy csillogást-villogást ugyanúgy számol mint más játék ahogy AI-t is. Egy játékban minden időzítve van, nem random rohangálnak az npc-k. Indulásnál megkapod a szinkronizálási időt, és onnantól a kliens pc számolja az AI-t is. Ha meg event miatt van változás akkor is csak valami event azonosítót kap a gép.

        És ez sem ide való hozzászólás, úgyhogy részemről ezt is lezárom.

  33. Kozzy
    2012. augusztus 17. - 22:53

    Menorel:
    Amiről nem tudsz mert nem próbáltad: a GW2 ki használja a 4 magot (akinek intel i7 van a HT miatt 8at lát a diagnosztikai programokban, de ebből 4 a valós, és kb csak azok vannak rendesen használva).
    A magok kihasználtsága pl nálam kb : 85%+,60%,50%,30% volt. Ez bőven kielégítő, azaz normális. Ennél jobban kb nem lehet szétosztani a terhelést. Azaz amit írtál hogy 1 mag van 85%+-on a többi meg csak közel 50%-on teljesen normális! Egy játékot se láttam még hogy a többi magot is 60% felett kihasználta volna. Ez meg azért van mert azok a részei a motornak egyszerűen nem esznek annyi CPU-t. Csak összehasonlítás képen a
    WoW DX9-ben: 80%+,40%,30%,20%. (40% GPU) GW1 DX9 : 75%+,40%,<20%,<10% (60% GPU), itt már látszik hogy nincs értelme a 4 magnak.
    LOTRO DX10: 50%+, 40%, <10%,<10% (95% GPU).
    Érdekes hogy pl a LOTRO alig eszik CPU-t és a GPU-t így is közel maxon pörgeti.
    Aki akar az affinitással tud játszani a feladat kezelőben. Pl. ha a LOTRO-nak csak 1 magot adtam az pörgette 100%-on és majdnem hozta azt az FPS amit 4 maggal. 2 maggal már ugyan azt kaptad mint 4-el.
    GW1-ben 1 maggal szintén van némi FPS esés, de 2-vel már ugyan az mint 4-el.
    Ami látszik : a LOTRO nem használ 2 magnál többet, a GW1 használ akár 2 nél többet is, de 2 felett a többit érdemlegesen nem használja, és kb ugyan ezt a helyzet a WoW DX9-nél is.
    GW2-ben a legjobb a helyzet ezek az MMO-k közül CPU kihasználtság terén.
    Egyébként a GW2 CPU kihasználatlansága miatt kb senki se panaszkodott ha jól tudom.
    Szóval a lényeg: leginkább a VGA volt amit sokat "szidtak", hogy nem használja ki rendesen, és az volt a másik nagyobb baj hogy a beállítások nem hoztak akkor teljesítménybeli különbséget mint amekkorát látványban.
    Pl. max beállításokkal volt 30 FPS-ed akkor csomó dolgot visszavéve se lett 40-nél több, viszont sokkal csúnyább lett.

    Még pár megjegyzés:
    -attól még hogy egy játékban nincs se a (össz.) CPU se a GPU 50% felett kihasználva futhat teljesen jól. Pl WoW, GW1. Nálam pl a GW2 is össz. CPU-ban (4magra nézve) nem volt 50-60% felett, és GPU-ban se nagyon volt 60% felett, mégis elég jó FPS-eket kaptam a gépemhez képest.
    -a process explorer-ben pedig a thread-ek össz. CPU idejét látod (az összes magra számított), azt nem melyik thread melyik magon mekkora terheltséget okoz.
    -a thread stack-jével nem sok érdemleges információt fogsz kapni, többnyire olyan eljárások nevét szedi elő a veremből amik egy objektumra (mutex, szemafor) várakoznak. Ebből az átlag felhasználó semmit se ért, sőt azt is kizártnak tartom hogy ezt akárhová beküldve "komolyan vesznek". Arról nem beszélve hogy a stack információ többnyire minden időpillanatban más és más lehet.

    • csigusz
      2012. augusztus 18. - 06:50

      A pár megjegyzésedhez hozzászólnék:
      – Attól, hogy nem látod melyik szál éppen melyik magon fut, és mennyire használja nem is fontos, a process time és cycles pontosan megutatja egy összehasonlításban melyik szál okozza a gondot a többi GW2-es szálhoz képest. Mivel ők is nagyon jól tudják melyik szálnak mennyi erőforrást kell igénybe venni hipp-hopp kiszámolják, melyiknél van a bibi. Amúgy onnantól, hogy te fizettél a termékükért komolyan vesznek. Persze ha valami extrém hibát generálsz amit ők sem tudnak leszimulálni. Akkor semmit sem fognak tenni.
      – thread stack: hogy mennyire értékes információ van benne, azt annak a szálnak a programozóján kívül senki sem tudja megmondani, mert nem lát bele a működésébe. A stackben pedig utasítások vannak, sulis példa: popok, meg pushok. Nem tudom ez a progi milye n mélységig szedi ki milyen utasítások vannak elvermelve, de MOV, MUL szintnél lejjebb nincs, és az is hasznos. (mutex == szemafor, és köszönő viszonyban sincs a veremmel. Egy adott funkción belül van egy várakozás, de attól még a szál pörög, mert állandóan csekkolja, elérhető -e az az erőforrás amire vár, ebből következik, hogy a stack-je is pörög.)

      • Kozzy
        2012. augusztus 18. - 08:26

        Lol. Itt látszik mennyire nem értesz a rendszer programozáshoz..de azért próbálsz bele kontárkodni…ne tedd mert csak beégsz…
        Ha értesz is a programozáshoz kb Java/Php programozó lehetsz mert a rendszerprogramozáshoz lövésed sincs.
        -eleve rossz a koncepció: honnan veszed ha egy szál több CPU-t visz el akkor az “rossz”? Tanultál algoritmus párhuzamosítást? Ugye tisztába vagy vele hogy nagy részük nem könnyen párhuzamosítható, azaz többnyire 1-3 szál van ami több CPU-t “eszik” és ez teljesen normális. Annak az esélye hogy van nálad egy GW2 szál ami valami oknál fogva jelentősen leterheli a CPU-t, de nem kellene neki kb 0%. (ebben igaza lehet Meno-nak, estleges hibás driver okozhat ilyet)
        Ha meg épp az ellenkezője, kevés CPU-t használ akkor se tudsz kb semmit tenni.
        -még ha foglalkoznának is egyenként minden ilyen hibát bejelentő emberrel akkor is egy Process Explorer féle stack reportból semmit se tudnak “leszimulálni”. Hidd el hogy megvan nekik erre a megfelelő ember/környezet.
        -a stack-ben nincsenek utasítások..tanultál te valaha assembly programozást? (Vagy számítástechnika/operációs rendszer alapismeretek?) Mert ha igen akkor ülj le egyes. Mert én vagy 10 éve foglalkozom vele..(igaz most már csak hobbiból). A stack-ben (verem) a hívó (“magasabb szintű”) eljárások/rutinok visszatérési címe és a hívó paraméterei vannak (STCALL vagy CEDCL szerint), illetve az adott rutin lokális változói. Egy debugger, vagy pl. a Process Explorer amikor kiszed a veremből (stack) információt akkor az utolsó pár hívó eljárás címét keresi ki, illetve az azokhoz tartozó neveket és az eltérés offszet címét. Nincs semmiféle utasítás, se “push”, se “pop”. A “mov” és a “mul” meg köszönő viszonyban sincs a veremmel.
        -a várakozást onnan szedtem hogy ha elindítasz egy ilyen stack reportot akkor a “kihalászott” eljárások azok pont ezek lesznek: WaitFor..
        És ha egy szál várakozik egy objektumra/eseményre (mutex,szemafor) akkor rendszerint nem pörgeti a CPU-t..mert várakozó státuszban van. Ezt mondjuk én néztem be, teljes képernyős módban indítottam a játékot, és a Process Explorer féle stack infó csak ablakozva ad némi érdemleges infót :)

      • csigusz
        2012. augusztus 18. - 08:48

        “honnan veszed ha egy szál több CPU-t visz el akkor az “rossz”?” Nem látom ilyesmit hol írtam.
        Algoritmus párhuzamosítás meg csak programozó kérdése.
        És ha látják, hogy melyik szál eszik láthatóan több erőforrást, mint ahogy az elvárható, akkor ahhoz kapcsolódóan keresik a hibát.
        Stack report meg tele van utasításokkal, és így kis töprengés után rá lehet jönni melyik sornál van a bibi.
        Látom nem tűnt fel, hogy pl. már a MOV is assembly parancs, és a PUSH() stb. eljárások is ezekből épülnek fel, de példákban push-t és barátait használják, sebaj.
        ST(D)CALL,CEDCL , ne dobálódzunk olyan kifejezésekkel amiről foggalmunk sincs micsodák.

        Beismerem túl sok információt nem adnak az ilyen reportok, de adnak egy kiindulási pontot, ami sokkal de sokkal több a semminél!

      • Kozzy
        2012. augusztus 18. - 09:00

        Itt ezt írtad : “process time és cycles pontosan megutatja egy összehasonlításban melyik szál okozza a gondot”..szóval amelyik sokat visz az gondot okoz?
        A stack-ben egy utasítás sincs! Miről beszélsz legalább olvass már utána légy szíves! Mint mondtam visszatérési címek, paraméterek, és lokális változók vannak.
        Mint mondtam több mint 10 éve foglalkozom a témával, nekem nem kell elmagyaráznod mit csinál a “push” és a “mov”..bár ez elemi/alapszintű assembly..és te mégse vágod..
        Attól még hogy félregépeltem egy betűt.valószínűleg ezer évvel előtted tudtam már mi az az stdcall, és cedecl..és ennek van köze ahhoz hogy mi hogyan van a stack-ben.
        Itt kedves Csigusz te vagy az aki nem tudod miről beszélsz csak próbálsz okosnak tűnni. Jobb ha inkább abbahagyod…

      • csigusz
        2012. augusztus 18. - 09:08

        Öhm a process time stb-nél arra gondoltam, hogy tegyük fel a progim 100 időegységet eszik (4 magon 25). És tudom, hogy az eloszlás 1:2:3 arányos három szál között, akkor ha egy olyan report jön, hogy 2:1:2 arányban eszik, akkor tudom, hogy első szál valamirért elszált, és elég lesz ott keresni a problémát. Nem arra gondoltam, hogy rossz, csak arra, hogy a problémát ott kell keresni, bár ez tényleg majdnem egyelő a rosszal.

        Nem szeretnék most könyvet scannelni, de egy linket azért adok, tudom wikis, ode meg mindenki beleírhat, de most külön nem fogok netes oldalak után kajtatni.
        “http://hu.wikibooks.org/wiki/Assembly/Veremkezel%C3%A9s”

        stdcall és cdecl pedig csak fordítónak mondja meg, hogy a deklarálásaid c illetve standard tipusúak. Ezek a lefordított kódban, ami a veremben is megjelenik, nem látszódnak.

        Tök jó, hogy 10 éve ezzel foglakozol! Nem értem miért jó hangoztatni nekem még sosem jutott eszembe.

      • Kozzy
        2012. augusztus 18. - 09:25

        LOL. Egyre nagyobb hülyeségeket beszélsz..haha..remélem jön valaki aki még jártas a témában és olyan jókat röhög rajtad mint én :)
        Ott a wiki amit linkeltél. El se olvastad. Az első pár mondatot olvasd el: a verem egy adatszerkezet ahogy írják is gyakorlatilag egy memória terület, ahová az egyes eljárások a meghatározott hívási konvenció szerint (stdcall, cedecl) rakják be a visszatérési címet, a paramétereket a veremben. Aztán az hívott eljárás a lokális változóit szintén a veremben foglalja le.
        “Ezek a lefordított kódban, ami a veremben is megjelenik, nem látszódnak.” Haha..ezen jót nevettem. A lefordított kód a veremben megjelenik? :P
        Oké, tegyük fel hogy az első pontban (szálak) kimagyaráztad magad, de akkor meg ez előző posztjaidban helytelenül fogalmaztál.
        És ha rájössz hogy nálad nem ugyanolyan arányban esznek CPU-t az egyes szálak? Erre egyébként mint mondtam is kb semmi esély nincs, max ha rossz driver-jeid vannak. Vissza fogod debug-olni? Mert attól nagyon távol állsz :)
        Jobban érzed magad? Mit fogsz csinálsz? Kb semmit..megjavul tőle a problémád? Beküldesz egy report-ot és várod hogy megcsinálják neked? Esetleg akkor ha a probléma tőlük ered (amit te nem tudsz megmondani), és széles körben fellép (mondjuk több mint >5%) idővel kijavítják.

      • csigusz
        2012. augusztus 18. - 09:49

        Persze, ha rossz illesztőprogramjaim vannak azzal nem tudnak mit kezdeni, de az átlagfelhasználó meg nem tudja kiszűrni. Beküldi és vagy lesz valami, vagy nem. És biztos írnak neki, hogy próbálja ki más egérrel, stb. Nekem ilyen problémáknál mindig írták, hogy nálunk nem sikerült reprodukálni a hibát, nézzem meg, így/úgy. Ha akkor is fenn állt a hiba, akkor termékcsere, amúgy segítenek, mert a supportos csókákat ezért fizetik, tiket alapon.

        Ahogy az oldal is írja.
        3 művelete van 1 veremnek.
        Pop, Push, Top.
        Ezeket valahogy meg is kell valósítani (oldalon példa is van rá).
        Ahogy megvalósítod az kerül be a verembe, mert a proci kb egy giliszta intelligenciájával bír és nem tudja mi az a pop pl.

        Namármost a proci verem szemlélet alapján dolgozik, tehát az utasításaid be fognak kerülni oda. A wikis példa egy adatverem példája, mielőtt félreértés lenne.

        A cdecl pl. abban segít kizárólag a fordítónak, hogy ha van egy c++ nyelven írt programod, de te egy régi könyvtáradból szeretnél importálni egy c valamit aminek a kódja ütközik c++ kóddal (mert előfordulhat hiába c++), akkor ő tudni fogja, hogy nem a c++ értelemben véve kell lefordítania azt a kódrészletet, hanem c szerint. Tipikus felhasználása c-ben megírt dll-ek ahol a forrás fájl kitejesztése nem .c így a fordító nem tudja megmondani, hogy az c kód.
        Stdcall nagyából ugyanígy működik.

        És elnézést ha nem teljesen érthetőek a hozzászólásaim, én is csak egy progi vagyok másokkal való kommunikáció során lefagyok. :-D

      • Kozzy
        2012. augusztus 18. - 10:36

        Hm..sajnos hiába győzködlek, nem tudod elismerni hogy nem érted mi az és hogy működik a verem. Az a baj ahogy látom a c-t ismered de azt hogy ahogy lefordul (a generált assembly kódot), és a rendszer működését nem látod még át. Ez nem nagy baj, nem is kell feltétlen tudni ezt, csak amikor más próbálja elmagyarázni akkor meg kell próbálni megérteni és nem ragaszkodni a rossz elméletedhez.
        Az stdcall és a cedecl szempontjából nem írsz hülyeséget, de sajnos nem tudsz túllépni a c programozási nyelven. A verem egy sima memória terület. Vannak assembly utasítások amik tudnak a tetejére bedobni adatot (push), illetve kivenni onnan (pop). De mivel ez egy sima memória terület közvetlen, bármelyik része (nem csak a teteje) is hozzáférhető, és ezt a paramétereknél és a lokális változóknál ki is használják. Ezzel eléred azt hogy ezek mind eltávolítódnak “automatikusan” amikor vége az eljárásnak. És mint sűrűn használt memória terület benne lesznek a CPU cache-ben amivel meggyorsul a lokális változók elérési sebessége. Mint már ezerszer írtam, az stdcall és cedecl : ezek hívás konvenciók amik azt határozzák meg hogy másik eljárás hívása előtt a paraméterek milyen sorrendben legyen berakva a verembe, és hogy hogyan kell őket eltávolítani (a hívó vagy a hívott takarítja a vermet). Ezen felül a hívott eljárások lokális változói vannak a veremben.
        Írok ide egy példát:
        c++ eljárás : … vonal (x,y,dx,dy,color)
        Ez stdcall-nál így fordul le : push x,push y, push dx,push dy, push color, call vonal. Cedcl-nél ez fordított sorrendben van. Ha mondjuk a verem mutatód mondjuk kb 1k-n volt akkor most így fog kinézni a vermed 32biten:
        0x00000400 x
        0x000003fc y
        0x000003f8 dx
        0x000003f4 dy
        0x000003f0 color
        0x000003ec a hívó eljárás visszatérési címe
        Aztán a hívott vonal is foglal magának lokális területet, azaz csökkenti a verem mutatót amennyi bájt kell neki. (4-re kerekítve, sub esp,8)
        0x000003e8 lokális1
        0x000003e4 lokális2

        Aztán a végén vonal eljárás felszabadítja a lokális változóit, hozzáad a veremmutatóhoz annyit amennyit az elején elvett (add esp, 8 ,ezzel szabad lett a terület). Stdcall-nál kiszedi a paramétereket is a veremből és visszatér : ret 0x14. cedecl-nél csak visszatér : ret, és a hívó eljárás szedi ki paramétereket a veremből (hozzá ad a mutatóhoz 0x14-et).
        Szóval mint látszik a veremben csak paraméterek, visszatérési címek és lokális változók vannak. Nincsenek utasítások.
        Azok külön, úgynevezett kódszegmensben vannak, a veremnek megvan a saját adatszelektora. Így pl nem lehet kód területre írni, és ha veremhiba keletkezik akkor lehet bővíteni a vermet.
        A proci igen, ismer olyan utasításokat mint pop, push. De a verem mint a memória terület közvetlen is hozzáférhető. Haha jó is lenne ha nem lehetne..minden paraméter vagy lokális változó előtt rengeteg push/pop kellene, illetve hozzá se lehetne férni.
        Ezer éve foglalkozom ilyesmivel, foglalkoztam debug-al is, de te csak a c-s részét látod át, a valódi rendszer (assembly/hardver) mechanizmusát nem. Kérlek olvass utána mert még mindig nem érted. Az pedig hogy érted c-ben nem elég ha ilyen témákra akarsz választ adni.

      • csigusz
        2012. augusztus 18. - 11:28

        A cdecl (egy eljáráson értelmezve) tényleg üríti a vermet, mivel minden c/c++ elj. megteszi magától ennek a hívásnak legtöbbször (ebből a szempontból) csak magas nyelvekben van értelme, amik nem ürítenek maguktól. Assemblyben te teszed ezt meg. cdecl-t használhatsz változóra is, pedig akkor semmilyen sorrend nincs se verem.

        Amúgy szerintem mi nagyon elbeszélünk egymás mellett.

        Veremnek csak az utolsó elemével tudsz kezdeni valamit, persze amúgy bármelyiket törölheted, és a legutolsó két elemet felcserélheted de ennyi. És az utasítások is verem alapján vannak. Bepakolgatja őket aztán visszaolvassa. Ezért vannak az előtagok, hogy tudja melyik utasítás és melyik nem.

        Ha te tudsz a verem aljáról is olvasni, akkor valószínűleg nem vermet használsz. És pop eljárás tényleg van assembyben, de ő azt át fogja fordítani egyszerűbb assembyre, és a proci nem pop utasítást kap mert az oké, hogy kiemel de azt neki valahova el is kell tennie amit egy sima pop-al nem tudsz megmondani neki. Ha megnézed a generált assembly kódot pop-ot és barátait nem fogod megtalálni. Ha mégis akkor te matlabot, whitespacet vagy valami hasonlót használsz amitől az Isten mentsen meg mindenkit.

        Amúgy tényleg, hardver közelt sosem szerettem és most is csak debugra használom, mert szerencsétlen környezetem nem tud rendesen debugolni, csak assembly kódot dob vissza, hogy na ez a művelet nem volt sikeres. De ettől még sajnos tudnom kell, hogy működik, mert különben soha nem jönnék rá hol vannak a hibák. Ha lehetőségem lenne maradnék c/c++-nál és soha de soha nem néznék assembler felé sem.

        De ez nem egy ezzel foglalkozó blogpost, úgyhogy szerintem hadjuk mert úgy sem jutunk dűlőre. Biztos nem szájhős vagy, mert ők nem írnak ilyen mélységben, aminek amúgy tökre örülök, mert érdemben lehet vitatkozni. Én minden progmatost sajnálok (gondolom a te végzettséged is az 10 éves szakmaival) aki abbahagyta, mert kevés a jó programozó. Béke?

      • Kozzy
        2012. augusztus 18. - 12:14

        Sose haragudtam szóval persze, “béke” :)
        És igen , nagyon túlreagáltam már a témát, de csak szerettem volna elmagyarázni mi hogy működik a CPU-ban alacsony szinten. Itt a legtöbben valóban még csak a programozás magas szintű részével se foglalkoznak, nem hogy a rendszer programozással. De ezzel semmi baj, hiszen egy játékról beszélgetünk :)
        Amúgy te a veremről mint adatszerkezetről beszélsz, és úgy nagyrészt helytállóak amiket írták.
        Én meg az egyes szálak (thread) verméről beszéltem ami gyakorlatban merőben másképp működik mint ahogy az elméleti verem adatszerkezet.
        A “pop” márpedig igen is van, létezik, és nem is ritkán használt utasítás, és nincs egyszerűbb formája. A “pop” utasításnak is van paramétere, ugyan úgy mint a “push”-nak. Push-nak az hogy mit dobjon a verembe (ez egy 32bites érték, ami lehet cím is, ez az értelmezéstől függ.), a “pop”-nak pedig hogy amit kivesz a veremből hova tegye (pl regiszter). Pl. sűrűn használatos eljárások végén amikor ez eljárás elején mentett általános célú regisztereket hozod vissza az eljárás előtti állapotra. Ugye 32 biten 4 általános célú regiszter van: eax,ebx,ecx,edx.
        Egy összetettebb számításnál (főleg ha optimalizálva van) szükség van mindegyikre. De a egyes konvenciók fenntartanak egyes regiszterek értékének megőrzését. Pl. ha minden regiszteredben hasznos információ van, de valamiért eax-ba mást kell raknod (pl meghívsz valamit ami eax-ban várja a paraméter) akkor a régi értéket így őrzik meg:
        push eax ;eax a verembe
        ;eax használata valamire pl:
        mov eax,[esi] ;eax megváltozott
        call eljárás
        pop eax ;eax visszaállítódott a régi értékre ami a veremben volt
        A “pop” utasításból azért látsz kevesebbet mint a “push”-ból, mert a paramétereket “push”-al szokták a verembe rakni eljárás hívás előtt, de kiszedni nem “pop”-al kell mert nincs hová rakni, a paraméterek az eljárás után nem kellenek tovább, felesleges adatok. Lehetne úgy is kiszedni őket a veremből hogy tolnak annyi pop x-et (x üres regiszter) ahány paraméter volt, de ez nem túl hatékony, egyszerűen hozzáadnak y*4 bájtot a veremmutatóhoz: add esp,y.
        De pl. a paramétereket így éred el a veremben: pl.1.param címe= [esp+0x10] második= [esp+0x0c].stb..pl. mov eax,[esp+0x10] = első paraméter eax-ba rakása. Lokális változónál szintén : [esp+0x0], [esp+0x04]…stb. Azaz sima indexelt memóriaként hivatkoznak rá, mert különben nem lehetne elérni benne semmit se.
        És a szálak vermében továbbra sincs 1 utasítás se, nincs előtag hogy ez utasítás vagy adat. Csak adat van: paraméter, visszatérési cím, lokális változó.
        Nah ennyit a mai rendszerprogramozói óráról :)

  34. Latabar
    2012. augusztus 18. - 00:24

    ember… te aztán vér profi vagy…

  35. SaGaIn
    2012. augusztus 18. - 01:12

    Kozzy csak azt felejted el hoyg mikor a woow és a GW1 et írták még szó nem volt töbagos processorokról hát még hader modell 4 vagy 5-ös kártyákról és nem melleseleg elég csúnyácskának számítanak 2012 es viszonlatba… persze hogy nem használja ki 4 magot meg 50% nem eszi jobbban a vidókártyát… régi mmokból én is futtatam akár 3-4 klinest is egyszerre a gépen mégnem is akadt… mert kb 10 éves fejlesztés mind.

    Amúgy megnéhetsz bármilyen játékor ami támogatja a több magot lásd crysis2 ki is használja ha olyan szintű grafikára éllítod és megfeleő videókártya van mellette.. értem én kihasználás alat hoyg pl két magnál mind a 2 80-90% felett van nem beszélve vagy a queadok is 80+80+80+60 on vannak egy többmagot támogató programnál win7 64 biten
    Szóval a gw2 minden csak nem használ ki 2 nél többet rendesen. tehát totál feleslegesen vennél i7 et elég egy “mezei” Q9550 is :D ha felhúzod 4GHZ re menni fog minden mert nincs még olyan program szinte (tesztprogramon kívül) ami kihasználna 6-8 magot nem beszélve a HT ről nah jó persze a bépített cahst meg memóriavezérlő és DDR3 miatt előnye van a i7 nek de nem a magok/szálak miatt.. annak hoyg 12-16 szálat tudjon használni egy játék még kell 2-3 év és abból sem az MMOk lesznek sajnos az elsők. Azoknak valahogy nem fejlesztik annyira a motorját…

    Pedig szerintem semmiből nem állna mondjuk egy HD Textúra packot kiadni az Aionhoz vagy tudom is én bármit. csak ne azt nézzem 3 évmulva is mint most fejlődést szeretnék látni nem csak pénz belapátolást a vitrinbe mint sok fejlesztő teszi (tiszteleta kivételnek). vagy lecserélhették volna a cryengine1-et 2-re 3.0-ra vagy 3.5-re(ami koreában van) de semmi. az össze amit tettek hogy betettek egy ki hdr + antaliasing kombót 2.5 be azt kész, jah és benyomtak 2 használható mapot a többi mellé… (azért kettőt mert ezt hausing témát én viccnek tartom)…Ott is úgy kellett a koreai klienből kilopni a 64bites indító részeket mert minket itt euban nem szántak meg ilyennel

    Mindegy remélem az Anet fejleszteni fog és nem csak ülés lesz a babérokon és mellébeszélés fórumon mint sok eddigi (máshol szerzett) tapasztalatom muttatta hoyg lenni Szokott. Talán egy-két hónap múlva ez grafikai hiba is csak egy lesz sztorik közül. talán valahol… az óperenciás tengeren is túl… a nyúlon túl… :D

  36. Bracus
    2012. augusztus 18. - 07:29

    Na “elvileg” hamarosan kijön az új nvidia driver, amivel “elvileg” gyorsulni fog pár nvidia kártya:

    http://www.guildwars2guru.com/topic/48375-best-nvidia-geforce-driver-for-gw2/page__st__120

    Már most is van, de egyenlőre csak az új 660Ti-hez érhető el. Egy kis hack-kel működik más kártyáknál is, de szvsz nem érdemes még. Ha esetleg lesz még stressz teszt vagy megjelenés előtt nem adják ki az új drivert, akkor kipróbálom ezt és postolok pár adatot.

    • csigusz
      2012. augusztus 18. - 07:32

      És ATi? :_( Brühühü… Nálam jól futtott a játék de azért lelki megnyugvás lenne az a pár százalék javulás. :D

      • Bracus
        2012. augusztus 18. - 07:42

        Én is így vagyok vele, azon szerencsések közé tartozom, akiknél jól futott a játék, nem is magam miatt linkeltem főleg, de azért várom én is, hogy kipróbálhassam.

  37. csigusz
    2012. augusztus 18. - 08:21

    Sokaknál volt probléma AMD Radeon HD6670 kártyatipussal. Tehát akinek ilyen TURKS magos kártyája van és észlelte a problémát, írjon ANetnek! Több sírás – nagyobb esély, hogy hamarabb javítják! De senki ne legyen rest, akinek gondja volt ÍRJON. Interneten keresztül még senkit nem ettek meg, ha jól tudom…
    (Amennyiben ilyen kártyád van és nem találkoztál a hibával írj ide, hogy mások okulhassanak!)

    A levél/fórum hozzászólás tartalmazza:
    Pontos hibaleírás
    Oprendszer neve, tipusa, utolsó frissítés dátuma
    DXDiag-ból kiolvasott directX verzió (ha megtaláljátok a dx9 utolsó dátumát az lenne az igazni)
    Pontos hardver specifikáció
    Netkapcsolat
    Párhuzamosan futó programok

    Pl.:
    Hi experts,

    I had experienced massive fps lag everywhere during the BETA test.

    Operating system: Microsoft Windows 7 Professional 64-bit last update 2012.08.25
    DX9 version: SDK version 2009 October (nekem fejlesztőkörnyezet miatt SDK van telepítve, nektek valószínűleg újabb)
    CPU: AMD Athlon II X2 235e
    Motherboard: Gigabyte MA770T-UD3P (with no bios update)
    Videocard: Sapphire AMD Radeon 5770 1Gb
    Soundcard: ASUSTek Xonar DX (ez persze opcionális, ha van írd le)
    RAM: 2x2Gb DDR3 1600 SAMSUNG
    (merevlemez nem kell)

    Internet connection: 5/1 Mbs ADSL

    In the background Skype client and TeamSpek3 client were running.

    (És legyünk rendesek!)
    Thanks in advance,
    A player

    • csigusz
      2012. augusztus 18. - 08:25

      Kifelejtettem, hogy ha van bármilyen printscreen-ed, log-od, azt is csatold!

  38. Nasser
    2012. augusztus 18. - 10:28

    Menorel, köszi a cikket! Sajnálom, hogy nem jössz GW2-re. A Variance név nekem szervesen összefonódott a neveddel. :) (Aki nem tudná, Meno vezette az AION Variance légiót. Professzionális vezetőt, kiváló stratégát és nem mellesleg baromi segítőkész embert ismertem meg benne.)

    Nem nagyon akartam eddig hozzászólni ehhez az FPS hajcihőhöz. Win7(64), 4G mem, NVIDIA GTX570, Core 2 Duo 2.8, 1920×1028-as felbontásban mentem az összes BWE-n. Minden alkalommal változó volt a teljesítmény, a grafikát inkább minimum-közép beállításokra raktam. Nem voltam elégedett a teljesítménnyel. Játszható és folyamatos volt végig, de pl. mikor fordultam egy kicsit mintha később mozdult volna a kép. Vagy tettem egy lépést előre és a semmiből hirtelen előtűnt a tömeg az orrom előtt. Nem baj, ez még béta, várjuk meg a véglegest mondogattam magamnak. A kis ördög viszont nem hagyott nyugodni, régi a procid haver, cseréld le. Ezt is tettem. Az utolsó teszteken egy i7 hajtotta a szekeret. Ég és föld amit tapasztaltam. Maximum grafikán is sima és gördülékeny minden. (Más játékokban is hatalmas minőségi változást hozott a proci a csere.)

    Az utolsó teszt végén, amikor Divinity-ben a waypointon nyüzsgött mindenki és tolta az efekteket ezerrel, folyamatosan és akadás mentesen rohangáltam, ugráltam körbe-körbe. Tökéletesen irányítható volt a karakter, minden mozdulatra azonnal reagált. Szándékosan nem írtam FPS számokat eddig. Itt a tömegben megnéztem, 25-35 FPS körül mozgott.

    Mire akarok kilyukadni ezzel? Egy hasonlattal élve: a női élvezetre nincs hatással a szerszám mérete. Kivéve, ha túl kicsi. Ha a MEGJELENÉS UTÁN is tapasztaltok teljesítmény problémát és van rá keret, érdemes elgondolkodni egy erősebb proci vásárlásán, lehet a Core2 kevés lesz. Mondom a MEGJELENÉS UTÁN. Valószínűleg i7 sem kell, én hosszú távra vettem ezt. A másik dolog pedig, hogy nem kell 100 FPS a jó játék élményhez.

    A legjobbakat, Nass alias Brigitta (AION).

    • csigusz
      2012. augusztus 18. - 10:36

      Meg lehet kérdezni, milyen i7-es procit szereztél be? Mert ha nálad jól vitte a játékot, akkor valószínűleg picivel alatta is hasonló élményt fog nyújtani, ha megjelenés után valakinek sajnos procira kell áldoznia ez is nagy segítség lehet.

      • Nasser
        2012. augusztus 18. - 10:41

        i7-3770 @ 3.40 GHz

  39. Geri
    2012. augusztus 18. - 12:19

    Akadnak itt hozzá értő emberkék, mit gondoltok egy laptop processzor cseréjét illetően ?
    Olvastam olyat h körültekínttően lehet cserélni minden probléma nélkül , olvastam olyat is h abszolút nem éri meg mert tuti h baj lesz csak vele. Véleményetek szerint ?

    • csigusz
      2012. augusztus 18. - 12:38

      Szia, ha nem vagy jártas ilyesmiben ne tedd. Procit nem nehéz cserélni, csak gondok lehetnek hűtéssel, mert ugye más procihoz méretezték. Szervízt tudnék ajánlani, kicserélik a processzort egy általad választottra persze munkadíjért cserébe. De ha probléma adódik gariban megcsinálják. Jobban jársz, mintha elfüstölne.

    • csigusz
      2012. augusztus 18. - 12:50

      Ha nem értesz hozzá, ne cserélj semmit! Processzort biztos latopban sem nehéz cserélni, viszont hűtéssel lehetnek gondok, mert azt az adott procihoz tervezték. Szervízben érdemes utánajárni ők mit javasolnak fejlesztésnek, dobj valamelyik bolt szervízének egy emailt, hogy milyen laptopd van és mit szeretnél cserélni, és mennyiért csinálnák meg ők. Munkadíj nem lehet olyan sok, és ha bedöglik a gép garanciában megcsinálják, nem pedig vehetsz új gépet.

  40. 2012. augusztus 18. - 12:25

    Kozzy és csigusz: Szerintem inkább hagyjátok a fentebbi vitát. Kb a vita 20%-át olvastam át de már abban is sok sületlenség volt.
    Egyetlen dologra reagálnák: Jómagam azon kevés ember közé tartozok, akik kis hazánkban részt vettek windows kernel/filter driver fejlesztésben. Ezt nem azért mondom, mert ettől mennyire hű de fasza gyerek vagy, hanem csak tisztázni akartam, hogy nem légből kapottak az információim. Hogy a call stack hasztalan információ? Nos ezzel messze nem értek egyet. A Call stack nem azért fontos, mert attól majd jól látszani fog, hogy hol a hiba, hanem azért, mert ugyanannak a syscall-nak a call stackje két különböző gépen két totálisan más pathot járhat be. Hogy miért? A válasz roppant egyszerű: Dll injection és/vagy kernel filter driver. Egy rosszul megírt vagy inkompatibilis grafikus overlay szoftver (legyen az akár csak egy FPS mutató vagy bámilyen egyéb szoftver pl. keyboard macro tool) igen komolyan befolyásolhatja egy-egy syscall stackjét. Ugyanez igaz pl. a filesystem filterekre, vagy akár az userspace DRM filterekre. Az ArenaNet ha akarná sem tudná összes létező ilyen szoftverrel tesztelni a programját, hiszen ez nonszensz elvárás.
    Hogy mi az értelme egy ilyen call stacknek? Ha pont jókor kapod el (márpedig egy 100%-on WaitFor-ban álló threadnél ez nem kizárd…), akkor egy igen mély call stacket fogsz kapni, amiben ott fog figyelni a kérdéses filter/injector alkalmazás is. Ez nyilván szemet fog szúrni a bugreportban is és vissza fognak kérdezni hogy pl. mi a franc az a GNInject.dll vagy FSfilter.sys. Majd egy-két iteráció után mikor kiderül, hogy mi az a kérdéses filter/injector, akkor az ANet is ki tudja tesztelni és rá tud jönni, hogy a kérdéses cucc miért is akasztja be kéretlenül az adott threadet.
    Mindez nem légből kapott, volt szerencsém nem egy hibát úgy debugolni anno, hogy az ügyféltől (kérésre) kapott forcelt crash dump vagy procexp call stack-ben ott figyelt egy olyan filter, amivel nem kicsit került a saját filter driverünk inkompatibilitásba.

    • csigusz
      2012. augusztus 18. - 12:46

      Sok sületlenség azért nem volt. De egyrészt elbeszéltünk egymás melett, másrészt megvitattuk, hogy nem itt kéne. Mert visszanézve tényleg sokat írtunk nem idevalót.

      Esetleg indulás után is tervezel egy hasonló blogbejegyzést, ahova majd mindenki beírhatja élesben hogy megy neki a játék, esetleg milyen konfigon?

      • 2012. augusztus 18. - 12:55

        Továbbra is fél szemmel követem a GW2 világát és ha úgy látom, hogy tudok bármilyen értékes/értelmes hozzászólást eszközölni akár post akár comment szinten akkor megteszem. Ennél jobban nem kívánom feszegetni az aktív bloggerek szuverenitását :)

    • Kozzy
      2012. augusztus 18. - 13:31

      Ha tényleg visszaolvasol én úgy gondolom egyszer se írtam hülyeséget. Túlzásba vittem egy vitát valóban, és többször elbeszéltünk egymás mellett. Amúgy szerintem te kezdted túl bonyolítani a dolgot ezzel a cikkel…
      Felesleges CPU terhelés vizsgálatokat végezni amikor azzal kb semmi baj nem volt. (legalábbis senkit se láttam arra panaszkodni) Én értem hogy segíteni akarsz, és ez tök jó. Én is azt akartam amikor a “vitát” kezdtem csak kicsit más irányba haladt. De mint már mondtam is leginkább a VGA használat és a beállítások voltak amik aggasztották az embereket.
      Erre írsz 1 cikket amivel kb az ilyen téren 99%-ban amatőr játékosok lelkét próbálod “vigasztalni”. Mert ezzel kb azt érted el. Az esélye hogy valaki ezen útmutató alapján kiszúrt valami hibásat a rendszerében (és meg tudta oldani a problémát) közelíti a nullát. Arra építetted az egész elméleted hogy van valami hibás szoftver a rendszerünkben. De ez akkor más játéknál is valószínűleg kibukna. Ha csomó más alkalmazás jó és ez nem akkor nem valószínű hogy a saját konfigurációdban kell keresned a hibát.
      Akinek CPU/akármi problémái vannak alapdolog hogy új driver-eket rak fel, és a háttérben nem futtat semmit. Ahogy tették is itt sokan, ennél sokkal többet egy egyszerű játékos nem tehet. És így is “szar” volt. Azaz ami kapsz reportot az esetek kb 99,99%-ában semmi különöset nem fogsz találni, ha igen se biztos hogy egy egyszerű játékos ezt észre is veszi. Ha lenne valakinél hasonló probléma más játékban is valószínűleg kiderült volna.
      Ha mégis kizártnak tartom hogy ha küldesz 1 ilyen report-ot a supportnak akkor ez tovább jut a megfelelő helyre. (a support-nál se ülnek guru-k, többnyire csak az egyszerűbb nem egyedi problémákra fognak értelmesen válaszolni, pl képzelj el egy upc vagy t-home support-ot :) ). Egyedi problémákkal nem fognak több százezres létszámnál foglalkozni. Ha valami olyan szoftver/driver okozza a hibát amit nem ők csináltak akkor meg főleg nem fognak neked segíteni. (persze lehetnek kivételek) Ha náluk (ANet) lenne valami probléma ilyen téren akkor azt ők már jóval a sima user-ek reportja előtt tudják.
      Téged idézlek :
      “ArenaNet ha akarná sem tudná összes létező ilyen szoftverrel tesztelni a programját, hiszen ez nonszensz elvárás.”-valóban így van, pont ezért nem fognak neked “külső” szoftver által okozott hibákkal foglalkozni. Ez leginkább a “külső” szoftvert gyártó dolga.
      Amúgy meg ha már jobb teljesítmény analízist akartál volna nyugodtan megadhattad volna az Intel VTune-t, vagy az AMD CodeAnalyst-et. Sokkal jobban, egyszerűbben lehet egy ilyen problémát látni azokban. Ezeket a szoftvereket hasonló helyzetekre csinálták. És szerintem a Process Explorer féle stack report túl primitív és kevés adatot tartalmaz (gyakorlatilag csak egy hívás lista) hogy kezdjenek is vele valamit. Amúgy meg respect jó cikk, csak szerintem gyakorlatban nem sokat segít (ahogy a “vitánk” se..)

    • 2012. augusztus 18. - 16:37

      Az a baj, hogy görcsösen ragaszkodsz ahhoz, hogy ez a post a GW2-ről szól, pedig arról nem szólhat, hiszen én nem értek a GW2-höz. Sőt nem látok bele az ANet supporting folyamataiba, így nem tudom megítélni, hogy vajon mire mennyire erőforrást költenek. A postban megpróbáltam néhány általános érvényű alap ötletet (is) megosztani, ami lehet hogy segítség lesz néhány embernek. Egy blog valahol erről szól, én leírtam a témával kapcsolatban a tapasztalataim mivel ez éppen itt és most aktuálisnak tűnt, majd végig olvastam a közel 150 hozzászólást (+ a kimoderált raszista ömlengéseket is…), ezek egy részé számomra is új dolgokat tartalmazott, melyekből tanultam. Nekem ezért márt megérte és remélem annak a másik 2556 lapletöltés gazdájának is,akik belenéztek ebbe a postba :)

      • Kozzy
        2012. augusztus 18. - 16:56

        No offense, tényleg semmi bajom veled, se post-al, és amit leírtál mind igaz és kb kétségbe vonhatatlan.
        Anno a TERA oldálán is olvastam a postjaid (játszottam is), és “bírtam” a stílusod. Bocs ha 1-2 mondatban a kelleténél rosszabb hangvételű a stílusom, de többnyire igyekszem a tényeknél maradni. Remélem igazad van, és volt akinek a gyakorlatban is segített valamit a post-od. Peace.

  41. Geri
    2012. augusztus 18. - 16:05

    Valaki megvilágosítana , hogy az alaplapom CPU foglalatát hol tudom megnézni ?:D
    egyébként egy K52J szériás asus laptop akinek esetleg ez segít :D

    • Kozzy
      2012. augusztus 18. - 16:22

      Elvileg mobile i-3 vagy i-5 van a gépedben, akkor pedig ez:
      http://en.wikipedia.org/wiki/Socket_G1

    • csigusz
      2012. augusztus 18. - 17:58

      Foglaltra rá szokták írni a foglalat nevét.
      Ahogy Kozzy írta socket G1.
      A gyártó honlapján a specifikációk alatt fel van tüntetve néhány processzor tipus.
      Ha választasz onnan válassz, mert nagyobb eséllyel fogkan jól működni, mint a nem felsoroltak.
      http://www.asus.com/Notebooks/Versatile_Performance/K52JC/#specifications

      Ettől függetlenül én azt javaslom processzor bővítéssel várd meg a start utáni első hetet legalább, amíg a debug részeket kiirtják a kliensből. Nagyobb procihoz pedig erősebb hűtés is kell, ezen is érdemes filózni. Most mennyire melegszik, van-e hozzá laptophoz kapható külső hűtés, stb…Habár a gyártó oldaláról van az információ, és szerintem egy családon belül nem alkalmaznak más hűtési eljárást, azért én mindenképpen írnék egy szervíznek, az érdeklődés még nem kerül pénzbe.

      Nem írtad meg milyen a mostani processzorod, lehet nem érdemes fejleszteni a laptopot, ha a bele szánt processzorok közül valamelyik erősebb van benne.

      Remélem sierkült megvilágosítani! :-D

      • Geri
        2012. augusztus 18. - 18:31

        Köszönöm a válaszokat , természetesen megvárom a startot de sajnos jelenleg egy Intel® Pentium® P6100 as van benne 2 magos 2 Ghz es ami ugyan épp elég lenne , de erre most nem sok esélyt látok videókártya és ram viszont elég, csóró egyetemista vagyok az asus garancia épp lejár lassan szóval annak már nem árt :D így a proceszor csere tűnik csak megoldásnak , köszi még egyszer a segítséget
        Még lehet majd zargatlak vele titeket itt :D ha olvassátok ezt rendszeresen ..pl i3 as vajon elég lenne a game nek vagy az i5 ösre jobban megérné (azokra gonolok amik a specifikációs linkben vannak) :D … ilyesmivel , de majd ha aktuális lesz :P

  42. Tamás
    2015. április 20. - 21:22

    Hazsnos cikk, bár számomra még mindig érthetetlen, hogy egy erős vason miért hullik az fps-em 0-3-ra nagyobb tömegnél (50-60fő fölött). Alaphelyzetben megvan a 60fps, viszont egy worldbossnál már képregény.
    (xeon 5470@4.0, 8GBram és HD6990). És az erőforrások felét se nagyon használja ki…
    ssd-ről fut a program, szóval az sem lehet szűk keresztmetszet.
    proci 30-40% minden magon, 2 gpu is aktív 50-70% között.

    • 2015. április 21. - 02:39

      60-ról 0-3 FPS tényleg nagyon sok. Viszont a Xeonról desktop alkalmazásoknál elég rosszakat hallottam. Szerverként hasít, de Win7 és Win8 alatt mostanában mesélte egy ismerősöm, hogy 12 Xeon magot vágott kukába és cserélt egy i7-re, mert elege lett abból, hogy renderelni sem tudott elfogadható sebességgel, miközben a load mégsem ment 30-50% fölé. Nem játékra használta, csak videó és grafikai utómunkákat akart renderelni vele, és az elméletben leggyorsabb gépet rakatta össze valami lehetetlen összegért.

      A model limitet és minőséget próbáltad low-low, low-lowest vagy lowest-lowest beállításokkal tömegben? Annál is így esik az fps-ed?

      Esetleg a shaders low beállítással is mehetne próbaként, ha még nem nézted azzal együtt az fps-ed.

      Lehet, hogy csak egyetlen beállítás okozza. WvW-n is könnyű tesztelni tömegben ezeket.

  1. No trackbacks yet.

Itt és most várjuk a hozzászólásod!

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: