Перейти к содержанию

Поиск

Показаны результаты для тегов 'engine'.

  • Поиск по тегам

    Введите теги через запятую.
  • Поиск по автору

Тип контента


Форумы

  • Энциклопедия Fallout
    • Galaxy News Network
    • Fallout 4 и 76
    • Fallout 3 и New Vegas
    • Fallout Tactics
    • Fallout 1-2
    • Wasteland
  • Другие проекты
    • Postapoc Media
    • Проекты «Nevada Band»
    • Olympus 2207
    • Nuclear Attack
  • Общий раздел
    • Старые Качели
    • «Голый Лось»
    • Nuclear City

Поиск результатов в...

Поиск контента, содержащего...


Дата создания

  • Начало

    Конец


Дата обновления

  • Начало

    Конец


Фильтр по количеству...

Регистрация

  • Начало

    Конец


Группа


Telegram


Discord


Twitter


Instagram


ВКонтакте


YouTube


Web


Откуда:


Интересы:

Найдено 2 результата

  1. Приветствую! Наверное каждый мододел спрашивал себя, почему двиг настолько дубовый. Сейчас объясню о чем я. Фолыч разрабатывался с 1994 года, первый фолыч выпущен в 1997 году, второй в 1998. Движок Fallout 2 более юзерфрендли, многие настройки вынесены из таблиц движка (exe файла) в текстовые файлы, которые можно редактировать в блокноте и тем самым изменять игру. Вот мой список костылей. 1. Проблема бинарных форматов игры. Карты, прототипы. Еще и зависимость от порядка байт. Я понимаю, что в 1997 году еще не было xml и json. Но почему не использовали для прототипов ini формат. Легко редактируется любым блокнотом. Нет зависимости от размеров структур игры. Те же проблемы наследуют карты. Можно было написать или свой текстовый формат в 300 строк или читать fscanf функцией, на ее основе можно считывать любые текстовые данные из файла. 2. Проблема хранения не имен файлов, а номеров файлов. Каждый ресурс в игре прописан в lst файле, где номер строки с названием ресурса является его числовым идентификатором. Обращение к ресурсу идет через данные идентификаторы, это все ресурсы картинки, скрипты, карты, прототипы. И поэтому добавление чего то нового в игру так затруднено. Еще существует проблема несовместимости модов, так как несколько модов используют одни и теже идентификаторы для разных объектов. Лучший вариант это хранить путь + название ресурса. Обычная текстовая строка с уникальным названием. 3. Скрипты в бинарном формате. Так как есть компилятор, то его следовало встроить в движок и хранить скрипты в текстовом формате, а при загрузке локации компилировать скрипты, это бы даже на тех маломощных ПК занимало несколько секунд. (Кеш скомпилированных скриптов можно хранить в папке игры) Претензий нет к форматам dat, acm, frm, так как хранение в данных форматах позволяло сильнее сжать итоговые ресурсы. Типичный компьютер тех лет это pentium 100 mhz и 16 мб озу это без шуток не мало. У меня есть ответ, что это было сделано для скорости загрузки ресурсов, так как бинарные данные читаются быстрее. Но не думаю, что это было решающее значение. Сжатый текстовый файл читается по скорости не менее быстро. Текстовые форматы добавили бы удобство редактирования игры, при ее создании. Еще есть вариант, что все изменения вносились через редактор карт, но он настолько дубовый, что у меня есть сомнения в том, что именно данный редактор выложенный разработчиками использовался для создания карт. У них возможно был более нафичеванный реактор. Поделитесь пожалуйста своими мыслями на этот счет.
  2. SFALL 5.0 Установщик перед установкой автоматически будет создавать новый файл sfall.ini с текущими настройками вашего ddraw.ini. По возможности используйте новый sfall.ini для вашей конфигурации sFall. SF-Configurator для управления и настройки параметров конфигурации sfall. Чтобы обновить текущую установленную версию sfall, в установщике выберите опцию обновления, это обновит файлы, не затрагивая текущие установленные настройки в конфигурационных файлах. Замечание к версии 5.0 Интегрированный патч высокого разрешения (HRP) - самая большая часть этой версии, и предназначен для замены устаревшего Hi-Res Patсh by Mash. Интегрированный патч высокого разрешения обладает почти той же функциональностью, что и Hi-Res Patсh by Mash, но встроенный патч имеет лучшую интеграцию с графическими функциями sfall. Теперь sfall будет считывать требуемые настройки из файла конфигурации f2_res.ini, и использовать f2_res.dat от оригинального HRP. Интегрированный HRP включен по умолчанию, и при запуске игры sfall отобразит уведомление и предложит отключить исходный Hi-Res Patсh by Mash. Есть несколько отличий от Hi-Res Patсh by Mash: Базовым графическим режимом встроенного HRP теперь является DirectX 7, это означает, что настройка GRAPHICS_MODE=0 будет работать так-же как режим 1. Удален устаревший 8-битный режим графики. Нельзя изменять размер окна во время игры в оконном режиме, что избавляет от нежелательных перемещений интерфейсов во время игры. Функция FoW (туман войны) не будет реализована во встроенном HRP. Опция CPU_USAGE_FIX теперь не будет иметь конфликтов с опцией ProcessorIdle в sfall если были сразу установлены две опции, теперь это является одной опцией. Опции UAC_AWARE, ALT_MOUSE_INPUT, SCROLLWHEEL_FOCUS_PRIMARY_MENU, REFRESH_RATE, IS_GRAY_SCALE, CD_CHECK, BARTER_PC_INV_DROP_FIX, FADE_TIME_MODIFIER, признаны на текуший момент устаревшими и не будут оказывать никакого влияния на интегрированный HRP (взамен опции FADE_TIME_MODIFIER имеется аналогична опция в sfall). Описание скриптовых возможностей sFall. (в процессе перевода на русский) Новые возможности компилятора SSL: Добавлен дополнительный оператор div для обеспечения целочисленного без знакового деления. Добавлены дополнительные логические операторы AndAlso, OrElse, с логикой short-circuit но не требующие установки -s опции компилятора (аналоги операторов &&, || в С++). Добавлен альтернативный оператор присваивания = (синтаксис C/Java). Добавлена возможность объявить локальные переменные процедуры в любом месте тела процедуры. Описание параметров на основе версии 4.1.6 extended Репозиторий: GitFlic / GitHub / Yandex / GitHub
×
×
  • Создать...