Hard Старые видеокарты

Баг так и не был исправлен http://www.ixbt.com/video/itogi-video/bugs/bugs-sc-1.html

 

Темка от Unwinder
http://forum.ixbt.com/topic.cgi?id=10:38613
с продолжением
http://forum.ixbt.com/topic.cgi?id=10:55650

Заодно, предваряя возможные и в каком то смысле неизбежные выяснения, даю ссылку на многотомный срач NVIDIA vs ATI

 

@vedmysh, про FP почитаю, спасибо. Про скандал в курсе Про суперскалярные архитектуры усвоил.

Ну, вообще-то этого никто и не скрывал, а в той статье так и было сказано в самом низу: "Под конец презентации Гейб Ньювел отверг слухи, что демонстрация результатов была проведена ради самих результатов. Гейб объяснил, что Valve не имела какого-либо скрытого умысла при проведении тестирования. Напротив, результаты явились финальной причиной выбора ATi в качестве партнёра по запуску Half-Life 2."

У меня есть и пиратский и от 1С. Пиратский версии 1.0 посмотрел. Режима NV30 не обнаружил. Патч пока не ставил, посмотрю чуть позже.


@Bato-San, на блюзньюс интересное инфо, только пока действительно непонятно, почему не соответствует действительности. Ведь Doom3 вышел с версией 1.0 и NV30 кодпафа там не оказалось.

За ссылки по драйверам благодарю, таких обсуждений - тысячи. Меня интересовали конкретные проблемы с играми и @BrainRipper уже подкинул достаточно. Больше не нужно

 

Я вчера посмотрел версию 1.31. Для r_renderer нельзя задать nv30 - откатывается на arb2. Возможно, он называется как-то иначе. Хотя подозреваю, что его там просто нет. В общем-то поддержка NV30 может заключаться в модификации существующего кода. Например для версии nv20. Но в планах фигурировал именно отдельный кодпаф. Думается, что дальше планов-экспериментов оно все таки так и не ушло. Впрочем, я не смотрел код компилирующий шейдеры и собственно сами шейдеры. Возможно наличие NV30 как-то учитывается там...

 

@vedmysh, Ещё немного покопался в релизе для винды. Значит, кодпафа nv30 точно нет, есть только те, что вы привели (в т.ч. best). Exp у меня не заработал, хотя я не особенно пытался (в той ветке на бейонде пишут, что заставить можно). Интересно другое: внутри файла pak000.pk4 я нашёл папку glprogs, в ней разные шейдерные программы, которые вроде бы как не используются (если верить комментариям внутри), но при этом при инициализации движка наличие их проверяется. И вот в них есть такие моменты, как:

Я пробовал менять везде на _nicest, но в рендере ARB2 разницы не увидел (не там смотрел?). Быть может, эти программы используются только в Exp, не знаю. Я далёк от программирования. Если вам несложно, можете посмотреть в исходниках ничего подобного нет? Если есть, то вот интересно, применяется это ко всем или только к nv...

 

Долго думал куда, пусть тут будет.

 

@tuliss, 120/144 ещё бы.

 

Ну работа не моя. Думаю люди с фотошопом могут добавить и 100/120/144.

 

Вот здесь лучше видно http://boallen.com/fps-compare.html

 

best это просто выбор наилучшего.
На счет файлов в паке. Ресурсы из одного пака могут "заменять" одноименные (совпадающий путь) ресурсы из другого пака. Порядок загрузки одноименных паков в обратном алфавитном порядке. То есть от наибольшего к наименьшему. Таким образом файлы будут браться из пака с большим номером. Вполне возможно там есть еще папочка glprogs, в другом паке с большей цифрой в имени.

На счет хинтов. Совершенно не обязательно, что смена хинта как-то повлияет на результат. Это только "рекомендация".
К nv оно имеет отношения, да.
https://www.opengl.org/registry/specs/NV/fragment_program4.txt

Хорошо, на досуге как появится время загляну, как он оперирует с фрагментными программами.

 

Да, это понятно. В других паках ничего подобного более нет. Сами файлы-программы называются так:

Код:

ambientLight.vfp
bumpyEnvironment.vfp
colorProcess.vfp
environment.vfp
heatHaze.vfp
heatHazeWithMask.vfp
heatHazeWithMaskAndVertex.vfp
interaction.vfp
test.vfp
nv20_bumpAndLight.vp
nv20_diffuseAndSpecularColor.vp
nv20_diffuseColor.vp
nv20_specularColor.vp
R200_interaction.vp
shadow.vp

Как понятно даже с расширений - это фрагментные и вершинные программы. Ну очень интересно, действуют ли они)

 

Ну, если вопрос только в том, чтобы проверить работают ли они то все очень просто.
Распакуйте пак с сохранением каталогов. В текстовом редакторе запишите в каждую из фрагментных программ какую-нибудь гадость - ну там, "Превед медвед", например, сохраните, упакуйте пак заново. Замените пак

 

Пробовал, но только с одним из файлов. Результата не увидел, возможно, потому, что этот шейдер не использовался на уровне. Подскажите тогда какой из них навскидку самый популярный. Ну и как на ARB ASM лучше сделать наглядную гадость.

 

На вскидку ничего не скажу. Надо смотреть, что внутри файлов. Банально удалить из них все. Из всех. Это точно сработает и будет ясно, используются они или нет Плюс, можно будет заглянуть в консоль. Вдруг господа предусмотрели "костыли" на такой случай.

--- добавлено 30 ноя 2015, предыдущее сообщение размещено: 30 ноя 2015 ---

Проверил. Шейдеры используются и компилируются при запуске. Это видно, если открыть консоль в Doom 3 и найти фразу: ----- R_ReloadARBPrograms -----
Если, например, распаковать их в каталог base/glprogs (по умолчанию локальная файловая система имеет приоритет перед пак файлами), написать какую-нибудь гадость в одном из файлов и запустить игру, высветится ошибка в той же консоли.

 

В том и дело: я делал так, видел ошибки компиляции, но не более. То есть, так и не ясно, используется ли, например, R200_interaction.vp или же просто компилируется и потом движок про него забывает. Ваше предложение высветить Hello world хорошее, но я не понимаю, как это сделать на арб-ассемблере.

 

Вы меня не правильно поняли Фразочку в код я предлагал добавить как раз таки для того, чтобы нарушить компиляцию шейдеров. Вывести сообщение из фрагметной/вершинной программы на экране не возможно Что вы хотите я понял. Попробую вам помочь

--- добавлено 30 ноя 2015, предыдущее сообщение размещено: 30 ноя 2015 ---

Не "hello world", но все же. Похулиганим

Если хотите самостоятельно, то пошагово:

Распаковываем из пака в base/glprogs каталог *.vfp/*.vp файлы. В принципе мы будем править только один.

Открываем interaction.vfp.

Находим строки:

добавляем наше:

Опускаемся в конец. Находим:

Меняем, чтобы выглядело вот так:

Сохраняем все, что изменили-добавили.
Запускаем Doom 3. Если все сделано верно, то при компиляции шейдеров не должно быть ошибки в консоли.
Заходим в игру. Получаем замечательный черно белый Doom (это не касается "светящихся" поверхностей).
Проверялось на arb2 кодпафе. Собственно, у меня работает и при best, который, скорее всего уходит на arb2.
Если лень править, в аттаче сам шейдер.

 

@vedmysh, большое спасибо, конечно, я попробую у себя! Можно ещё пару вопросов?

Если я хочу, скажем, не чёрно-белый Дум получить, а изменить, скажем, глубину мэппинга в программе nv20_bumpAndLight.vp, мне какой параметр нужно править? Ну или... суть в том, чтобы найти и изменять что-то конкретное, что можно легко изменять и наглядно увидеть, но при этом остальные части мира остались бы такими же, как были. О целях позже

Кстати а важно ли расширение файла - от этого зависит набор поддерживаемых команд или это лишь условное разделение?

 

Не очень понял, что вы подразумеваете под глубиной меппинга. Нормал меппинг? Если да, то что подразумевается под глубиной?
Я вообще говоря не силен во внутренностях Doom3. Все что происходило последнее время делалось "на лету" скажем так.
Тут проблема в том, что Doom3 очень скуден на "материалы" и как я понимаю практически все освещается однотипным пиксельным шейдером, меняются только кодпафы. А где-то так и вообще шейдеров наверное нет, а есть регистр комбайнеры. Не знаю. Поэтому сходу предложить то, что можно было бы поправить, а все остальное осталось бы прежним не смогу.
Расширение файла не играет роли. Шейдер может находится и в txt файле. Важно содержимое. Но само имя файла безусловно где-то есть. Либо "захардкодено" внутри самой игры, либо присутствует еще где-то в ресурсах, которые игра читает при старте. Он ведь берет вполне конкретные файлы при запуске. Вполне возможно, что перечисляет все, что находится в папке glprogs. А затем, возможно, есть файлы свойств-материалов, которые назначают тот или иной шейдер на ту или иную поверхность в игре.

 

@vedmysh, спасибо, всё понял. Буду думать)

Под глубиной мэппинга я подразумевал силу эффекта bump-mapping, если так можно выразиться... Знаете, как это бывает, когда едва заметны выпуклости, а можно настроить, чтобы они были очень хорошо видны. Не знаю, каким образом это технически достигается)

 

В случае классического нормал меппинга боюсь ничего поделать нельзя.
Посмотрите в сторону parallax normal mapping/parallax occlusion mapping:

http://www.fabiensanglard.net/bumpMapping/index.php