GHOST, насколько я понял, это на случай если актор вытащит ПДА у трупа.
Что-бы в контактах не отображался.

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

В остальном жрет немного.

K.D., поправить/изменить можешь?

Первое будет исправлено в огсе - там скриптовый менеджер погоды. Второе доступно в xray-extensions уже сегодня.

Я так понимаю это связанно с тем что все это выкинуто в луа? Реально ли опять же в луа выкинуть деструктор типо destruct(секция_погоды)? Хотя больше смысла наверное имеет переработка прекеша дабы сделать его не "единым" а сделать чистку при переходе с уровня на уровень, загрузка станет чуть дольше но оперативы будет больше свободной.

K.D., сдк ещё не компилили?

Nod33eset
фигня это все, похоже.


Будет ли подобная правка на ЧН?

При очередной компиляции хохотал как сумасшедший

GSC душу дьяволу продали,чтобы выпустить сталкер что ли?

Наоборот - все в движке грузится менеджером ресурсов.


Увы, нет.


Правка копеечная, если надо, то будет доступна.

есть пара файлов tntQAVI.(c|h), которые юзаются только в SH_Texture.cpp (загрузка и рендер в текстуру). видео в AVI-контейнере, насколько я помню, это только телевизоры.

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

p.s.
еще дохлый нынче GameSpy так и просится на выброс. пока, правда, быстрее показалось сделать dll-ку пустышку, ибо вызывается она много где, плюс загрузка через LoadLibrary в неожиданных местах.

в том же направлении хотелось бы и мультиплеер отправить ("DirectPlay не нужен!" (С)). были когда-то только мультиплеерные "билды", а есть ли какой дефайн по этому поводу?

Надо бы реализовать удобную модернизацию оружия на уровне кода.
-Установка разных прицелов
- Установка и правильная работа лцу\фонаря как на подствольное
пространство, так и сбоку, тем самым сохраняя возможность поставить гранатомёт,
либо подствольный дробовик.
- Установка тактических ручек.
- Поддержка около десяти анимаций на любое действие оружия (перезарядка,
клин, анимация при простое игрока (аля бездействия).
- Поддержка смены всего худа в зависимости от надетого костюма (ну и худ рук
как в ЧН\ЗП)
- Возможность сортировать инвентарь по вкладкам (+ по степени износа)
Оружие-Броня-Медикаменты-Еда-Квестовые предметы-Патроны-Артефакты-Разное

Угу, очень даже надо, для ЧН вполне будет полезно, а то там вечно перегруженный двиг. Вообще хотелось простые правки хотябы, дублировались на других платформах, по мере возможности конечно.

Теперь есть не только выгрузка текстур из G-буфера, но и дин. моделей?
Как часто будете выкладывать новые билды?

AVI в релизе не используется. Совсем.

Вот думаю..запушить ли адаптацию под 13ую студию,или не стоит..
У меня Git Репо,поэтому напрямую в Hg я коммитить не могу

Я почти собрал. Только не всё собирается, в xrSoundB например жалуется на функции из vorbisfile..

Я знаю я наркоман) но кто может помочь с запуском Battlefield 4 на Win XP. Пропатчил экзешник, начал кидать дллки.
Споткнулся после api-ms-win-core-processthreads-l1-1-0.dll
dwmapi.dll выдает ошибку "точка входа процедуры _except_handler4_common не найдена в msvcvrt.dll
нашел совет заменить dwmapi.dll на user32.dll теперь после dxgi.dll выдает __cxxframehandler3 не найдена в msvcvrt.dll

Здесь разве обсуждается BF? Раздел форума вроде как сталкерский, мм.. походу я ошибся разделом. Поставить бы тебе минус в репу за такое..

P.S.: Наркоман говоришь? Так компиль SDK

Тема потходящая потому что патчил я как abramcuper лостальфу. И наркоманы здесь именно

Извините меня конечно за грубость, но у Вас случай клинический и врятли он будет поддаваться лечению.

Найди в инете адаптацию дх10/11 под ХП. Вроде были такие. Все же в ЛА был рендер под дх9, а в БФ4, как я понимаю, только дх10/11.

я вот тоже предлагаю перекатиться в гит, тем более что можно сконвертить репо hg->git.
сегодня собрал все внешние либы в один солюшн, всё компилится с чистого листа нажатием одной кнопки мечта нубов нужно только красиво исправить boost::throw_exception / std::terminate.
надо бы запилить, правок никаких в самом движке пока не делал, т.е. у меня студия 2005-я нужна. если залить в репо, то можно объединить правки.
UPD: вот

libogg 1.1.3, libvorbis 1.1.2, libtheora 1.0a6 и тем более FreeImage 3100 можно смело обновлять до последних версий.
для theora, правда, нет готового солюшена для 2010-й студии (а более ранние конвертируются криво), но его можно утянуть из 1.2_alpha, либо из их SVN-а.

[hr]
немного скучной статистики. я как-то писал, что количество дубликатов файлов с одинаковым названием и даже содержанием немного зашкаливает, но теперь могу дать (почти) точные цифры. базовым является каталог /xr_3da/xrGame, содержит >1.6К файлов (без учета вложенных каталогов).

vs xrAI: 224 всего, 118 одинаковых, 30 чуть отличающихся.
последние отличаются как числом пробелов, так и правками с обоих сторон (типа добавление _s к ф-ям чтобы компилятор не ругался, обертывание части кода в #ifdef AICOMPILATOR). такое чувство, что разрабы сами потерялись в своих каталогах, ибо имеются чисто компиляторные дейфайны в самом xrGame

vs xrSE_Factory: 193 всего, 87 одинаковых, 75 разных. тут ситуация аналогичная, разве что добавились инклюды luabind-а в xrSE (неясно накой), кучка диффов в условиях (if(check) => if(!check)) и совершенно разные ai_space*.*. а, еще дефайны версий отличаются.

xrAI vs xrSE_Factory: 68 одинаковых и пара файлов где закоментарены дефайны (вероятно, лениво разыменовывать было). при этом первый требует второго в виде dll-ки.


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

p.s.
можно отнять от циферок 2-5 файлов, всякие stdafx и иже с ними.

я ставил перед собой задачу собрать все либы без правок движка - сделать базовый солюшен, с которым можно работать. ориентировался, примерно, на 2005 год (хотя что-то мне подсказывает, что у них либы были ещё древнее).
по уму, конечно, от некоторых либ надо было бы избавиться ещё в 2006-2007.

UPD: добавил ColorPicker, не смотрел, правда, зачем он вообще нужен и почему нельзя использовать стандартный виндовый диалог.


забавно, что некоторые из дубликатов даже не используются, как например, trivial_encryptor в xrCore.
возможно, результат неудачного рефакторинга.

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

перечисленные огги/ворбисы не требуют правок движка )


только для сдк-шных редакторов . в борланде своего контрола нет, а вызывать виндовый не умеет (или не было тогда такого).


подобное — да, но этот круче.

Кто-нибудь кроме меня пытается собрать SDK?

а чего там пытаться? там все собирается, но ни черта не работает )

Собрал только xrCoreB, xrParticlesB, xrEPropsB, editor.bpl, остальное не собирается. Ну чуствую что я жестко туплю)

Вот например xrSoundB, не пойму что не так, vorbisfileB.lib и eaxB.lib есть, конвертировал с помощью coff2omf из vorbisfile_static.lib и eax.lib соответственно.

из мануала: COFF2OMF does not convert .OBJ files. а ваши *_static.lib ни что иное как куча склеенных .obj-ей.

пересобирайте все что можно как динамические библиотеки, вместо coff2omf лучше юзать impdef натравив его на полученные dll-ки (.def файл можно потом подправить ручками), полученные .def-ы добавьте в проект вместо .lib

p.s.
тьфу, implib -> impdef, это для тех либ, у которых нет .def-файлов в комплекте. у оггов/ворбисов они есть.

Ты бряки убирал? Их там дохрена стоит

не понял о чем речь.

Debug Breakpoints

в релиз собирал, а там их их нет. вроде писал как-то, с релизом небольшой головняк в виде непроставленных #ifdef DEBUG в декларациях (при этом в определениях они есть).

p.s.
самое главное — не включать CodeGuard. иначе он вынесет весь мозг воплями "тут полный кошмар, а не программа на плюсах" ))

Двигло всё-таки собирается с статическим рантаймом (/MT). Таким образом можно избавиться от необходимости тащить за собой VС Runtime нужной версии. При этом размер файлов не особо возрос. Вопрос к тем, кто может ковырял эту тему - можно ли всё-таки сделать нормально работающий EAX 2.0, чтобы с бубном не плясать при использовании разных звуковых?
Для проверки звуковых харакеристик есть утилита ALCapsViewer. Её надо положить в папку, где лежат EXE/DLL-файлы игры и запускать оттуда.

Нет. Слишком много разных операционок/дров/звуковух. Но можно свести пляски к минимуму, если:

1. Чуть поправить (хексом или исходниками) xrsound.dll, заменив в нем слова software и hardware на любую абракадабру. Тогда обнаружаемость EAX значительно повышается.

2. Дать пользователю конфигуратор с пятью базовыми вариантами комбинаций openal/dsound дллей, которые ему надо будет единожды перепроверить на мапе точно имеющей звуковые зоны.

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

[/quote]
xstream ?

Разве на бинарниках КД обнаружаемость EAX не 100%?

В ридми об этом не сказано. Проверил build 5578, действительно EAX работает. Может тов. КД сам напишет, что он исправил, и на сколько в целом стало совместимее?

Дык сделал ровно то же самое, что делал ты порчей строк. Поскольку в каком-то лохматом году eax на встроенных звуковухах с дровами AC97 глючил, то разрабы вставили проверку на эти звуковухи с отключением eax для них. Встроенные карты, как правило, имеют название девайса Generic Software или Generic Hardware, проверка на строковый идентификатор осуществляется через strcmp, так что если попортить строку, то встроенные карты будут проходить проверку. Ну а в исходниках вообще нет необходимости менять строки, достаточно просто отключить "фильтр" встроенных звуковых карт.

Ну вот, стало быть фикс работает, но касается встроенных. А для полной универсальности/совместимости с дискретными картами всё равно нужно иметь в запасе несколько вариантов комбинаций openal/dsound дллей. Точно где-то читал, что на современных Live/Audigi звук или eax работает только со старыми openal-дллями.

оно даже собирается в один большой бинарник с зависимостями только от eax, dx и прочих виндовымых либ. только пользы так и не обнаруживается, быстрее работать не стало, памяти меньше есть тоже, только ~6 часов комп был занят линковкой.


да привыкните вы наконец, что EAX есть (был) только у Creative или картах на их чипах. на любых других карточках делаем в консоли "snd_efx off" и живем спокойно. либо на барахолках ищем б/у Audigy 4, возвращаемся на XP и живем аналогичным образом.


до сих пор ничего не изменилось, встройки, звуковухи и дрова научились лишь "корректно" игнорировать вызовы ф-ий eax 2 (выше никто не умеет) и хотя бы не портить звук своими эмуляциями.

а, чего приходил-то. должен ли компилятор всегда выдавать совершенно одинаковый результат на одном исходном материале?

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

но все же есть довольно много мелких отличий (там поле добавлено, тут проверка делается...). все локации какие нашел в топике собираются, пример из sdk 0.4 тоже. достаточно ли того, что игра такие локации загружает?

K.D,а ты репо на bitbucket перенести не хочешь?
Просто,форкать было бы удобнее.

опять по компилятору вопрос.

привинтил опцию для прямого указания количества используемых потоков. но смущает изначальный выбор разработчиков:

8 потоков где-то после "Sorting faces..."
6 потоков на этапе "Lighting..." (LMaps)
2 потока при использовании GI
3 потока для всего остального в начале
4 потока для всего остального где-то в середине

может у всех тут восьмиядерные процы, поэтому никто не обращает внимание?

Если софтварно работает и на встроенках, почему бы не задействовать? "snd_efx off" никогда не поздно сделать.


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


Я уже писал, что основные этапы (имплисит террейна и компиляция лайтмапов) на 4-ядернике грузят все ядра, но вот финальные, в частности Building/Saving lightmap xx, грузят одно ядро. В результате, если лайтмапов много (100-150), а на сейв каждого уходит по несколько минут, в целом эти второстепенные этапы отнимают еще несколько часов.

ещё один репо, лол.

кстати, я переписал xrDXT под nvtt, единственное - в nvtt нет некоторых специфических фишек типа fadeToAlpha/fadeToColor, а также большей части мип-фильтров.

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

встроенные карточки даже для столь древних игр не могут выдать хоть что-то похожее.


понятное дело, если число потоков >= числу ядер то и загрузка будет 100%. но, у меня тоже 4 ядра, простенькая карта с кубиком на штатном компиляторе мучается пару минут (там где 3-4-6-8 потоков), а если принудительно указать правильное число, то стабильно меньше минуты.

но и тут есть затык, даже на маленькой карте задачи работают не одинакого по времени, одна-две закончились, а остальные еще молотят, на бОльших картах это становится еще заметнее. тут и напрашивается прикостыливание какого-нить планировщика, который разобьет задачи не на (число_ядер) частей, а побольше. в теории это должно выровнять загрузку и уменьшить общее время.


насколько я понял, лайтмапы собираются "по кусочкам" из общей кучи, а это не очень-то распараллеливается.


для компиляторов требуется только одна фишка - банальное сохранение RGBA (или ABGR, не помню) массива в DXT5. LevelEditor при Compile-Build делает еще одну DXT1 (build_details.dds). я вообще выкинул и вставил туда сохранение в TGA, типа сам потом пакетно конвертирую.

а вот замороченная ф-ия DXTCompressBump, которая принимает на вход два массива и делает нормал-мапы и спекуляры, вызывается только из редакторов. что именно надо сделать, чтобы получилась пара файлов name.dds и name#.dds? есть мысль, что эта ф-ия сплошной велосипед и тоже требует замены ))