ups

На полочку поставить - для красоты :P

Потому что у меня на текущих настройках FPS ограничен процессором, а видео недогружено (я мониторю загрузку GPU и видеопамяти, графики вывожу на второй монитор). Будет более мощный процессор, будет разница. Сейчас видео менять смысла нет. Реально у меня во многих сценах FPS не поменялся даже при переходе с GTX 480 на GTX 680 (пока 4x сглаживание стояло). Пришлось накрутить максимальное сглаживание, чтобы хотя бы на 80% загрузить GPU 680-ки с текущим процессором. 780-ка (да хоть Titan) мне тем более пока без надобности. Сейчас у меня недогруз видюхи 20%, с 780-кой был бы бОльший недогруз, а FPS был бы тот же :)

Речь о настройках именно DCSW. Но если всё действительно было на максимуме (или даже хотя бы как у меня на скриншоте настроек), то получается, что Sandy Bridge-E на равных частотах намного шустрее, чем мой Nehalem. Похоже пора менять процессор...

Практически - не имеет. А ответ на Ваш вопрос по EDGE, вероятно, вот:

Просто у меня зеркала рендерятся не каждый кадр, а через кадр. И гражданский трафик у меня низкий стоит. Возможно если у себя так настроите, тоже 36 получите.

Хорошо, раз не хотите светить свои настройки, давайте на моих попробуем: Создаю миссию в редакторе, ставлю Ми-8МТВ2 на в Нальчике с запущенными движками на стоянке №4: После снятия симулятора с паузы и окончания автоизменения зума имею 36 FPS (при включенных зеркалах): При этом GPU загружен на 80-82%, видеопамяти использовано 1,6 Гб (то есть тоже не вся). Было бы интересно знать Ваш результат при том же раскладе.

Хорошо. И поверьте, не хотел Вас доставать. Хотел помочь. FPS>>45 на каком ЛА? А то у меня Ми-8 и Ирокез в 1.5-2 раза по этому показателю отличаются. И можно скрин Ваших настроек графики? Тоже такой FPS хочу. Видео у меня сейчас недогружено, так что надо разгрузить процессор, а какая-то опция жрёт его ресурсы.

В данном случае это - побочный эффект, а не назначение опции. Попробуйте ещё отрубить сглаживание вообще, не только прозрачных объектов (принудительно - через драйвер: "Сглаживание - режим: Выкл"). Некоторые режимы сглаживания "мылят" текстуры. Если поможет - тогда искать такой, который не "мылит" или летать без сглаживания. Да, кстати, Вы меняете глобальные настройки или профиль для конкретной игры? А то у DCS с последним может быть сложно - там же по exe-шнику приложение идентифицируется, а у него то один стартует, то другой (GUI, сам симулятор). Можно ещё попробовать HDR временно убрать, часть HDR-эффектов тоже могут картинку блюрить.

В корне неверно. Упомянутый вами параметр влияет на сглаживание прозрачных объектов. А за размытие полосок, которое Вы привели на скринах, точнее за отсутствие размытия, как верно Вам объяснили, отвечает анизотропная фильтрация. У Вас ничего не получается из-за того, что Вы не там ищете. Где искать - уже сказали. Для наглядности: Анизотропная фильтрация выключена: Анизотропная фильтрация 16x: Хорошо видно разницу в отрисовке "зебры" на ВПП?

Так не честно - Вы снимали с разной точки, то есть угол - разный, для GeForce - практически с уровня полосы, для Radeon - несколько сверху и всё равно вдалеке у него полоса размывается :) По поводу анизотропной фильтрации уже подсказали. Добавлю ещё: в настройках драйвера NVidia есть параметр "Фильтрация текстур", его стоит поставить на "Высокое качество", а параметр "Анизотропная оптимизация" - отключить.

Понятно, ну что ж, развивать оффтоп не буду. Если ближе к теме ветки, то вопрос-то основной один, но на него Вы мне вряд ли ответите ;) Насколько EDGE в действительности новая разработка, а в какой степени он наследует существующую кодовую базу движка DCS World, а с ней и его проблемы (особенно в плане масштабируемости под многопроцессорные / многоядерные архитектуры)?

Только зря Вы всё сбиваете обсуждение в полный оффтоп. Изначально я хотел сказать, что ED никак нормально не распараллелит свой движок, может боится лезть в код, который писали люди, давно уволившиеся ("не трогай то, что работает"), или не хочет на это тратить много ресурсов - не знаю уж, это ваша внутренняя кухня, я бы не хотел тут заниматься гаданием на кофейной гуще. Факт в том, что в итоге с движком в загруженных сценах с трудом справляются топовые процессоры под разгоном, и при этом 80% вычислительных ресурсов процессора простаивает. Ну дело ли это? А Вы всё отшучиваетесь, типа "вам виднее". Если есть принципиальная проблема при распараллеливании (не типа тех, скорее организационных, что я сейчас упомянул, а техническая), может проще обрисовать её, вдруг кто-то решение предложит? Наверняка специалисты есть не только в ED, могут быть и среди аудитории форума.

Элементарно - схема с фиксированными разделами. Процесс загружается в свободный раздел. Адресация изначально "+N байт от начала раздела". Загрузчик программ модифицирует эти адреса при загрузке процесса в память, заменяя конкретными физическими адресами (смотря в какой раздел грузим). Вот сейчас с Вами помозгуем и легко спроектируем такую многозадачную ОС, которая будет работать на Z80. Нет там никаких принципиальных проблем ;) Вы, кстати, про SymbOS не слышали? Это свободно распространяемая многозадачная операционная система для Z80 ;)

Ну вообще-то изначально я говорил про многопоточность, а не про многозадачность. Процесс и поток вещи разные. А конкретно по Вашему вопросу - многозадачность в Win 3.1 (не NT 3.1) так и работала - без нормальной защиты памяти, без вытесняющего планировщика, много без чего. Да, криво работала (одна программа легко могла подвесить всю систему, элементарно не вернув управление). Но работала ;)

Вы правы помимо последнего предложения. Параллельному программированию обучают всех программистов (и не только) ещё в ВУЗе, полагаю уже несколько десятилетий ;) Перефразируя господина eXceed'а, концепция многопоточности существует со времён царя Гороха (точнее со времён мейнфреймов на UNIX).

Извините, я не Вам, просто неудачно процитировал Ваши слова в подтверждение своих :doh: Пост поправил для исключения двусмысленности.

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

И в чём Ваш исторический экскурс противоречит тому, что я написал выше? В данном посте Вы неправы лишь в этом: Многопоточность вполне себе работает без всяких "свойств железа". Просто потоки будут работать по-очереди. Достаточно поддержки средствами ОС. Можно и без ОС, если напишете свой планировщик потоков. Только если делать совсем без аппаратной поддержки, даже без прерываний, придётся делать в парадигме невытесняющей многозадачности - чтобы поток сам через какое-то время возвращал управление.

Да. Но только в том смысле, что Вы изначально использовали неправильный термин. Многоядерность - свойство железа. Многопоточность - свойство софта, позволяющее использовать многопроцессорность / многоядерность ;) Движок World'а, кстати, многопоточный (кто не верит - может заглянуть в диспетчер задач), но у него потоки несоизмеримые по расходу машинного времени - один (основной) - тяжёлый, остальные (вспомогательные - звук и т.п.) - много легче. Поэтому эффективной загрузки нескольких ядер не выходит. Нужно основной цикл параллелить :music_whistling:

Это здесь не при чём. Если платформа не поддерживает несколько ядер, то наличие такой поддержки в движке не поможет, но и ничем не помешает. Нормальные кросс-платформенные проекты (не движков конкретно, а вообще любого софта) многоядерность (точнее многопоточность) поддерживают и используют, если есть возможность. Так что в данном случае - косяк разработчиков. Возможно им просто лень переписывать старый код, написанный ещё в домногоядерную эпоху.

Понятно. Но я как раз пытаюсь до Вас донести мысль, что моделирование, скажем Су-27П, с уровнем детализации, как у DCS A-10C ничуть не проще, даже напротив - в ряде аспектов гораздо сложнее. И пусть Вас отсутствие МФИ в кабине не вводит в заблуждение, Су-27 тоже "компьютеризированный" - там несколько БЦВМ разных типов и нужно знать алгоритмы их работы, не говоря уж о том, что там нет жёсткой связи ручка-управляющие поверхности, СДУ - это тоже фактически специальный компьютер + плюс его исполнительные органы.

Значит нужен какой-то аналог кикстартера, через который мы могли бы скинуться не деньгами, а человеко-часами, эх, жалко, что человеко-часы скажем электрика или сантехника не конвертируемы в человеко-часы программиста или 3d-дизайнера :D