Еще у HikeR`а есть репозиторий И в плане подхода к работе он посимпатичней предыдущих двух.

Он публичный? Если да, то можно ссылку?

Я ее потерял. Где-то в этой теме должна быть. В то время был публичным, не знаю как сейчас.

на гитхабе за бесплатно все публичное.
но там все очень "личное", на совместную работу не рассчитывалось, хе-хе.

С дуру добавили второй. Естественно, надо делать один в корневой директории, а не плодить кучу.

Впрочем, в том репо уже свалка, которую хз кто будет разгребать.

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

ОС Windows 7x64.
Пользуюсь этой информацией.
Установил DirectX SDK June 2007.
Установил DirectX SDK June 2010.
Пропустил OpenAL Redistributable, не нашёл.
Установил Visual Studio 2010 Professional.
Установил Visual Studio 2010 Service Pack 1.
Что делать с EAX.dll не понял.

Чтобы убедиться в том что исходники те самые, скажу точный размер папки XRay: 48 725 964 байт (46,4 МБ).
При помощи батника mount.bat создал локальный диск Х. Туда поместил папку XRay. Запустил VS 2010 SP1. Открыл "X:\XRay\xr_3da\XR_3DA.sln". Прошло несколько минут после того как весь проект загрузился. После правой кнопкой мыши по Solution\Configuration Manager из выпадающего меню выбрал Release после нажал Close. И правой кнопкой мыши по Solution\Build Solution.

Итак, пробую собрать чистые исходники без всяких изменений. Но компиляция не проходит. Выдаёт такой лог.
Вопрос: что не так делаю? Прошу помощи в решение данной проблемы.
Заранее большая благодарность!

X_Starter_X, оно же тебе написало что не может открыть файл т.к. его не существует по указному пути:
"x:\xray\xr_3da\xrgame\../stdafx.h(18): fatal error C1083: Cannot open include file: 'dplay8.h': No such file or directory"
Так что ищи файл и проверяй корректность пути.
PS: Аналогично и с другими "Build FAILED.", я быстро просмотрел лог - вроде все они связанны с отсутствием файлов.

X_Starter_X, я скидывал ведь доку.

STALKER2011x, то есть исходники всё же не те?
MegaNub, Если ты про VK Docs, то "Данный документ доступен только его владельцу."

dplay8.h доступен только в "DirectX SDK June 2007". а у вас в проекте пути к какому DXSDK указаны?

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

HikeR, C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\
Значит вот оно что. Придётся менять на 2007?
STALKER2011x, ога. Файлы нашёл, но не указан путь.

по-моему, на xp-dev весь проект собирался с 2010-м сдк, а 2007-й был нужен только для отдельных подпроектов (xrDXT и что-то сетевое). вот где ругается, там и меняйте.

Берешь и распаковываешь ехе от 2007 и берешь недостающие хедеры . Или возьми с битбакета -там архив уже готовый(недостающие файлы в depr/filename.h )

он уже

HikeR, действительно. Прописал директории до 2007, ошибки по не найденным файлам прекратились. Спасибо !
Но возникли другие ошибки:


Даже такое есть


Насчёт второй ошибки ясно, так как в папке ещё нет xrCore.lib. А вот первое, что за новый мутант из зоны ?

ну первая и вторая ссылка в гугле же по этой ошибке. конфликт между старыми DXSDK и "новыми" Platform SDK.
пути к DX должны быть на самом верху списка, то есть самые первые.

Кстати, вот набор конфигураций проектов и адаптированых исходников под VS2012.
Проблему с путями я там решил глобально Все заменил на переменные окружения, которые можно редактировать в файле xray_pathes.reg или-же прямо в реестре. Получается при добавлении новой папки инклудов не придется по десятку проектов в настройки лазать.

alpet,опять велосипедите-уже сделано

Опять я что-то пропустил? Смотрю в нынешних ревизиях, в каждом *.vcxproj файле можно найти именно прямые включения путей вроде "X:\trunk\xray\xrLua\src;". Может подскажете, как за 20 секунд для всех проектов в VS2012 можно заменить все пути к инклудам и либам?

Уже сделано,смотрите на bitbucket репо.
Там уже все настроено.
Выделяете проекты мышкой и в свойствах редактируете.
Инклуды,по сути одни и теже.Главное настраиваете относительно SolutionDir

Так мало-ли где ещё есть переделанные варианты с конфигурацией У меня рабочая копия с xp-dev, с уже сложившейся структурой папок и как я понял на этом репозитории сейчас большая часть народа сидит. В целом все устраивает, надеюсь со временем получится разделить проект на необходимые бранчи. Полюбопытствовать-бы у Григоровича, под какой лицензией допустимо выкладывать исходники вообще на открытом репозитории )

alpet
Занимайтесь чем,хотите если времени своего не жалко.

На xp-dev,нет возможностей bitbucket'a,но разве вам объяснишь...


Всё,не хочу на вас время свое тратить

С тех самых пор как начал играть на динамике на широкоформатном мониторе меня преследуют ужасы "глючных теней по углам экрана"
r2_sun_near_border 1 проблему устраняет на 80%, а хочется чтобы на все 100
Расширить диапазон значений для r2_sun_near_border можно? Или значения больше 1 будут таким-же идиотизмом, как если параметру вероятности ставится значение выше 100%?
Может быть проблему уже решили, а я страшный слоупок?

и какие же возможности битбакета помогают менять пути к инклюдам?

Шутку оценил-смешно
Удосужтесь почитать выше на пару постов,и вы прекрасно поймете о чем шла речь

я прочитал, все равно не понял.

1) Смотрю в нынешних ревизиях, в каждом *.vcxproj файле можно найти именно прямые включения путей вроде "X:\trunk\xray\xrLua\src;"...
2) Уже сделано,смотрите на bitbucket репо.

смотрю первый попавшийся проект в оригинале:


везде использовались относительные пути. поэтому не совсем ясно, зачем было менять их на абсолютные, и что именно было сделано на битбакете (отредактировали абсолютные обратно на относительные?).

p.s.
хотя я подозреваю, что "жесткие" пути к Lua встречаются только в luabind-е, там более элегантно было сделать затруднительно.

Самые свежие студии создают дополнительно файлы *.vcxproj, в которых есть дополнительные строки типа:
<IncludePath Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">X:\trunk\xray\xrLua\src;X:\trunk\3rd party\FreeImage\FreeImage\Source;... ещё килобайт текста )
И вот туда в нынешнем транке на xp-dev занесены прямые пути к папкам с DirectX SDK. Который у меня например совсем в другое место поставлен, и так-же может в другом месте находится у программистов с 32-битными системами.
В ранних студиях было проще, т.к. подобные настройки были глобальными для всех проектов пользователя. У меня теперь практически все настройки заменены на подстановку переменных окружения, что выглядит компактнее:
<IncludePath Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">$(IncludePath);$(DX9IncludePath);$(XrayIncludePath);</IncludePath>

Подождите,я от относительных путей не отказывался-и не призывал к отказу от них.
Я переписал пути "выхлопа","инклудов" и "либ",на пути относительно солюшена.

Под возможностью bitbucket ,по сравнению с xpdev я имел ввиду:
Гораздо проще форкать(+иметь приватные репозитории)
Ну и следовательно,если произведена правка,нет смысла отписывать здесь,можно сделать pull request

По очевидным причинам,смысла пересоздавать репо где-то еще,я считаю дурным знаком.


Опять вы изобретаете велосипед.
Есть такая вещь как свойства проекта-можно написать одну конфигурацию и прописать её во все проекты.( до 2010 студии это файлы .props,после .vsprops)

И никакой реестр редактировать не надо

т.е есть стандартные средства(см. вкладку "Диспетчер свойств"(Property Manager))

файлы, согласен, создают студии, а вот инклюды прописывают люди, там было в любых студиях. и в данном случае не вижу проблемы в абсолютных путях к 3rd-party либам, диск X: и так везде задан как выходной для всех проектов.

это не проще, а неправильно в корне, с чем и столкнулся народ при использовании двух разных версий DXSDK.
впрочем, использование настроек родительского проекта плюс *.props до сих пор заменяет "убранные" глобальные настройки.

и кроме этого плюсов более не обнаруживается. по сути, на первоначальный вопрос (как за 20 секунд для всех проектов в VS2012 можно заменить все пути к инклудам и либам?) можно было ответить одной строчкой:

или, при отсутствии данных утилит воспользоваться


я просто спросонья подумал, что речь идет об обычных путях к файлам.


... обычный холивар на предмет SVN vs Git vs Merurial, все понятно ;)

Дабы не было срачей по поводу путей в проекте разрабы хрея давным давно использовали моунт папки и всем было хорошо и у всех она была под буквой Х и все пути(кроме директх) у всех одинаковые были и не было ни с чем проблем. Не проще ли было вкинуть директх в проект и в корне сделать батничек на моунт папки?

Так уже...
Собственно вот правки которые я отправлял в основную ветку

+Там еще человек(судя по аватарке,с нашего форума) фиксил(в том числе и мои ляпы)
Собственно это и даст возможность собирать под новыми студями,с новым DXSDK

Посему,я повторюсь,уже давно все сделано(адаптация под новые студии).


Честно говоря,предпочитаю первые 2 системы.
Но тут речь идет просто о многочисленном дублировании одного и того же кода.

upd:Посмотрел репо:
Оказывается nick9 вернул обратно диск Х

Вот собственно последняя правка с диском Х и со всеми 3dparty библиотеками(в том числе и DXSDK(with deprecated headers and libs))

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

но никто более этим дублированием не озаботился, что уж говорить про "дублирование репозиториев", которое в случае распределенных CVS совершенно нормальное явление.

Именно поэтому я предлагаю децентрализованный bitbucket репо

эмм... под "распределенными" я и имел в виду "децентрализованные", то есть отличные от SVN.
потом, при текущих методах работы в обоих указанных репозиториях для них прекрасно подошел бы и древний CVS. для "все в кучу" выбор системы не принципиален, разве что только учитывать ситуацию "недовольные разрабы прикроют репо".

Не буду спорить, это тоже решение. Но мне чаще всего не хочется трогать файлы проектов. Например, вывод бинарок у меня происходит не в x:\binaries, а в одну из папок с копией игры - сравнительно чистой версии или с установленным модом. Менять время от времени переменную окружения XrayOutput, мне все-таки кажется изящнее подход

для этого вам пришлось перелопатить все файлы проектов, которые "не хочется трогать".
чтоб совсем не трогать вариантов масса:
- запустить батник, копирующий полученные файлы в нужное место
- X:/binaries сделать симлинком на нужный каталог и не трогать окружение
- так как игре совершенно пофиг где она лежит, достаточно изменить путь к $app_data_root$ в fsgame.ltx, чтобы указать каталог хоть с чистой версией, хоть с испорченной модами

p.s.
вот последнее по какой-то неведомой причине было неизвестно разработчикам Lost Alpha, которые впулили требование админских привилегий для запуска (!!!) игры.

Не работают они в моем случае, или потребуют лишние секунды времени. Т.к. в разных папках bin находятся разные файлы конфигурации и сборки проекта Lua-перехватчика. А мне очень нравиться, что нажал в VS кнопочку "Start debugging", и все поехало без всяких копирований. Так или иначе с выставлением переменной окружения телодвижений получается пока минимум.

С админскими правами сурово, может они драйвер какой запускают или диск читают напрямую? )

о каких секундах идет речь, если пересборка проекта после "выставления переменной окружения" (изменение выходного каталога) занимает десятки минут?

админские права нужны чтобы писать в Program Files, ну никак мод не будет без этого работать. это вместо использования %LOCALAPPDATA% в конфиге.

1. Так переменную я выставлю один раз в неделю допустим. А потом неполных пересборок будет десятки и сотни, часть из которых на моей системе довольно быстро завершаются. Зачем после этого ещё и копировать каждый раз файлы? Студия знает что надо по команде "Start Debugging" запускать цель xr_3da.exe из папки $XrayOutput, равно как и то - куда эту цель компилировать. Мне ничего другого на момент реализации просто и в голову не пришло Был вариант с переименованием папки с игрой, но я обеспокоился что так запутаюсь попросту.
2. Такие вещи реализуются инсталлятором проще - например Inno Setup может выставить разрешения для папки нужные, чтобы любой в неё мог писать. Хотя в NLC6 вродь как предлагается по умолчанию ставить в C:\Games\ или подобный каталог, давно уже инсталлер не запускал.

1) "надо, так надо, хочешь убить — значит есть за что" (С)

2) такие вещи реализуются путем штатного использования пользовательских каталогов, априори доступных для записи, а не запуском от админа.
это клиенту Steam-а простительно в случае установки в Program Files писать туда вообще все. и то только потому, что он не меняет никакие дефолтные права, а держит запущенным мелкий сервис с повышенными привилегиями, он то и выполняет все файловые операции.

Никак не пойму зачем папка depr нужна? При сборке в логе выводилось что не может найти некоторые файлы из папки depr, но если посмотреть на имя файла то один в один что лежат в папке includes. Или я что-то упустил и не прав?

У сорцов зависимость-directPlay
Он начиная с 2008 года не входит в поставку DXSDK

Tron, файлы в includes и в depr разные?

Тем временем уже 81 ревизия. Добавил управление текстурами в Lua, как это возможно с участием моего перехватчика для 1.0006.
Кто-то помнится мечтал делать асфальт более темным, если дождик идет, так теперь это просто:

Единственное, такие глобальные текстуры надо возвращать в адекватное состояние при загрузке сейва. На тот случай если движок не догадается сам выгрузить между перезагрузкой уровня.
Исходники очень многое открывают в плане таких мелких хаков: надеюсь скоро можно будет рисовать на текстурах и смешивать их, а так-же передавать параметры настроек в шейдеры.

alpet, можешь сделать команду для перезагрузки текстур прямо в игре?

А что я до этого сделал? Этому трюку уж пару лет будет.

alpet, более темный асфальт?
Я не совсем понял, как именно можно управлять ими. Подскажи, если не трудно
P.S: Я про перезагрузку всех текстур, как в сдк

Так ведь резко будет меняться - смысла нет.

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


Это уже забота текстурщиков, наделать десяток градаций яркости асфальта По крайней мере пока не получиться напрямую surface редактировать, затемняя или смешивая с какой-либо маской.