FreemanRU

Здесь это уже много раз обсуждалось. Узкое место текущего движка ЛО - это процессор. Чем он (причем если это многоядерный - то только одно ядро) мощнее/быстрее/больше кэша L2 - тем быстрее работает ЛО.

4 ядра работать не будут. Читай эту тему. На полных настройках тоже врдяли полетишь. Чиж обещал, что ЧА будет на 50% тяжелее, чем 1.12

И что? 3D модели - это даже не пол дела. ИМХО конечно. Пока в ЛО нет API, которое позволи было "вставлять" в него хотя бы СФМ модели самопальной, говорить о сходстве с MSFS в этой области рано.

У меня одна кнопка задействована под Shift на нем, соответсвенно Shift+хатка = тримерры.

Кстати, вот: http://www.beyondlogic.org/consulting/processutil/processutil.htm http://www.activeplus.com/us/freeware/runfirst/

Вопрос был из 2х частей. =BVA=Zmey Только сначала таки надо перевесить на один проц (ядро). А уж потом реальное время врубать.

Тока не рекомендую реальное время. Могут начаться лаги, т.к. все время будет съедать процесс, а на дрова прерываний не хватит.

Возможно, в низкоуровневых приложениях типа ЛО, где требуется математика, просчеты, работа с памятью - да. А вот писать прикладное ПО на c\c++ - дорогое удовольствие. И это даже не ИМХО. А вот к скриптовым языкам у меня вообще антипатия. Так уж сложилось. Ибо медленно, неуклюже. Хотя сам 95% пишу на скриптах. Но это специфика профессии - сисадмин :) И кстати меня очень удивило, что новый движок будет не на DX (хотя возникла мысль, что это сделано для кросс-платформенности). Прошу прощения модераторов, всё, больше флеймить не буду.

А что так, если не секрет? Или имелось в разрезе использования с ЛО?

Твоя правда, это я с Разорванным Небом перепутал Со всем уважением, но сравнивать Ударную силу с симулятором, да еще и вертолета..... :cry:

Ударная Сила не работает под XP (проблемы с отрисовкой поверхностей). Да и с физикой там не очень-то хорошо. Интересует всё-же именно физика вертолета.

.., то хотелось чуть-чуть попрактиковаться. Из достойных симов имеем не богатый выбор - MSFS и X-Plane. Видел на форуме, что тестеры BS играют и в то, и в другое. Соответсвенно вопросы: 1. Где физика вертолета максимально приближена к локоновской? (понимаю, что в локоне соосник а в перечисленных мной - классика, но все же) 2. (как следствие первой) Какую из игр можно использовать как тренажер вертолета?

Открываешь файлик %windir%\system32\drivers\etc\hosts (файл без расширения) блокнотом, и пишешь на каждой отдельной строке: 80.250.162.148 raf.server.main 111.222.333.444 server.low.ping И после этого можешь использовать эти имена в настройках сервера.

http://www.ag.ru/games/enemy_engaged_2 Кто помнит "Разорванное небо", тот порадуется.

А что вообще случилось-то? Можно комментарии хоть какие-то получить?

Т.к. все основано на выходных lua-скриптах, то ждать Шквала не стОит. Автору - отличная разработка, я начал что-то подобное, но за неимением времени пришлось отбросить. А OpenSource-сность проекта не входила в дальнейшие планы ;) ?

Про НАРы правильно заметили. Просто не может быть, что бы после попадания 5го(С5) НАРа в 3х метрах от ЗИЛа, последний продолжал ехать... нереально...

Ты толи шутишь, толи издеваешься.... или просто с трудом представляешь, что такое физическая модель. Пример. Есть танк. Есть ровный полигон, изображающий дорогу. Вар 1. Танк едет по дороги, расчитывается только перемещение пикселей. Знаешь на сколько будет загруже проц при использованиии DX-ускорения? % на 2, максимум 10. Ибо он НИЧЕМ не занят, всё перемещение сводится к сдвигу в матрице с помощью вызовов DX, а они в свою очередь обрабатываются GPU. Вар 2. Танк едет по дороги, но при этом расчитывается колебание внутренней башни, давление на дорогу, сопротивление ветра и где-то еще за кадром перемещение второго танка. Что изменилось для видюхи? Ровном счетом НИЧЕГО. Но в этом случае проц нагружен на 100%, т.к. идет обсчет физики. Пример понятен? Далее пример из "жизни", т.е. из локона. Если следовать твоей логики, то если мы выставим камеру в небо, то у нас ФПС ничем не должен ограничиваться - расчет то графики не идет. Только почему-то у меня при взгляде в небо не более 15 ФПС, когда на земле возятся 20 танков. Когда никого нет - 70-80. Повторюсь - расчет графики по сравнению с расчетом физической модели - ничто. Кстати вот здесь мы и видим те "качели" движка, постороенного на покадровой модели - мы всегда, даже на 3-4 ФПС имеем ровную игру (да, медленную, но ровную), в других играх после 15 ФПС, если не справляется проц мы видим "фризы".

1 и 2. Ну и как следствие - пример в 3ем. "Процессор подготавливает данные для видеокарты, видеокарта превращает их в картинку на мониторе." - процессор практически ничего не готовит, кроме собственно координат, которые к видюхе имеют посредственное отношение. 2. "Нехватка процессора" в данном случае - это его неспособность разорваться между кучей потоков. Так что слудет добавить еще один вариант в пример - когда чувак с канистрой не успевает подливать топливо.

Ну, мягко скажем, многое не правда. ИМХО видеокарта в ЛО не сильно влияет, я имею ввиду видеокарты современные. Т.е. н-р на 6600GT упираемся примерно в теже FPS, что и на 7900. По поводу аналогий - грубо говоря, процессор лишь подгатавливает сырые данные для видюхи, координаты и адреса текстур. А всю остальную работу делает GPU (графический процкессор). Именно он преобразует координаты в треугольники, делает основные графические построения и пр. Это то, что называется "поддержкой DirectX" (или Opengl), когда видюха выполняет многие построения, вызываемые методами DirectX. Так что если брать твой пример, то проц это скорее чувак с канистрой, который подливает топливо в насос. ПРосто в ЛО этот чувак еще разружает канистры, поет пол, чинит насос и пьет чай. И всё это одновременно. ЧТо касается тестов - я их сейчас как раз виду. И на 100, даже на 105% процентов могу утверждать - узкое место ЛО - проц, и моддержка многопроцессорности/многоядерности выведет игру на более высокий уровень. Думаю (это только МОЁ мнение, никого ни к чему не обязывающее) разработчикам надо в первую очередь работать именно над этим, хотя, как я уже говорил, реализовать это в Акуле будет проблематичным. Н-р с компа Cel 2000/756/ATI 9600PRO замена процессора на P4 2,4 увеличило FPS примерно на 15-20 (было среднем 10, сейчас 25-30) Что есть процессрное время - наземка, Chizh прав (что не удивительно, ему то виднее). Если из миссии убрать все наземные объекты - всё просто летает. Даже 20 самолетов (только если они не Су-25Т, см. ниже о нем) почти не грузят комп. Н-р битва 12х12 танков на земле провешивает машину см. выше (которая уже с Р4) примерно до 10 ФПС. Что же касается Су-25Т, то всё хорошо, пока на них не смотришь. Н-р группа из 4х Су-25Т даже на удалении 30-40 км, "отъедают" 10 фпс. Легко. При чем при приближении это не сильно меняется. Только если они совсем ближко (до 1км), тогда фпс просаживается совсем, отъедается примерно 20-30 фпс.

Тут уже не раз поднималась тема о целеуказании в игре по сети, в выходом Акулы это становится еще более актуально (об этом тоже писали :)). Т.е. н-р передать цель с Акулы на Су-25Т было бы просто волшебно. Но в игре это не предустмотрено вообще. Это понятно. Сейчас можно делать появление цели уже в процессе миссии. Н-р создаем группу танков, ставим её появление через 20 минут, скажем, и делаем эту группу скажем целью для штурмовиков. Тогда цель (заветный ромбик :)) появится только через 20 минут после старта миссии. Собственно теперь вопрос. Сложно ли так, чтобы танки появлялись не по времени, а по событию? Т.е. время ППМ1 для этого танка устанавливается динамически в таком случае, н-р с помошью lua или еще как-то?

1. как решат модераторы 2. Я не претендую на полноту освещения своего теста, а лишь хочу сравнить различные тесты. Если кого-то интересуют подробные данные - могу поделится, если нет - могут и помолчать, а не зарабатывать флеймом посты. 3. Файл подкачки в моём тесте не использовался вообще, как было после старта локона 13% использование файла подкачки, так и осталось. Винда сгрузила всё неиспользуемое в файл подкачки, так и работает. Обращение к файлу подкачки нулевое. Так что файл подкачки тут не причем. 4. Да ты чё? Грубо говоря, если приложение не расчитано на работу с 2м процом/ядром, то ОС (любой) пофигу, она не будет за приложение распаралеливать процессы. 5. Искал, не нашел. To Интересующимся Обещанная инструкция (для XP/2003). 1. Запускаем permon (Пуск-Выполнить, вводим perfmon, Enter). Откроется окно с графиком real-time статистики. 2. Нас real-time мало интересует, нам надо сделать сбор постоянный. Для этого в дереве слева открываем "Журналы и оповещения производительности" и выбираем журналы счетчиков 3. В правой части нажимаем правой же кнопкой мыши (или выбираем в главном меню "Действие") пункт "Новые параметры журнала", вводим ео имя (любое) 4. В начале нам необходимо добавить счетчиков. Жмем кнопку "Добавить счетчики". В основном нас интересуют следующие объекты - Процессор, Процесс, Память, Файл подкачки, Физический диск и/или Логический диск, лучше оба. Далее распишу те датчики, показания которых напрямую говорят о производительности и какие значения нормальны (если есть). Описание каждого счетчика приводить не буду, для этого есть кнопка "Объяянение". Объект Процессор. Тут всё просто: % загруженности процессора. Это то, что мы видим в Диспетчере задач или ProcExplorer. _Total - это общая для всех процов, далее цифра с 0 - это соответсвенно номер процессора. Рекомендую включать как _Total, так и каждый из доступных процессоров, если их более 1. Остальные датчики в объекте Процессор не столь важны, разве что можно обратить внимание на кол-во прерываний в секунду. Кнопка Описание даст дополнительную инфу. Объект Процессы. В данном объекте рекомендую выбирать пункт "Все вхождения" вместо выбора определнного процесса. % загруженности процессора. Показатель для каждого процесса отдельно. Полезно, позволяет просмореть кто как нагружал процессор. Байт файла подкачки Счетчик потоков Объект Память Обмен страниц в секунду - нормальное значение для серверов до 20, для workstation - до 15. Доступно МБ Объект Файл подкачки Там один параметр - % использования. Объект Физический (или Логический) диск. Параметры для физического/логического диска одинаковы. Обращений записи на диск/сек Обращений чтения на диск/сек Обращений к диску/сек (это сумма двух предыдущих.) Скорость записи на диск/сек Скорсть чтения с диска/сек Скорость обмена диск/сек (это сумма двух предыдущих.) Средняя длина очереди диска Текущая длина очереди диска. Чем меньше, тем лучше. Значение более 10 уже плохо. Для хорошо разбирающихся в работе ОС также рекомендую посмотреть на объект Система. Выбрав счетчик жмем кнопку "Добавить", и так до тех пор, пока не будут выбраны все интересующие счетчики. 5. Выбираем интервал записи по чаще, от 2х до 5ти секунд 6. Переходим на вкладку "Файлы журнала". По умолчанию файл журнала будет записываться в папку c:\Perfmon, если у вас несколько дисков, физических или логических, папку с журналами надо раполагать на диске, где НЕ установлен Локон. Для выбора папки жмем кнопку "Настроить". Тип журнала - двоичный, наименование самого файла можно сделать любым. 7. Переходим во вкладку "Расписание", устанавливаем запуск и отсановку журнала "Вручную". 8. Жмем ОК. Если в кач-ве каталога для записи была указана несуществующая папка, perfmon предложит её создать. 9. В списке журналов счетчиков теперь появилася журнал с заданным в п.3 именем. Для запуска сборов счетчиков щелкаем на имени правой кнопкой мыши, и выбираем "Запуск". После этого закрываем perfmon, и запускаем Lockon, лучше запомнив время запуска. Далее играем, и лучше иметь синхронизированные с компьютером внешние часы, дабы знать что в какое время происходило. После выхода из игры снова запускаем perfmon, находим наш журнал счетчиков, жмем на нём правой кнопкой мыши и выбираем "Остановить". Далее начинается самое интересное - промотр того, что же мы получили. Об этом чуть позже.

Это подходит, только если у тебя 2 монитора, да и то не вся инфа. У меня еще есть подозрение на видюху, вернее на её драйвер. двухядерность для приложений = многопроцессорности, движок Локона не умеет работать на 2 и более проца, об этом уже говорилось, Акула сделана на том же движке, делаем выводы... orthodox 1. Нагрузка на диск при записи даже 50 счетчиков ничтожна мала, так что на общую погрешность не влияет 2. При чем здесь mmc? запись счетчиков идет с помошью службы "Журналы и оповещения производительности", smlogsvc.exe Инструкция будет завтра, постараюсь с утра, ща спать иду...

Собтсвенно такой темы не было, или я не нашел. Я тут много почитал, и ничего толкового на данный счет не нашел, если не считать "мне кажется" или "я думаю". Цифр нет, фактов нет ну и т.д. А ведь перед тем, как менять железо, надо решить ЧТО менять, бюджет не резиновый. Итак, что что получилось у меня. Дана железка - Cel 2 Ghz (400 FSB), 756 Mb DRR 233 Mhz (3х256Mb плаки), IDE 120Gb, видео ATI RADEO 9600Pro, мать GA-8GE667 Запускаем perfmon на сбор основной информации по процу, памяти и диску. Тестировал на стандартной миссии из начального меню для Су-25Т. Что получилось у меня: 1. Диски.При загрузке самой игры огромная очередь чтения на диске, что собственно не удивительно. Делаем выводы, что улучшение дисковой подсистемы приведет к ускорению загрузки игры. ВО время самих миссий обращение к диску можно считать 0м. Соответсвенно улучшение дисковой подсистемы на сам игровой процесс никак не повлияет. 2. RAM. Играл одну и ту же миссию с рестартом после падений самолета. Свободной памяти в начале было больше 100Мб (~120), в конце миссии ~80mb. После выхода из миссии (но не из игры) кол-во доступной памяти уменьшилось до 60Мб. Можно сделать вывод, что 756Mb игре хватает. Скорость обмена в памяти тоже была в пределах допустимого, лишь скачки во время загрузки миссии или рестарта самолета. 3. CPU. А вот это самое интересное. Я ожидал 100% нагрузку, но вышло совсем не так. Загрузка варировалсь от 90 до 100, при этом иногда, судя по времени - во время рестарта самолета, падало до 80%. Также периодически возникала активность процесса System, в других играх/приложениях такого не наблюдалось. Причем активность процесса System достигало 40%. Средняя нагрузка на CPU от момента входа до момента выхода из игры - 94%, процесса lockon и того меньше. Собсвтенно данные показатели ввели меня в тупик. Почему так происходит? Я делаю подобные анализы для серверов, и вот там бывает 100% нагрузка на CPU постоянно, без скачков. Если скачок происходит, то этому есть причина - страничный обмен в памяти, обращение к диску, к сети и пр. А тут просто колебания, на вид не связанные ни с чем. Взял P4 2,4/512/400, посмотрю что будет, запущу тест еще раз. Сюда по этим данным, я не знаю, что за игра запущенна, мог бы сделать вывод, что CPU ей хватает, а если и не хватает, то не так и много. Единственное, чем это можно объянить - слишком большим кол-вом одноврменных обращений к CPU, и как следствие - небольшое проседание в момент переключения треда. Этопришло в голову только что, сегодня вечером потсмотрю кол-во тредов в процессе, если конечно я писал эти данные в журнал. Собственно у меня просьба к владельцам среднего и топового железа - проделайте подобные тесты и выложите их, при архивации даже за 30-40 минут лог производительности будет не большой, до нескольких Мб. Хотелось бы посмотреть, что и как на более мощных компах. Если кто хочет собрать эти данные, но не знает как - скажите, я напишу подробную инструкцию. Жаль только, что perfmon не собирает производительность с видюхи. Кто нибудь знает - есть ли способ проверить нагрузку на GPU и память видеокарты, подобному perfmon?