Need For Speed III Modern Patch (HD + Widescreen + Portable)

Need For Speed III Modern Patch (HD + Widescreen + Portable)
Страница проекта: http://veg.by/go/nfs3ru

Я не буду здесь описывать все изменения, поскольку их слишком много. Опишу лишь основные тезисы. За подробностями обращайтесь к файлу readme.txt.

— Адекватная поддержка широкоформатных и больших разрешений — игра без проблем работает на 1920×1200 и других разрешениях без искажения пропорций изображения.
— Улучшена графика машин — на максимальных настройках у других машин текстуры в 2 раза лучшего качества, всегда крутятся колёса, никогда не исчезают зеркала и другие элементы (это происходило из-за подгрузки худших моделей при наличии 3 и более машин в кадре).
— Улучшена дальность отрисовки — на максимальных настройках в зеркале объекты не пропадают так рано как раньше.
— Режим DX6 поддерживает эффект тумана — ранее эта возможность была эксклюзивной только для видеокарт 3dfx Voodoo2 и эмуляции Glide API.
— Улучшена поддержка Voodoo2/Glide — в этом режиме в игре доступен эффект тумана, работоспособность Glide API обеспечивается враппером nGlide 1.04.2.
— Переносимость — игра больше не лезет в реестр за настройками, все системные настройки хранятся в ini-файле рядом с исполняемым файлом игры (он должен иметь такое же имя как и запускаемый exe-файл).
— Добавлено несколько оптимизаций. Например, игра не делает копию музыкальных файлов при каждом старте и читает их сразу их исходного каталога, что экономит время и 10 мегабайт ресурса вашего SSD на каждый старт.
— Исправлено несколько десятков ошибок и недоработок оригинальной версии. Например, индикация загрузки теперь намного более плавная.

Установка:
1. Скопируйте каталоги FEDATA и GAMEDATA с оригинального диска в новый пустой каталог.
2. Извлеките содержимое архива nfs3_vegmod.7z (1.3МБ) в этот же каталог, с заменой файлов.
3. Готово!

Скриншот в широкоформатном разрешении 1280×720:


Оригинальное сообщение:
Взялся я тут патчить оригинальный NFS3. Добавил поддержку больших разрешений, пофиксил баг про то что осталось меньше мегабайта свободного пространства (хотя на самом деле его завались), для драйвера d3d добавил поддержку 32-битного цвета (в игре многие вещи с 32-битным цветом выглядят значительно лучше), для драйвера voodoo2 поддержку разрешений вплоть до 1600×1200. Сейчас вот работаю над добавлением поддержки широкоформатных разрешений без искажений пропорций, если всё будет хорошо, то и 1920×1080, и 1920×1200 будет поддерживаться. Ещё хотелось бы устранить баг с зависанием на многоядерных системах.

А теперь вот подумалось, а может взять лучше за основу NFS4, но попробовать исправить в нём то, что не нравится, и сделать так как это было в NFS3? Расскажите, чем вам нравится NFS3 и не нравится NFS4, и наоборот. Карты вроде как от NFS3 там есть вообще без изменений.

И ещё. У вас в NFSIII работает сетевая игра? У меня на Windows 7 x64 при попытке создать игру или подключиться ничего не происходит. Надо будет проанализировать эту проблему, но может уже кто-то знает ответ.

 

Начала прочитал

 

@VEG, Это кажется не простой фифа, а FIFA World Cup 2002, Я сначала прочел в нете что там был dx8, но люди плевались и говорили что глючной. Саму dll сначала с инета скачал, где то с зарубежного сайта, а потом уже и саму игру, правда пиратку от фаргуса, но сверив dll-ки, они одинаковые.. В архиве все рендереры с игры

 

У меня в коллекции всего 3 рендерера dx8 (из FIFA2002, из MCO и из MCO обновления), выбирать особо не из чего. Качаю разные игры EA тех времён периода 1997-2002 годов выпуска включительно. Очень во многих используются те же библиотеки и форматы файлов. Но одна игра меня сильно удивила своей структурой — очень похоже на NFS3. И таки да, я нашёл там массу свидетельств и останков от NFS3. Интриги добавляло то, что эта игра вышла до релиза NFS3! А самое смешное, что эта игра — Ultimate Hunt Challenge. Это охота! Представьте себе. Сейчас у меня есть только демка (и там следов NFS3 более чем предостаточно), полную версию удалось найти, качаю.

А вообще оказывается, что такие игры как Крикет, Гольф и Бейсбол очень сложно или вообще невозможно найти в полных версиях. Ни на каких торрентах или ещё где-то нет. Полностью забытые и никому ненужные игры. Печально.

 

Пожалуйста, приведите номера версий.

 

Так, насчёт даты релиза Ultimate Hunt Challenge я погорячился. Файлы демки датированы 1999 годом, а я прочитал 1998, поздно было. Тот образ что я скачал — это Second Edition 2000 года. Оригинальную версию не удаётся найти, только демки.
Какие вещи остались от NFS3? Судя по всему, они целиком позаимствовали код всего меню, и потом модифицировали его. Оружие и персонаж охотника вращаются в игре как тачки в NFS3 =) Шрифт тот же. Прямо внутри исполняемого файла меню можно найти большое количество строковых констант, которые остались от NFS3 (про копов, про игровые режимы типа Knockout и т.д.). Файл с курсорами вообще не изменился — игра использует тот же файл. Также среди файлов можно найти файлы позиций элементов HUD из NFS3 (забыли удалить).
Любопытен набор файлов рендереров и вариаций eacsnd.dll. У eacsnd.dll есть какой-то странный альтернативный вариант xacsnd.dll — интерфейс у них общий, видимо они как-то по-разному умеют выводить звук. Помимо обычных версий в игру включены и отладочные версии, правда, без непосредственно отладочной информации из *.pdb файлов.

@BrainRipper,

8193.8.21.8503 / 2001.08.15.2137 — из Fifa 2002
8193.9.5.5682 / 2001.09.05.1632 — из MCO
8193.17.7.4951 / 2001.11.07.1357 — из MCO Update

Ещё вам может попасться dx8z.dll из TCM2003, но на самом деле это DX7 с изменённым именем файла. Там ещё информация о версии испорчена немного. Очень похоже на то, что собирал файлы для TCO2003 человек, который не знал, как правильно собирать эти рендереры. Возможно, DX8 он не смог собрать, поэтому вставил на его место DX7, который тоже собран не совсем правильно =)



Глядя на даты хорошо видно, что разработку Thrash API остановили к концу 2001 года, и в 2002 году похоже что только одна игра не переехала на EAGL и осталась на этом API (TCM2003), соответственно кто-то собрал пару немного устаревших версий DX7 в 2002 году.

Кстати, у кого есть идеи, что кодируют в номере версии вот такие цифры: 8193.8.21.8503? Я пока что нахожу их бесполезными, ибо в File Version закодирована дата и время, что полезнее. Также в мета-информации, возвращаемой thrash_about, есть номер версии API — его я тоже себе в имена файлов добавил. А вот эти 8193.8.21.8503 чем полезны не ясно =)

--- добавлено 15 окт 2016, предыдущее сообщение размещено: 15 окт 2016 ---

Ещё касательно Ultimate Hunt Challenge. Там прямо в Credits указано, что над игрой работала часть команды NFS3, и перечислено порядка десятка человек. Сами по себе Credits оформлены больше в стиле NFS4. В корне версия Thrash-рендерера dx6 идентична версии из NFS4, при этом есть ещё отладочная версия (опять без файла отладочной информации, так что толку мало). То есть на самом деле игру делали на основе NFS4, но в Credits упомянули именно NFS3. Полагаю, всё дело в том, что NFS4 изначально разрабатывался как NFS3 SE Блин, вот бы найти какую-нибудь раннюю бету из этих времён. Стоит заметить, что игру форкнули ещё до релиза NFS4, потому что структура каталогов и останки именно от NFS3, то есть форк был сделан тогда, когда проект ещё был гораздо ближе к NFS3.

 

В общем поизучал я DX8 тот что в FIFA 2002 и MCO. В FIFA 2002 он использует пиксельный туман, а в MCO они не удаляли туман, они просто решили заменить его на вершинный, при этом при переписывании они не заботились об обратной совместимости — им надо было чтобы оно в одной игре работало, а не во всех старых

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

Знаю, что при вершинном тумане можно любую формулу для вычисления тумана задать. Но там заданы те же формулы, которые используются по умолчанию и для пиксельного тумана. Кажется, что не должно быть разницы, хотя я не уверен =)

Кто-нибудь может точно сказать, есть ли какой-то профит с вершинного тумана? =)

 

Включается быстрее.
А, если серьёзно, то вершинный туман рассчитывается на этапе трансформации и освещения.
Табличный/пиксельный рассчитывается при текстурировании и работает с текстурами.
Насчёт "любую формулу" - увы. Железо поддерживает только три (linear, exp и exp2), хотите чего другого - извольте ручками...

 

Значит там не вершинный туман и я не разобрался в терминологии. Там для каждой вершины прямо в коде идёт вычисление по соответствующим формулам. То есть ручками. И записывается значение. И кажется я понял, что за значение оно записывает. Походу оно берёт цвет, указанный для вершины, и смешивает его с цветом тумана в нужной интенсивности. И у этого есть подтверждение — когда я заменяю формулу на вывод константы 0 (максимальная густота тумана), это влияет только на цифры обратного отсчёта, у которых нет текстуры! Не очень много смысла, когда этот цвет не видно под текстурой. Возможно, там каким-то флагом можно разрешить хитрое накладывание цвета на текстуру?

Или же есть ещё вариант, что они написали этот код строго под один формат вершин, а NFS3 использует другой формат вершин, с которым этот туман работает неправильно. В первых Thrash API был толко один формат вершин, но где-то в DX7 появился дополнительный с какими-то дополнительными полями (я не разбирался в нём, так как игра не использует это). В пользу этого говорит и то, что при переписывании с пиксельного тумана авторы не парились о совместимости и не повторяли старые трюки для совместимости рендерера со старыми форматами параметров, которые применялись во времена Thrash API v104-106. То есть совместимость со старыми игрушками была сломана ещё на этапе приёма параметров, возможно и старый формат вершин объявлен легаси, они просто не успели полностью убрать его поддержку из рендерера.

--- добавлено 15 окт 2016, предыдущее сообщение размещено: 15 окт 2016 ---

Кстати, там видно ещё один тип тумана, помимо туманов по стандартным формулам, где можно передать разную густоту для разной глубины (256 позиций), и таким образом, можно сделать туман любой формуле из кода игры.

--- добавлено 16 окт 2016 ---

UPD. Насчёт форматов вершин разобрался — нет, оба поддерживаемых формата ничего не ломают. Там второй формат добавляет возможность указать дополнительную пару текстурных координат.

Подозреваю, что там должно быть что-то типа texture blending, и чтобы указанный для вершины цвет использовался вместе с текстурой, нужно включить какой-то режим смешивания. И это уже должно быть в рендерере, просто нужно добавить вызов нужного метода, а перед этим его нужно вычислить

--- добавлено 16 окт 2016 ---

Документация говорит, что если хотите делать свой гибкий вершинный туман, то нужно нужную густоту записывать в альфу specular color, а цвет тумана будет браться из значения, установленного соответствующим SetState. Но, судя по всему, dx8 делает иначе. Он зачем-то смешивает и цвет с цветом вершины, а specular color вообще не трогает. Возможно, в Direct3D8 это как-то хитро настраивается, и авторы применили что-то подобное здесь. Не может же быть, что они так много кода настрочили и не проверили, работает ли оно =) Найти бы как активируется другой режим смешивания. А для этого надо понимать, как такое можно сделать на DX8.

Хотя переделать то что есть в вариант со specular color, как говорит документация, в принципе не сложно. Ладно, завтра ещё гляну. Заодно и выравнивание текселей сделаю, уже разобрался где что.

 

Наверно ПК-видеокарты обзавелись аппаратным T&L позже (в 1999), чем вышла игра NFS III (в 1998).


Хмм...
Хотя откуда в игре dx8 взялся?
Шейдерный туман мог бы разгрузить центральный процессор от перемалывания вершин...

 

@daemolisher, dx8 c NFS MCO (2001)

--- добавлено 16 окт 2016, предыдущее сообщение размещено: 16 окт 2016 ---

@VEG, Я думаю что они писали пиксельный туман, наверное изза того чтобы более гибко котролировать наложение тумана на обьекты. Наверное для MCO или другой игрушки это было необходимо, например не затуманивать или наоборот или даже придавать больше тумана на какие-то обекты (возможно какие-то панельки на экране). С вертексного тумана вижу только смысл в Range Based Fog. Возможно он был бы и полезен, но в гонках не такой и большой туман или fov чтобы видеть разницу, зато возможны не сильные проседания, хотя с железом того времени может и сильные.

И еще, в dx8 отключался только пиксельный туман (35) но нигде не включался через setrenderstate, но зато о вершинном тумане (104) там ничего кажеться небыло, точно уже не помню так как пишу по памяти. Зато в старых рендерерах пиксельный туман включается и выключается, а вершынный всегда выключается. Выключение вершинного тумана стоит всегда вместе с включением/выключением пиксельного наверное из-за того что бы всегда легко можно было поменять с пиксельного на вершинный.

Кстати можеш там легко поменять на вершыный (в dx7 поменять где setrenderstate(35, 1) и setrenderstate(140, 0), наоборот (35, 0) а (104, 1)). Ну а в dx8 просто setrenderstate(35,...) на (140,...)), но еще добавить setrenderstate(48, 1) для range based тумана. Но незнаю заработает ли и сомневаюсь что будет лучше виглядеть. Но тут еще с sdk видно следуеще, но так далеко я не заглядывал так как в 3d прогр. я ламер

Спойлер

If your application does not use Direct3D for transformation and lighting, the application must perform fog calculations. In this case, place the fog factor that is computed in the alpha component of the specular color for each vertex. You are free to use whatever formulas you want - range-based, volumetric, or otherwise. Direct3D uses the supplied fog factor to interpolate across the face of each polygon.

--- добавлено 16 окт 2016 ---

Посмотрел в правленый мною dx8, и вспомнил что я тоже добавил по примеру dx7 (140,0) для таких случаев

 

@Verok, верно, про этот кусок документации я и говорил выше.

Если мы хотим задействовать стандартный вершинный туман по нестандартной формуле, мы должны густоту поместить в альфу поля specular color вершины, включить туман и задать цвет стандартными SetState, но в таком случае нужно установить для табличного тумана режим NONE.

Я теперь разобрался ещё чуть лучше в Thrash API. Там уже во времена DX7 была возможность задать массив значений густоты тумана на всех расстояниях (для 256 значений глубины), то есть по сути туман по произвольной формуле. Активировалось setstate с кодом 0x14 (20) и табличкой значений вторым параметром. Там для каждой вершины, добавляемой в буфер вершин, выполнялся однообразный код, который в DX8 был вынесен в функцию, поскольку кода стало гораздо больше и эта функция теперь отвечает вообще за весь туман, даже по стандартным формулам. Так вот, раньше там оно как раз в итоге и писало своё значение в альфу specular color, как гласит документация. А дальше оно уже само, в зависимости от переданного в Direct3D ранее цвета тумана, делает все вычисления. Но вот DX8 почему-то сам вручную смешивает цвет тумана с цветом color (не specular!) каждой вершины в вычисленной пропорции. Как результат — там где установлены текстуры, цвета этого вообще не видно.

Но ведь не просто же так это сделали. Появилось предположение, зачем такое могло понадобиться. Может быть, они хотели дать возможность использовать эффекты тумана разных цветов сразу в одном кадре?

Я вижу в DirectX3D8 SDK есть куча вариантов смешивания текстур и т.д., наверняка такой подход рассчитан на какой-то вариант смешивания, не знаю только на какой =) Или дальше уже должны быть замешаны вершинные шейдеры, но это вообще тёмный лес для меня на данный момент.

На данный момент оптимальным решением видится переписывание ручного смешивания цвета с color на простую установку альфы в specular color вершины, как гласит документация, и, что самое главное, как было сделано во всех рендерерах до этого для кастомных туманов по произвольным формулам. То есть совместимость это не ухудшит, ибо оно изначально так и было. Потом можно будет сравнить визуально и по производительности два тумана — и если вершинный туман по стандартным формулам, которые в самом последнем DX8 тоже вычисляются вручную, покажет себя не очень — то можно будет сделать как предложил Verok, задействовать стандартный пиксельный туман для стандартных формул, как это было во всех рендерерах D3D ранее.

То есть для обычных формул будет использоваться пиксельный туман, а для нестандартных формул будет использоваться вершинный туман с записью нужной густоты в альфу specular color каждой вершины в той функции, где сейчас вычисляется обычный color, который не видно.

Если кто-то знает тонкости работы с Direct3D, и знает, как могло предполагаться сделать видимым этот новый ручной туман, который пишется в обычный color вершины и смешивается тоже вручную — просьба подсказать

 

А у нас новая бетка: http://veg.by/files/nfs3/nfs3_modern_patch_beta.7z

— Решена проблема с Texel Alignment в DX8, так что теперь всё выглядит чётко, как при использовании Glide3x.
— DX8 теперь поддерживает эффект тумана. Большое спасибо Verok за исследование.
— Графические дефекты DX7 вроде чёрного полигона у старой церкви более не проявляются.
— Новые сообщения об ошибках для некоторых проблемных ситуаций: слишком длинный путь до корневой директории (он не может быть длиннее 210 символов); выбранный thrash driver не найден.

Изменения касательно тумана в DX8 повторяют логику всех предыдущих версий рендереров D3D: вместо странного вершинного тумана нового DX8 используется стандартный пиксельный туман. По сути это почти то же самое, что проделал Verok, но есть и различия: код вычисления густоты тумана для вершин также был заменён, добавлены релоки, изменённый код организован иначе.

Огромное спасибо Verok за такую отличную находку. Я, если честно, был скептичен и не планировал заниматься DX8 вообще в обозримом будущем. Но теперь добавил выравнивание текселей и постараюсь в будущем разобраться с воспроизведением видео. Также в ближайших планах касательно DX8 — получение разрешений без захардкоженных 16-битных вариантов, что уже сделано для DX6 и DX7.

Ещё планируются некоторые изменения для NFS3 и много изменений для NFS4. Следите за новостями

--- добавлено 25 окт 2016, предыдущее сообщение размещено: 25 окт 2016 ---

Исправил ссылку. Случайно ссылку на релиз вставил.

 

В DX5, оказывается, разработчики тоже писали кастомный вершинный туман. Вычисляется табличка из 256 значений, и потом эти значения записываются в альфу specular color каждой вершины в зависимости от координаты z. Там есть код только для экспоненциального тумана (его как раз и использует игра), но он не работает, не вникал почему. Скорее всего потому что надо было использовать 1/rhw вместо z для определения глубины. А ведь прикрутить обычный пиксельный туман при наличии исходников рендерера можно было за минут 10-15. Там реально всё получается очень просто, гораздо проще, чем с вершинным туманом. И работало бы.

Поскольку код тумана не рабочий, и чинить его смысла немного, а рендерер сообщает, что он умеет туман — я его исправил, чтобы он сообщал, что не умеет туман, а сам код тумана вырезал. Аналогичная проблема была в softtri — он тоже сообщал, что умеет туман, хотя там даже зачатков тумана нет. Это тоже было исправлено. Теперь nfs3.exe может спрашивать рендерер о наличии поддержки тумана нужного типа без явного указания значения FogSupport в thrash.ini. Правда, пока что параметр FogSupport=1 всё равно обязателен, но в будущем я думаю его заменить на обратный NoFogSupport, который можно будет использовать с рендерерами, которые некорректно сообщают о положительном статусе поддержки тумана. По умолчанию же игра будет полагаться на статус, который сообщает рендерер.

Проверка поддержки тумана рендерером сделана таким же образом, как проверяется, поддерживается ли туман d3d-рендерером в NFS4. То есть оно реально так задумывалось, просто рендереры не всегда следуют правилу сообщать об отсутствии поддержки тумана. DX5 и SoftTri были маленькими врунишками, хотя DX5 всё же имел зачатки тумана, так что ему можно простить

 

Новая бетка: http://veg.by/files/nfs3/nfs3_modern_patch_beta.7z

Очередной рефакторинг кода инициализации видеорежима. Я ещё не раз буду к этому возвращаться. Там ещё так и просится вырезать кучу кода, которая осталась от времён до thrash-рендереров и по сути не используется игрой. Плюс там для первоначальной установки видеорежима и последующих изменений видеорежимов используется две разные функции. Чтобы не городить тут огороды, хочу их по максимуму объединить, чтобы можно было удобнее и красивше доделать поддержку оконного режима в D3D.

Данная итерация рефакторинга этого кода (в который раз уже к нему возвращаюсь) выявила один мелкий баг: при выходе видеорежим восстанавливался дважды. Возможно, это вызывало (по крайней мере у меня) неприятную ситуацию, когда после игры с nGlide все окна становились уменьшенными до 640×480. Этот баг у меня не всегда проявлялся, но беспокоил достаточно часто и настойчиво. Сейчас несколько раз запустил игру — проблему не наблюдаю. Возможно, nGlide не нравилось то, что игра дважды восстанавливает видеорежим, и исправление этого мелкого косяка решило проблему. Косяк, кстати, возник как раз потому, что разработчики поверх старого кода инициализации наслоили новый, и новый код при выходе восстанавливал видеорежим независимо от старого. Они вместе старались Если бы они вырезали всё это устаревшее добро, то проблема бы не возникла.

Хотя, возможно, они поначалу хотели иметь возможность использовать как старую систему отрисовки, так и новую, поэтому и оставили их обе. Но в третьей части оно мёртвым грузом лежит в exe и в некоторых местах вхолостую выполняет лишние операции.

--- добавлено 26 окт 2016, предыдущее сообщение размещено: 26 окт 2016 ---

Хм, старая версия тоже теперь не глючит. В общем время покажет, решилась ли проблема Иногда она проявлялась при 100% запусков, но иногда и исчезала сама по себе, без видимой на то причины. Проявлялось только с nGlide.

 

Хах, у меня панда говорит на nfs3.exe - что вирус . Наверное нужно код как-то по другому написать. Добавил в исключения, теперь не могу проверить предыдушую бету, которую не качал

 

@Verok, на вирустотале только у какого-то Bkav детект:
https://virustotal.com/en/file/86e8...21960e40840f3935792ad3b5/analysis/1477549374/

В любом случае, это false positive. Антивирусы вообще часто не любят вручную исправленные исполняемые файлы. Или, например, файлы, которые используют продвинутые техники для написания компактного кода. Ничего не поделаешь. Они же не указывают, какой именно фрагмент двоичного кода им не понравился =)

 

@VEG, Хм, на вирустотале не проверял. Остальное я знаю, тому и пишу на вся случай

 

Юбилейная 300-ая ревизия! http://veg.by/files/nfs3/nfs3_modern_patch_beta.7z



По сравнению с предыдущей версией ничего внешне не изменилось. Лучше разобрался в коде работы тумана, поэтому написал немного улучшенный вариант кода включения/отключения тумана во время геймплея. Если бы не красивый номер ревизии, не стоило бы и упоминания

--- добавлено 27 окт 2016, предыдущее сообщение размещено: 27 окт 2016 ---

Чего я там вообще копался — думал сделать более плавное изменение густоты тумана во время въезда и выезда из регионов с повышенной концентрацией. Оказалось, что проблема фундаментальна — значение переменной, которая хранит текущее положение игрока на трассе и на которую опираются многие вещи в игре, имеет слишком большой минимальный шаг в 3D-пространстве. Число целое, дробных значений не предусмотрено. В общем, задача требует гораздо большей переделки, чем ожидалось, так что пока что отложено в долгий ящик.

 

Вышел Modern Patch v1.6.1 [2016/10/28]

• Решена проблема с Texel Alignment в рендерерах DX6, DX7 и DX8, так что теперь всё выглядит чётко, как при использовании Glide3x.
• DX8 теперь поддерживает эффект тумана. Большое спасибо Verok за исследование.
• Графические дефекты DX7 вроде чёрного полигона у старой церкви более не проявляются.
• DX7 сортирует разрешения и не выводит 640×480×16 в случае, если этот видеорежим не поддерживается.
• Небольшая оптимизация загрузки текстур: функция thrash_about не вызывается без необходимости.
• Более строгая проверка корректности используемого thrash-драйвера (рендерера).
• Новые сообщения об ошибках для некоторых проблемных ситуаций: слишком длинный путь до корневой директории (он не может быть длиннее 210 символов); выбранный thrash driver не найден.
• DirectDrawLagFix был переименован в DisableMaxWindowedMode в файлах thrash.ini. Теперь оно выключено по умолчанию.
• Добавлен новый флаг совместимости NoDwmOffForPrimaryLock в файлы thrash.ini.
• Игра спрашивает у рендерера наличие поддержки тумана. DX5 и SoftTri всегда сообщают, что не поддерживают туман.
• Рефакторинг кода установки видеорежима. Предотвращён двойной вызов функции восстановления видеорежима при завершении.

Скачать: http://veg.by/files/nfs3/nfs3_modern_patch.7z

 

Продолжаю работу над патчем. Нужен кто-нибудь, у кого DX8 работает, но не показывает салон при виде из кабины. Есть предположение, что это связано с объёмом видеопамяти в GPU. Нужно будет протестировать несколько тестовых билдов. Буду очень благодарен за помощь. Можете связаться здесь при помощи личных сообщений, или по Skype: evgeny.vrublevsky.

--- добавлено 1 ноя 2016, предыдущее сообщение размещено: 31 окт 2016 ---

Так, человек нашёлся, гипотеза подтвердилась. Так что вскоре будет фикс этой проблемы