Gl-ER

Включение теней (в игре), сглаживание прозрачных поверхностей (8х) и высокое качество текстур (настройка драйвера) при разрешении 1920х1080 в референсном треке используется 1663Mb видеопамяти.

Камрады, внесу свои 5 копеек. CPU 3930K 4Ghz/GPU MSI 670 Power Edition 1228MHz/6010MHz (заводские настройки)/ RAM 16Gb 1866MHz (4 канала) Монитор 27" 1920*1080 Average 45.9 FPS Max 51 FPS Min 31 FPS Stable 93.8% Freeze — Rating 0.82 Включение теней (в игре), сглаживание прозрачных поверхностей (8х) и высокое качество текстур (настройка драйвера) дают такой результат: Average 40.6 FPS Max 58 FPS Min 27 FPS Stable 93.0% Freeze — Rating 0.77 Респект HellDiver и Dell_Murrey-RUS за методику и усилия.

Об этом и речь.:) Не путайте разрешение монитора и количество объектов в миссии. Движок игры можно ввести в ступор и на минимальном разрешении. Разрешение - это работа исключительно для видеосистемы, а объекты - это уже совместная работа ЦП и ГП. С добавлением дополнительных юнитов (объектов), статических или катающихся по кругу, ФПС будет падать, а качество картинки при этом не изменится. В ГС2 с эпик сражением довел систему до того, что ФПС пляшет от 8 до 30 не более.

Позволь не согласиться, 100% загруженность видеокарты как раз показывает, что более мощный процессор не нужен, т.к. карта уже полностью загружена и узкое место именно в ней (если при этом уровень ФПС не отвечает желаемому или достаточному для комфортной игры). А то, что сравнивать надо конкретно в текущей реализации ДКС и более того - на конкретном одном месте трека, абсолютно верно. Здесь у большинства форумчан нет загрузки видеокарты на 100%, не вытягивает проц. Сам наблюдал падение загруженности ГП с 99% до 85-90% (приблизительно) на собственном компе при уменьшении частоты проца 3930К с 4 до 3,6 ГГц. Проверял на третьей миссии компании "Тяжелое небо" из ГС3 (запуск СУ-33 в ангаре и рулежка, филд - Адлер). + травку подрезал с максимума до 500-600метров, т.к. при запуске ЛА в ангаре и рулежке ФПС проседал где-то на 5-6 пунктов. Рулежка и взлет - 28-36 ФПС, Загрузка ГП до 98%. Нет противоречия в том, что при одинаковой загрузке ГП производительность (и в конечном счете ФПС в игре) у видеокарт разных серий и производителей будет отличаться :).

Сегодня праздника не будет.

Вот тебе до кучи что бы не сомневаться. Я от Корсара 80 отказался, а он был так близок (заказал в регарде).

А эти немецкие?

Вот тесты. Я "починил" свой Zalman Extreme (снял резистор), теперь Санди снова дышит с частотой 4ГГц :). От СВО отказываюсь (не категорично, но и не торопит теперь).

Вопрос сугубо практический и больше зависит от охлаждения твоего проца. Навскидку никто не скажет. Так же есть и предел конкретного экземпляра процессора и давай\не давай вольтаж, толку не будет - упрется в свой предел. (да ты и сам все это прекрасно знаешь ) Во-во :D

Как бывший владелец Core 2 Duo E8400 и Quad 9660 подтверждаю, что на кваде система работает более стабильно и не фризит чем на Дуо. Игра действительно крутится на двух ядрах, а на третьем ядре исполняются фоновые системные задачи. Такой разницы между четырьмя и шестью ядрами в текущей реализации ДКС нет. Разница в игре ощущается только в том, что ядра современных процев более производительные и лучше разгоняются чем старик квад.

Сегодня на оверах вышел интересный, на мой взгляд, обзор про процессоры. i3 существенно сливает, i5 и i7 не зависимо от поколения держаться практически на уровне. Спасибо за линк, использовал, то, что было :).

Провел небольшой эксперимент на своем конфиге в поисках максимально возможной производительности при имеющемся охлаждении (Zalman Extreme, который планирую заменить на СВО замкнутого цикла того же производителя). Практичность этих данных применительно к ДКС не обсуждаю, только голые цифры. Итак, имеем проц 3930К. Производительность и стабильность работы замерялась на Linx 0.6.4 с AVX, температура ядер программой C-Temp. Максимальная температура достигала 91-94 Гр. HT выключен. 6 ядер - 3,7GHz при Vcore=1,11V - 145 Gflops 5 ядер - 3,9GHz при Vcore=1,14V - 128 Gflops 4 ядра - 4,0GHz при Vcore=1,145V - 100 Gflops Вне зачета, т.к. стабильность больше не подтвердилась из-за перегрева, привожу годовалые данные: 6 ядер - 4,0Ггц при Vcore=1,18V - 155 Gflops Может быть кому-то будет полезна данная информация. PS Снял ограничитель оборотов с вентилятора (резистор): 6 ядер (HT off) - 4GHz при Vcore=1,18V - 155 Gflops пик нагрева 80 Гр. (1600 RPM) 6 ядер (HT on) - 4GHz при Vcore=1,195V - 121 Gflops пик нагрева 85 Гр. (1450 RPM)

Здесь опасность, что интел не будет долго развивать эту платформу, как это было с 1156->1155->1150->? А 1366 и 2011 - долгожители относительно вышеуказанных платформ. Это к теме нашей переписки. Что тебе больше подходит знаешь только ты :). Ладно, парни, я откланиваюсь, опять 4 утра :doh:.

Это точно, у меня был его старший брат на кваде - zalman cnps 9700 nt. Держал температуру прилично для воздушного охлаждения, но воет он страшно при этом.

Кулер исправил на Extreme, Корпус нормальный, с боку добавил два вентиля, один потом пришлось снять как раз из-за кулера, только башня приличная в него уже не входит по высоте. Корпус-то еще от Дуо и Квада остался, хотел менять его, но зажал, а потом свыкся. Как сказал, я уже год в завязке, разгоном категорически не занимаюсь ибо могу сорваться :). Максимум - это замена видео в год-полтора. Больше пока ничего не требуется. Лучше Мамбу и педали взять, чем лайтнинг :).

Мать - ASUS Rampage 4 Formula Кулер - Zalman CNPS11X Extreme Корпус - Gigabyte Poseidon Исправил кулер.

Был у меня раптор 250Гб, его и поменял на плекстор 128Гб, т.к. после нескольких скачков напряжения (ИБП как раз был с дохлым аккумулятором) Раптор представился - электроника померла. Сигейты 500 (из той самой проблемной серии) и 1000 выжили.

Да, я Veterу отписал уже, у меня охлад несерьезный, поднимать напряжение больше 1,3 не могу и при этом частота максимум 4,3 всего. Далее от повышения напряжения температура резко растет, но частота выше 4,3 не дается. Такой уж экземпляр попался. Поэтому со спортом завязал и остановился на 4Ггц при 1,15В (точно вольтаж не помню) и 70Гр. в пике.

У меня на 3930 по данным С-Temp проц на линпаке на 6м ядре начинал сбоить при температуре 94-96 градусов. Тротлинга не было, просто ошибка и остановка теста. Синий экран на этот раз не ловил. (Все что было написано ранее до редактирования поста по памяти не верно, проверил сегодня специально еще раз). Температура поднялась до 96 градусов на 4Ггц и 1,18В, тест линпака не проходит. Температуру сбросил только уменьшением напряжения на ядре до 1,10В и соответственно частоту пришлось урезать до 3,6ГГц. Вот такой у меня комплект 3930К + кулер. Увы. Слился по частоте с 4,3 до 3,6 за год эксплуатации. Охлад проца менять надо, факт.

Есть кое-что о совместном использовании старой и новой линейки АТИ АМД здесь.

Разовью мысль, озвученную в своем предыдущем посте. Обсуждается вариант установки задержки по времени, но есть и другой путь - манипулировать не временем задержки, а скоростью возвращения виртуального РППУ в ноль. Поясню, Время задержки предполагается использовать всегда фиксированное 0,5сек в моем примере и 1,5 сек в посте выше, НО РППУ в полете отклоняется на разные углы - от минимального до крайнего и поэтому оперировать фиксированной задержкой по времени нельзя, а надо оперировать именно скоростью возврата РППУ в ноль, т.к. этот параметр позволяет учесть и расстояние и время - расстояние РППУ от нуля и время прибытия РППУ от точки триммирования до нуля, т.е. чем больше угол отклонения РППУ, тем больше времени понадобится для возврата в ноль. Если представить себе, что при ограничении по времени виртуальный РППУ находится в точке триммирования, а по истечении времени задержки телепортируется в ноль (в этот временной интервал физический РППУ должен быть перемещен в ноль иначе рывок, при чем чем боль угол отклонения, тем больше рывок), то при использовании варианта оперирования со скоростью перемещения красной точки до нуля, виртуальный РППУ сразу после триммирования начнет движение в ноль с заданной пользователем скоростью и даже если пользователь сразу не подберет комфортное для себя значение скорости возврата виртуального РППУ, кивок вертолета, на мой взгляд, будет меньше, чем при использовании задержки и телепортатора красной точки в ноль. Может немного сумбурно, но если разобраться, то по-существу. Не пинайте сильно :).

Извините, торопился, а надо было мне сначала обозначить терминологию, а именно, что подразумеваю под РППУ: 1. Под физическим РППУ понимаю джойстик пользователя и действия им со стороны этого пользователя в виде данных Output в игре (перемещение красной точки). 2. Под виртуальным РППУ понимаю тот РППУ, который мы видим в виртуальной кабине. 3. Соотношения между 1м и 2м настраиваются манипуляцией с осями и коэффициентами. Так вот, в полете манипулирование джойстиком отзывается через Output на положении РППУ в кабине, но только до момента триммирования. В момент триммирования виртуальный РППУ начинает стремится к нулю с какой-то фиксированной скоростью (как реализовано сейчас в случае если опция ожидания возврата не используется) и при этом за отведенное для этого время физический РППУ в руках пользователя должен тоже переместиться в ноль, если этого не происходит, то получаем рывок. В случае включения опции ожидания возврата джойстика в ноль время этого ожидания установлено в бесконечность, т.е. пользователь не может управлять вертолетом до тех пор пока физический РППУ не будет приведен к нулю. А дальше напрашивается компромисс между этими двумя условиями - сделать настраиваемое пользователем время ожидания возврата в ноль в заданном диапазоне (какой это будет диапазон необходимо определить на практике). Например для кого-то будет комфортно 0,5 сек, а кому-то 0,9 или больше.

Как я понял, Output - это красная точка, т.е. реальное положение РППУ, она и пишется в трек и от нее все пляски с бубном начинаются. А задержка устанавливается именно в инпут и от него уже расчет скорости перемещения красной точки в ноль после триммирования.

Все очень доходчиво и понятно :), но это лишь еще раз подтверждает необходимость писать в трек коэффициент задержки перемещения РППУ владельца трека, для корректного проигрывания данного трека на другом инпуте, а если трек передается Васе и Вася берет управление аппаратом, то именно (и только) тогда использовать значения инпута Васи (после этого конечно схождения не будет, но как вел себя автор трека узнать можно если просто посмотреть трек от начала до конца и ничего при этом не трогать). Все это конечно не сейчас и сразу, а с прицелом на будущее. Мысль-то у StarLey_Andrew хорошая! :thumbup:

Логично: - низкие настройки графики дают передышку ГП и ЦПУ успевает его накормить, - настройки графики усложнились - ГП пыхтит рисует, ЦПУ не успевает ему подавать на вход данные, минимальный FPS проседает. Причем как раз безрезультативный переход на более производительный ГП подтверждает факт, что ЦПУ не мог как следует накормить 460SE, а 770го накормить ему еще сложнее. ГП простаивает не загруженный. В ГС2 устраивал эпик вар - боты с ботами - флот, эскадрильи, танки, смерчи и все что летает и ползает (20-30 FPS максимум). Это безобразие и санди переварить не может. FPS увеличивается только на 2/3 сюжета, когда синие или красные (рандом - в нем и смысл) перебьют друг друга, а остатки гордо удаляются под занавес на скорости 40 FPS. Но Мир в плане графики гораздо шустрее ГС2, над ним хорошо поработали (а баги залатают).