Скільки кадрів створює ваш ПК у темі шоу Кельн-Кобленц; Форум Zusi
Часовий пояс UTC + 1 година
Скільки кадрів управляє ваш ПК у Кельні-Кобленці ?
.
Чи є спосіб підрахувати посилання у файлах ls, це трохи нудно від руки.
Тоді я міг побачити, скільки файлів загалом пов'язано в модулях ls. Але за приблизними оцінками це кілька сотень (перила, елементи контактної мережі, розмітка платформи тощо).
Одного разу я пропонував щось подібне, коли управління об’єктами в Zusi мало свій крок, а саме впровадити управління посиланням відповідно до маршруту ED, відповідь від Carsten була дуже чіткою.
Для мене це завжди від 15 до 25 кадрів в секунду.
(2,7 ГГц, відеокарта: що я знаю (комп’ютер з травня 2003 року)
На всіх інших маршрутах я нормальний на 40 кадрів в секунду, тільки з Kö-Ko він падає
частота кадрів нижча
(Можливо, через гарний ландшафт; ви майже думаєте, що пейзаж викрадений з іншої гри)
Востаннє змінено Марселем Темпліном 31 травня 2004 р. 19:07:12, змінено в цілому 1 раз.
Отже, я розмістив інтегровану версію на сервері, ви можете знайти її тут.
Попередження: розмір частини становить 16 МБ (16873794 байт).
На жаль, він не стає меншим. Слід також зазначити, що історія вимагає 140 Мб дискового простору.
Одного разу я протестував інтегровану версію на своєму комп’ютері і не виявив жодної різниці. Частота кадрів абсолютно однакова для обох версій. Б. 10 у Кельні Hbf та 18 на вхідному сигналі Кальшоурена. Чому це може бути?.
Моя система: P 4 з 2 ГГц, Windows XP, 512 МБ оперативної пам'яті, відеокарта 64 МБ NVIDIA GeForce 3 Ti 200, 4 x AntiAliasing, 1024 x 768. Регулювання: вигляд 2400/2400.
Завдяки інтегрованій версії я отримую загальмовані 40 кадрів скрізь. Працює чудово.
@Stefan: Дякую за зусилля.
@Holger: Можливо, ви скопіювали щось неправильно або інший файл str, так що старий файл все ще використовується?
Збільшення FPS насправді працює чудово. Тільки результат.
Мій комп’ютер робить різкі рухи приблизно кожні 200 метрів, що є найсильнішим у Кобленці. Погляд на системну інформацію показує, що це, мабуть, пов’язано з моїм жорстким диском. Тому що файл підкачки є гордим 650 Мб на цьому шляху. Незважаючи на те, що я маю 512 Мб 266 оперативної пам'яті DDR. Чому так?
В принципі, я використовував метод Стефана, але завантажив "* _AllLS-Dateien.ls" у редактор будівлі, інтегрував пов'язані файли та знову їх зберег. (Проходить в найкоротші терміни.)
Маючи (на даний момент) 384 МБ основної пам'яті, жодного квіткового горщика не можна було виграти, оскільки триває підкачка. Звідси, мабуть, і заїкання Патріка. (Погляньте на світлодіод для жорсткого диска - він повинен бути переважно темним.)
Потім я віддав своєму старому стругальному апарату (PIII, 850 МГц) ще 512 МБ пам’яті. З теперішніми 768 Мб я отримую близько 19 кадрів в секунду в Кельні, майже 30 кадрів в секунду в Бонні і майже 40 кадрів в секунду на відкритій дорозі. Однак зменшення до 14 кадрів в секунду (в Кельні) або 24 кадрів в секунду (в іншому випадку) було необхідним, щоб уникнути типових звукових ривків (привіт Майкл). РЕДАКТУВАТИ: Звук у мене на борту.
В кінці поїздки з Кельна в Кобленц частота кадрів впала до 2 кадрів в секунду, якою б вона не була. (Давайте подивимось, чи це стосується кожної поїздки.)
Востаннє змінено Крістіаном Грюндлером 06/01/2004 17:32:51, змінено в цілому 1 раз.
В ОС Windows різні інструменти роблять різні заяви про те, наскільки велика необхідна віртуальна пам’ять, оскільки інструменти використовують різні імена.
Але зараз мені вдалося прийняти рішення більшості.
Відповідно до вказівок Стефана, інтеграція та очищення маршруту після завантаження маршруту без розкладу вимагає від мене XP з 768 МБ основної пам'яті:
- робочий набір 393720 КБ, максимум 414828 КБ під час завантаження;
- загальний віртуальний розмір 926408 КБ з максимальним показником 1208484 КБ під час завантаження, з яких 390676 КБ є приватним для процесу, не можна розподіляти.
Отже, якщо ви обчислюєте лише приватні сторінки (які "Диспетчер завдань" також відображає як "віртуальну пам'ять" за бажанням), то приблизно такий самий розмір зберігається у файлі сторінки на додаток до області, яка постійно зберігається в пам'яті.
Тому я вважаю, що будуть серйозні проблеми з обміном пам’яті на 512 МБ.
Зрештою, рішення можна знайти лише в індивідуальній технології зарядки модулів, наданій Carsten. До цього часу можна впоратися з жорстокою силою, звичайно, це не чисто чи елегантно.
Карстен писав:
Я знову завантажив інтегровану версію, нічого не змінилося. Я дав повному "старому" файлу маршрутів іншу назву. Таким чином, інтегрована версія знаходиться на комп'ютері як окремий файл. На жаль, це не може бути причиною.
Я б не називав перетворення з підключеного до інтегрованого ландшафту "жорстоким насильством". І коли ви вважаєте, що доступ до диска при пейджинговій системі уповільнює все це, я, звичайно, запитую себе, чи не призвело б заплановане перезавантаження розділів доріжки також до ривків .
Востаннє змінено Крістіаном Грюндлером 06.01.2004 20:14:35, змінено в цілому 1 раз.
Експерименти минулого року показали, як Карстен знову зазначив, що дуже великі або дуже маленькі сітки надаються менш ефективно, ніж ті середнього розміру. Однак без злиття файлів .ls в даний час практично неможливо створити значущі великі сітки для багатьох маленьких 3D-моделей, таких як поперечні структури тощо. Це купується за ціною більших вимог до пам'яті не тільки у файлах, але й під час виконання для сіток, оскільки перевага трансформації маленької сітки в потрібні місця (множина), що економить пам'ять, втрачається лише в момент рендерингу.
Тільки висновок про скорочення, який би виплив із цього, не буде правильним, що потрібно буде купувати більш високу частоту кадрів із більшими вимогами до пам'яті. На даний момент це фактично - припускаючи відповідну відеокарту - але незмінної причини для цього немає. Інша модель сховища - ключове слово: модульне завантаження - значно зменшить потребу в зберіганні знову, не відмовляючись від оптимальних розмірів сітки.
Звідси і моє зауваження про "жорстоке насильство": включення файлів ls наразі коштує пам'яті. Тож стискайте пам’ять, поки це не стане більше можливим за допомогою лома. Це працює, але знову стає зайвим із введенням нової моделі пам'яті.
Це також може бути пов’язано з графічним драйвером. Особливо для nVidia, неодноразово повідомляється про ефекти, що частота кадрів не є постійною для різних версій драйверів. Інший вплив може спричинити згладжування.
Я можу підтвердити підвищення продуктивності, згадане в цьому потоці, за допомогою інтеграції ls для драйвера 53.03 з вимкненим згладжуванням. Однак з поточною версією 56.72 зі мною нічого не сталося. (Будь ласка, не завищуйте результат. Можливо, є окремі причини, крім номера версії, чому новий драйвер не мав рації.)
також офіційно задокументовано в надрах сторінок nvidia.
Можливість створити ефективні розміри сітки зменшиться із Zusi 3 (оскільки для 2 різних текстур завжди потрібні дві різні сітки). Однак ці недоліки повинні мати можливість компенсувати за рахунок того, що wg. динамічне навантаження означає, що потрібно розрахувати значно менше ландшафту.
Звичайно, зарядка також коштує продуктивності, але іншого шансу немає. Я сподіваюся, що поштовхи не будуть помітні, а лише зменшення частоти кадрів при завантаженні.
Отже, я також наполегливо працював учора ввечері. Мій дещо старший GF 2 Ti також досягає значного збільшення в принципі, завдяки моєму гонщику на 700 МГц в Кельні я отримую близько 15-16 кадрів в секунду замість попередніх 7 кадрів в секунду. Але і для мене проблема з посмикуванням має дуже серйозний ефект, лише 448 МБ оперативної пам'яті, і мій застарілий W98 діє як додаткове гальмо для задоволення. Ну, поки нова закупівля обладнання вже не запланована, я спочатку пропрацюю стару версію, яка принаймні постійно працює на низькому рівні.
Часовий пояс UTC + 1 година
Хто в мережі?
Учасники цього форуму: 0 учасників та 1 гість