Hány keretet hoz létre számítógépe a Cologne-Koblenz Show témában; Zusi fórum

Minden idő UTC + 1 óra

létre

Hány keretet kezel a számítógépe Köln-Koblenzben ?

.
Van-e valamilyen mód arra, hogy megszámoljuk az ls fájlok linkjeit, kézzel kissé unalmas.
Akkor láthattam, hogy az ls modulokban összesen hány fájl van összekapcsolva. De nagyjából becslések szerint több száz (korlátok, felsővezeték-alkatrészek, peron jelölések stb.).

Valami ilyesmit javasoltam, ahol a zusi objektumkezelésnek meg kellett lépnie, nevezetesen a linkkezelés ennek megfelelő megvalósításában az ED útvonalon, a Carsten válasza nagyon világos volt.

Számomra ez mindig 15 és 25 kép/mp között van.
(2,7 Ghz, grafikus kártya: mit tudok (a számítógép 2003. májustól származik)

Az összes többi útvonalon normál vagyok 40 kép/mp sebességgel, csak a Kö-Ko-val csökken
alacsonyabb a képkockasebesség

(Valószínűleg a jó táj miatt; szinte azt gondolja, hogy a tájat ellopják egy másik játéktól)

Utoljára Marcel Templin módosította 2004. május 31-én 19:07:12, összesen 1 alkalommal változtatta meg.

Tehát az integrált verziót feltettem a szerverre, itt megtalálhatja.

Figyelem: az alkatrész mérete 16 MB (16 873 794 bájt).

Sajnos nem lesz kisebb. Azt is meg kell jegyeznem, hogy a történet 140 MB lemezterületet kíván.

Egyszer teszteltem az integrált verziót a számítógépemen, és egyáltalán nem találtam különbséget. A képkockasebesség mindkét verziónál teljesen megegyezik. B. 10 a Köln Hbf-ben és 18 a Kalscheuren bejárati jelzésénél. Miért lehet az.

Saját rendszer: P 4 2 GHz-es sebességgel, Windows XP, 512 MB RAM, grafikus kártya 64 MB NVIDIA GeForce 3 Ti 200, 4 x AntiAliasing, 1024 x 768. Beállítás: 2400/2400 nézet.

Az integrált verzióval mindenhol megkapom a fékezett 40 keretet. Csodálatosan működik.

@Stefan: Köszönöm a fáradságot.

@Holger: Lehet, hogy valami rosszat vagy egy másik str fájlt másolt át, így a régi fájl továbbra is használatos lesz?

Az FPS növekedés valóban csodálatosan működik. Csak az eredmény.

A számítógépem kb. 200 méterenként rángatózó mozgást végez, ami Koblenzben a legerősebb. A rendszerinformációk áttekintése azt mutatja, hogy valószínűleg HDD-jemnek köszönhető. Mivel a cserefájl büszke 650 MB-os ezen az útvonalon. Annak ellenére, hogy 512 MB 266 DDR RAM-mal rendelkezem. Miert van az?

Elvileg Stefan módszerét használtam, de betöltöttem a "* _AllLS-Dateien.ls" fájlt az épületszerkesztőbe, integráltam összekapcsolt fájlokat és elmentettem őket. (Nincs idő.)

(Eddig) 384 MB fő memóriával nem volt virágcserép nyerhető, mert a lapozás folyamatos volt. Valószínűleg onnan származik Patrick dadogása. (Vessen egy pillantást a merevlemez LED-jére - többnyire sötétnek kell lennie.)

Aztán a régi gyalumnak (PIII, 850 Mhz) adtam egy újabb 512 MB memóriát. Most 768 MB-mal kb. 19 kép/mp sebességet kapok Kölnben, majdnem 30 kép/mp sebességgel Bonnban és majdnem 40 kép/mp sebességgel a nyílt úton. Szükség volt azonban 14 fps (Kölnben) vagy 24 fps (egyébként) csökkentésére a tipikus hangrángások elkerülése érdekében (helló Michael). EDIT: A hang velem van.

A kölni és a koblenzi út végén a képsebesség 2 kép/mp-re csökkent, bármi is legyen az. (Lássuk, minden utazás esetében ez a helyzet.)

Utoljára Christian Gründler változtatta meg 2004.01.01. 17:32:51, összesen 1 alkalommal változtatott.

A Windows alatt a különböző eszközök különböző kijelentéseket tesznek arról, hogy mekkora a szükséges virtuális memória, mivel az eszközök különböző neveket használnak.

De most sikerült többségi döntést hoznom.

Stefan utasításai szerint az útvonal integrálásához és megtisztításához, miután az útvonal menetrend nélkül lett betöltve, XP-nél 768 MB-os fő memóriával kell rendelkeznem:

  • 393720 KB, maximum 414828 KB munkakészlet betöltés közben;
  • teljes virtuális méret: 926408 KB, betöltés közben legfeljebb 1208484 KB, ebből 390676 KB folyamat-magán, nem osztható meg.

Tehát, ha csak a privát oldalakat számolja ki (amelyeket a Feladatkezelő "virtuális memóriaként" is megjelenít, ha szükséges), akkor nagyjából ugyanolyan méretet tárol az oldalfájl a memóriaterületen kívül.

Ezért feltételezem, hogy komoly csereproblémák lesznek az 512 MB memóriával.

Végső soron a megoldás csak a Carsten által biztosított egyedi modulok töltési technológiájában található meg. Addig brutális erővel lehet boldogulni, természetesen ez nem tiszta vagy elegáns.

Carsten ezt írta:

Újra letöltöttem az integrált verziót, semmi sem változott. A teljes "régi" útvonalfájlnak más nevet adtam. Az integrált változat tehát külön fájlként van a számítógépen. Sajnos ez nem lehet az oka.

Nem nevezném "brutális erőszaknak" az összekapcsoltról az integrált tájról való átalakulást. És ha figyelembe vesszük, hogy a lapozáskor a lemezelérés lelassítja az egészet, akkor természetesen azt kérdezem magamtól, hogy a sávszakaszok ütemezett újratöltése is rángatózást eredményez-e? .

Utoljára Christian Gründler változtatta meg 2004.01.01. 20:14:35, összesen 1 alkalommal változtatott.

A tavalyi kísérletek kimutatták, amint arra Carsten ismét rámutatott, hogy a nagyon nagy vagy nagyon kicsi szemek kevésbé hatékonyan kerülnek előállításra, mint a közepes méretűek. Az .ls fájlok egyesítése nélkül azonban jelenleg gyakorlatilag lehetetlen jelentõsen nagy hálókat létrehozni a sok kicsi 3D modellhez, például keresztirányú struktúrákhoz és hasonlókhoz. Ezt nemcsak a fájlokban, hanem a hálózatok futásidejénél is nagyobb memóriaigény mellett vásárolják meg, mivel a memória-megtakarítás előnye, hogy a kis hálót a renderelés pillanatában megfelelő helyre (többes számba) transzformálja, elveszett.

Csak az ebből adódó rövidítési következtetés nem lenne helytálló, hogy magasabb képkockasebességet kellene vásárolni, több memóriaigénnyel. Jelenleg ez tényszerűen - megfelelő grafikus kártyát feltételezve -, de ennek nincs megmásíthatatlan oka. Egy másik tárolási modell - kulcsszó: modulonkénti betöltés - ismét jelentősen csökkenti a tárolási igényt anélkül, hogy az optimális hálóméretekről lemondanánk.

Ezért a "brutális erőszakkal" kapcsolatos megjegyzésem: Az ls fájlok beépítése jelenleg memóriába kerül. Szorítsa hát az emlékezetbe, amíg a feszítővassal már nem lehetséges. Ez működik, de új memóriamodell bevezetésével ismét feleslegessé válik.

Ennek oka lehet a grafikus illesztőprogram is. Különösen az nVidia esetében többször is beszámoltak arról, hogy a különböző illesztőprogram-verzióknál a képkockasebesség nem állandó. Az elhallgatásnak más hatása lehet.

Megerősíthetem az ebben a szálban említett teljesítménynövekedést az 53.03 illesztőprogram integrálásával, kikapcsolva az aliasing funkciót. A jelenlegi verzióval 56.72 azonban semmi nem történt velem. (Kérjük, ne becsülje túl az eredményt. A verziószámon kívül különféle okok is lehetnek, miért nem volt igaza az új illesztőprogramnak.)

az nvidia oldalainak mélyén hivatalosan is dokumentálva van.

Egyébiránt a hatékony hálóméretek létrehozásának képessége csökkenni fog a Zusi 3-mal (mivel 2 különböző textúrához mindig két különböző hálóra van szükség). Lehetővé kell tenni azonban e hátrányok kompenzálását abban a wg-ben. A dinamikus terhelés azt jelenti, hogy lényegesen kevesebb tájat kell kiszámítani.
Természetesen a töltés is teljesítménybe kerül, de nincs más esély. Remélem, hogy a rángatózás nem lesz észrevehető, hanem csak az, hogy a képkockasebesség csökken a betöltéskor.

Szóval keményen dolgoztam tegnap este is. A valamivel régebbi GF 2 Ti-m is elvileg jelentős növekedést ér el, a kölni 700 MHz-es versenyzőmmel 15-16 fps körüli sebességet kapok a korábbi 7 fps helyett. De számomra is a rángatózó problémának nagyon komoly hatása van, mindössze 448 MB RAM-mal, az elavult W98-asom pedig további fékként hat a szórakozásra. Nos, amíg az új hardver vásárlást már meg nem tervezik, először a régi verziót vasalom át, amely legalább állandóan alacsony szinten fut.

Minden idő UTC + 1 óra

Ki van bejelentkezve?

Tagok ebben a fórumban: 0 tag és 1 vendég