Колко рамки създава вашият компютър в темата Show Cologne-Koblenz Show; Форум на Zusi
Всички часове са UTC + 1 час
Колко кадъра управлява вашият компютър в Кьолн-Кобленц ?
.
Има ли някакъв начин да преброите връзките в ls файловете, това е малко досадно на ръка.
Тогава можех да видя колко файла са свързани общо в модулите ls. Но грубо се изчисляват няколкостотин (парапети, елементи на контактната мрежа, маркировка на платформата и т.н.).
Веднъж бях предложил нещо подобно, когато управлението на обекти в Zusi имаше своя ход, а именно да се приложи управлението на връзките съответно в маршрута ED, отговорът от Carsten беше много ясен.
За мен винаги е между 15 и 25 fps.
(2.7 Ghz, графична карта: какво да знам (компютърът е от май 2003 г.)
По всички останали маршрути съм нормален при 40 fps, само че с Kö-Ko пада
честотата на кадрите по-ниска
(Това вероятно се дължи на добрия пейзаж; почти си мислите, че пейзажът е откраднат от друга игра)
Последна промяна от Марсел Темплин на 31 май 2004 г. 19:07:12, променена общо 1 пъти.
И така, сложих интегрираната версия на сървъра, можете да я намерите тук.
Предупреждение: частта е с размер 16 MB (16 873 794 байта).
За съжаление не става по-малък. Трябва също да отбележа, че историята иска 140MB дисково пространство.
Веднъж тествах интегрираната версия на компютъра си и не открих никаква разлика. Честотата на кадрите са абсолютно еднакви и за двете версии. Б. 10 в Köln Hbf и 18 на входния сигнал Kalscheuren. Защо може да е така.
Моята система: P 4 с 2 GHz, Windows XP, 512 MB RAM, графична карта 64 MB NVIDIA GeForce 3 Ti 200, 4 x AntiAliasing, 1024 x 768. Настройка: изглед 2400/2400.
С интегрираната версия получавам спирани 40 кадъра навсякъде. Работи чудесно.
@Stefan: Благодаря за усилията.
@Holger: Може би сте копирали нещо грешно или друг str файл, така че старият файл все още да се използва?
Увеличението на FPS всъщност работи чудесно. Само резултатът.
Компютърът ми прави рязко движение на всеки 200 метра, което е най-силно в Кобленц. Поглед към системната информация показва, че това вероятно се дължи на моя HDD. Защото суап файлът е горд 650MB по този маршрут. Въпреки че разполагам с 512 MB 266-DDR RAM. Защо така?
По принцип използвах метода на Стефан, но заредих "* _AllLS-Dateien.ls" в редактора на сградата, интегрирах свързани файлове и ги запазих отново. (Отива за нула време.)
С (досега) 384 MB основна памет нямаше да бъде спечелена саксия, тъй като пейджингът продължаваше. От тук вероятно идва заекването на Патрик. (Погледнете светодиода за твърдия диск - той трябва да е предимно тъмен.)
След това дадох на стария си ренде (PIII, 850 Mhz) още 512 MB памет. С сега 768 MB получавам около 19 fps в Кьолн, почти 30 fps в Бон и почти 40 fps в открития път. Необходимо е обаче намаляване до 14 кадъра в секунда (в Кьолн) или 24 кадъра в секунда (в противен случай), за да се избегнат типичните шумове (здравей, Майкъл) EDIT: Звукът е на борда при мен.
В края на пътуването от Кьолн до Кобленц честотата на кадрите спадна до 2 кадъра в секунда, каквото и да е това. (Да видим дали случаят е такъв при всяко пътуване.)
Последна промяна от Christian Gründler на 06/01/2004 17:32:51, промяна общо 1 пъти.
Под Windows различните инструменти правят различни изявления за това колко голяма е необходимата виртуална памет, тъй като инструментите използват различни имена.
Но сега успях да взема решение на мнозинството.
Според инструкциите на Стефан интеграцията и почистването на маршрута след зареждане на маршрута без график ме изисква под XP с 768 MB основна памет:
- работен комплект от 393720 KB с максимум 414828 KB по време на зареждане;
- общ виртуален размер от 926408 KB с максимум 1208484 KB по време на зареждане, от които 390676 KB са частни за процеса, не могат да се споделят.
Така че, ако изчислявате само частните страници (които Task Manager също показва като "виртуална памет", ако желаете), тогава приблизително същият размер се съхранява във файла на страницата в допълнение към пребиваващата памет.
Следователно бих предположил, че ще има сериозни проблеми при суап с 512 MB памет.
В крайна сметка решението може да се крие само в отделната технология за зареждане на модули, предоставена от Carsten. Дотогава човек може да се задоволи с брутална сила, разбира се, която не е чиста или елегантна.
Карстен написа:
Изтеглих отново интегрираната версия, нищо не се е променило. Дадох на пълния "стар" файл с маршрути различно име. По този начин интегрираната версия е на компютъра като отделен файл. За съжаление това не може да е причината.
Не бих нарекъл трансформацията от свързан към интегриран пейзаж „брутално насилие“. И когато смятате, че достъпът до диска при пейджинг забавя цялото нещо, аз се питам, разбира се, дали планираното презареждане на секциите на пистите също би довело до дръпване .
Последна промяна от Christian Gründler на 06/01/2004 20:14:35, променена общо 1 пъти.
Експериментите миналата година показаха, както Карстен отново посочи, че много големи или много малки мрежи се представят по-малко ефективно от тези със среден размер. Въпреки това, без обединяване на .ls файловете, в момента е практически невъзможно да се създадат значими големи мрежи за многото малки 3D модели като напречни структури и други подобни. Това се купува на цената на по-големи изисквания за паметта не само във файловете, но и по време на изпълнение на мрежите, тъй като спестяващото предимство при трансформиране на малката мрежа на правилните места (множествено число) само в момента на изобразяване.
Само заключението за съкращаване, което би се получило от това, не би било правилно, че ще трябва да се купува по-висока честота на кадрите с повече изисквания за памет. В момента това е де факто - ако приемем подходяща графична карта - но няма неизменна причина за това. Различен модел за съхранение - ключова дума: зареждане по модул - ще намали значително изискването за съхранение отново, без да се налага да се отказвате от оптималните размери на окото.
Оттук и коментарът ми за „брутално насилие“: Включването на ls файловете в момента струва памет. Затова използвайте лост, за да стиснете в паметта, докато вече не е възможно. Това работи, но отново става излишно с въвеждането на нов модел памет.
Може да се дължи и на графичния драйвер. Особено при nVidia има съобщения за ефекти, че честотата на кадрите не е постоянна при различните версии на драйверите. Сглаждането може да има друго влияние.
Мога да потвърдя повишенията на производителността, споменати в тази нишка, чрез интеграция ls за драйвер 53.03, с изключен анти-псевдоним. С текущата версия 56.72 обаче нищо не ми се случи. (Моля, не надценявайте резултата. Възможно е да има конкретни причини, освен номера на версията, защо новият драйвер не е бил прав.)
също е официално документиран в дълбините на страниците на nvidia.
Между другото, възможността за създаване на ефективни размери на окото ще намалее с Zusi 3 (тъй като 2 различни текстури винаги се нуждаят от две различни мрежи). Въпреки това трябва да е възможно да се компенсират тези недостатъци в този wg. динамично натоварване означава, че трябва да се изчисли значително по-малко пейзаж.
Разбира се, зареждането също струва производителност, но няма друг шанс. Надявам се, че дърпането няма да бъде забележимо, само че честотата на кадрите спада при зареждане.
И така, работих усилено и вчера вечерта. Моят малко по-стар GF 2 Ti също постига значително увеличение по принцип, с моя 700Mhz състезател в Кьолн получавам около 15-16 fps вместо предишните 7 fps. Но и за мен проблемът с дърпането има много сериозен ефект само с 448 MB RAM, остарелият ми W98 все още действа като допълнителна забавна спирачка. Е, докато новото закупуване на хардуер вече не е планирано, първо ще изгладя старата версия, която поне постоянно работи на ниско ниво.
Всички часове са UTC + 1 час
кой е на линия?
Членове във този форум: 0 членове и 1 гост