я уверен - из сугубо неудобства в произношении сочетания букв(звуков) -гзд, хоят никто при этом не жалуется произнося слова с корнем "бзд.." Обычная чья-то школьно-местечковая слабинка подхваченная из за удобства произношения другими, и переросшая в привычку.
Я говорю "распаковать", потому что большинство модов в которых есть модели упакованы в пк3/пк7. А это дополнительное время которое будут очень хорошо заметно в рамках рендеринга, когда абсолютно всё должно отработать за 16мс.
Представим, что у нас 16 гиг оперативки и 2 гига видеопамяти. Что мешает при загрузке уровня (или вообще при запуске гздума, но это отдельный вопрос) распаковать всю сжатую (и пропарсить всю непропарсенную) графику сразу в оперативку? А при игре просто копировать распакованные (и пропарсенные) данные из оперативки в видеопамять, не тратя время на распаковку/парсинг. Если же повторный парсинг понадобится в любом случае, то как минимум распаковку заранее сделать
Представим что гздум и моды лежат на ссд. Варианты такие:
1) Никаких pk3/pk7 нет, просто распакованные папки, которые подгружаются по "-file путь к папке"
2) pk3/pk7 есть, но заархивированы в режиме "без сжатия", т.е. отличие от первого пункта - у нас 1 файл вместо большого количества файлов (и его надо парсить, хотя по идее затраты на парсинг копеечные, но могу ошибаться)
3) тот же вариант 1, но вместо png у нас tga, вместо mp3 у нас wav и т д
4) тот же вариант 2, но вместо png у нас tga, вместо mp3 у нас wav и т д
Вопрос 1: какой из вариантов даст максимальную скорость загрузки уровня и минимальные пролаги при игре?
Вопрос 2: тот же вопрос 1, но если у нас HDD вместо ссд
Иными словами, если моддер хочет минимизировать лаги, как ему лучше сделать мод?
Что мешает при загрузке уровня (или вообще при запуске гздума, но это отдельный вопрос) распаковать всю сжатую (и пропарсить всю непропарсенную) графику сразу в оперативку?
Я правильно понимаю, что при таком подходе лаги пропадут даже при условии сжатых pk3/pk7 с png/mp3 внутри ?
Да, потому что рендеринг (фпс) будет отдельный от загрузки, и все тяжёлые операции будут отдельно. Кроме непосредственно перекидывания текстуры в видеопамяь. Потому что это в потоке сделать нельзя.
1) Никаких pk3/pk7 нет, просто распакованные папки, которые подгружаются по "-file путь к папке"
2) pk3/pk7 есть, но заархивированы в режиме "без сжатия", т.е. отличие от первого пункта - у нас 1 файл вместо большого количества файлов (и его надо парсить, хотя по идее затраты на парсинг копеечные, но могу ошибаться)
3) тот же вариант 1, но вместо png у нас tga, вместо mp3 у нас wav и т д
4) тот же вариант 2, но вместо png у нас tga, вместо mp3 у нас wav и т д
Предположительно будет быстрее, но надо тестировать. Звуки кстати грузятся как-то по хитрому и лагов не вызывают, насколько я знаю. Видимо библиотека проигрывания звуков устроена умнее рендерера)
Разница между PNG и TGA меньше, чем между PNG и JPG (в связи с тем, что сжатие в пнг lossless, а значит несложное).
Я не думаю, что сжатие само по себе является самой главной проблемой, проблема — это r/w операция с диска во время рендеринга. При игре с ссд должно стать быстрее.
проблема — это r/w операция с диска во время рендеринга
Как я писал выше - реализовать загрузку всех файлов оперативку при старте уровня (или порта), и проблема решена
И да, есть еще такая штука как преобразование спрайтов и текстур в HQ4x, xBRZ4x и т д, она тоже ощутимое время занимает, и как я понимаю, теоретически она тоже может быть сделана заранее для всех текстур
А опция "Precache GL textures" это случаем не оно самое?
Там не всё так просто. Если кратко - в моем случае моих тяжелых модов, данная опция лаги уменьшает, но полностью не устраняет.
Изначально (еще в 2012 году) у меня эта опция была выключена, а мои моды представляли из себя всего лишь набор хайрез текстур стен и пола/потолка (а также был включен фильтр HQ4x для убирания пикселей в спрайтах и остальных текстурах, для которых нет хайреза (это кстати тоже бок оптимизации, что HQ4x применяется даже к хайрезу, но сейчас не об этом) ). Потом я заметил подлагивания, начал шерстить опции и нашел там "Precache GL textures". Активировав ее, проблемы лагов исчезли полностью, и я был доволен. Вплоть до тех пор, пока не начал постепенно добавлять в свой мод все новые и новые текстуры, а также 3Дмодели и звуки.
И вот когда моды растолстели прилично, появились лаги даже при "Precache GL textures", например при первых трех выстрелах из вот этого оружия были ощутимые пролаги. Причем вдумайся: одного выстрела недостаточно (хотя HUD анимация каждого выстрела всегда одинаковая), и чтобы текстуры прогрузились полностью и лаги исчезли, выстрелить надо несколько раз (и если пройдешь уровень, либо загрузишь сейв - опять несколько раз выстрелить, чтобы лаги исчезли)
Дальше я начал дополнительно экспериментировать со следующим: использовать PrecacheClasses + PrecacheTextures + PrecacheSounds (что это и как этим пользоваться, читать здесь и здесь ), но и это не устранило все лаги. Дальше я начал юзать вот такие костыли с ACS (читать абзац про "на старте каждого уровня на первом тике выполняется скрипт"), и это тоже не все лаги устранило
Поэтому, на текущий момент, я не знаю 100% решения по устранению лагов (естественно это все при условии, что памяти и железа хватает)
З.Ы. И да, гздум и моды у меня на ссд, а pk3 файлы без сжатия
https://github.com/Mistranger/libzdgui Не раз это уже показывал, но да, оно юзает GDCC для компиляции.
Преимущества - почти вся мощь языка C.
Недостатки - это все еще ACS, и все связанные с ним ограничения тоже тут (не более 2000000 циклов VM за тик и т.д.)
Поэтому с приходом ZScript он стал абсолютно ненужным, ну если только кому-то позарез нужен именно ACS (моддеры для Zandronum, старых версий здума)
Звуки кстати грузятся как-то по хитрому и лагов не вызывают, насколько я знаю. Видимо библиотека проигрывания звуков устроена умнее рендерера)
Забыл сказать: звуки скорее всего не лагают как раз по причине, что предварительно грузятся в оперативку (и распаковываются/парсятся). Соответственно, если сделать тестовый мод со специально огромными звуковыми файлами (или большим их количеством), чтобы для них гарантированно не хватило оперативки (ну и формат какой-нибудь сложный, типа ogg), то скорее всего будут лагать тоже. Просто такая ситуация мало у кого бывает
О боже, гигантоманы - зачем вам дум? почему не юнити не анреал енджин если вы озадачиваетесь тем как сделать жирнее, больше, хайрезнее... или все же суть в том чтоб добиться лагов? тогда выбор верный. Потому что такой херовой оптимизации как здесь нету нигде наверное, по меркам современных движков во всяком случае) Если бы я заморачивался о чем то таком что беспокоит theleo_ua то я бы начал с выбора другого движка, в котором заранее другой подход хотя бы к тем же хайрез текстурам (а вернее к текстурированию целиком, где не будет лоурез вообще понятия, и все изначально будет заточено под высокие детализации)
И еще - вот насколько я знаю упаковка в Zip/pk3/pkxxx это как раз мера оптимизации а не повышения уровня лагов, потому как у нас идет предраспаковка всех нужных ресурсов еще до старта игры. А сборка в пак нам дает 1 файл который как раз с диска в оперативку загружается быстрее, тем более если он без сжатия (хотя как раз для медленных дисков но с быстрым софременным сжатие это опять же скорее плюс ведь с диска читается меньше инфы). использование wav вместо ogg в сжатом zip/pk3 дает потенциально лучшую упаковку на диске при более высоком качестве звука, в отличии от вада, где сжатие самого wav в архив не осуществляется. по поводу TGA vs PNG - однозначно PNG лучше для хранения, потому как один хер он при загрузке в видеопамять раскрывается в немного другой RAW формат, так же как и TGA и BMP и JPG, который по сути наверное все же будет ближе к BMP (но это не 100%), преимущество PNG тут в том что он не сжатый, он просто не хранит ту информацию которой в файле нет (тут лучше почитать на Wiki или на специализированных форумах), но грузится он весьма и весьма прямолинейно)
О боже, гигантоманы - зачем вам дум? почему не юнити не анреал енджин если вы озадачиваетесь тем как сделать жирнее, больше, хайрезнее... или все же суть в том чтоб добиться лагов? тогда выбор верный. Потому что такой херовой оптимизации как здесь нету нигде наверное, по меркам современных движков во всяком случае)
О боже, гигантоманы - зачем вам дум? почему не юнити не анреал енджин если вы озадачиваетесь тем как сделать жирнее, больше, хайрезнее... или все же суть в том чтоб добиться лагов? тогда выбор верный. Потому что такой херовой оптимизации как здесь нету нигде наверное, по меркам современных движков во всяком случае) Если бы я заморачивался о чем то таком что беспокоит theleo_ua то я бы начал с выбора другого движка, в котором заранее другой подход хотя бы к тем же хайрез текстурам (а вернее к текстурированию целиком, где не будет лоурез вообще понятия, и все изначально будет заточено под высокие детализации)
Такой вопрос, причем ответ на который очевидный, я получаю достаточно часто (наверное даже сохраню ссылку на этот комментарий, и буду ее кидать каждому спрашивающему).
Начнем с определения того, что я конкретно хочу (ведь это ключевой фактор, который не понимают те, кто задает такие вопросы):
Скрытый текст:
1) Я хочу сыграть в doom1/2 / heretic 1 / hexen 1 / strife
Данный пункт означает, что я не хочу сыграть в ведьмак. Поэтому аргументация в стиле "хочешь графику - играй в ведьмак" идет лесом: меня не интересует графика сама по себе - меня интересует графика строго в тех играх, где меня заинтересовал геймплей. Если мне нужна графика без геймплея - я предпочту посмотреть демосцену
(этот пункт не относится к тебе ConradRDW[B0S], так как ты это не имел в виду, но были такие индивиды, которые на полном серьезе писали "хочешь графику - играй в ведьмак вместо хексена", я даже удивлен, что такие вообще существуют)
2) Я хочу получить настолько близкий к ванили геймплей, насколько это позволяют гздум и doomsday.
Это подразумевает:
- скорость бега и поворотов камеры игрока
- механика взаимодействия со стенами
- механика покачивания оружия при взаимодействии со стенами
- механика движения монстров
- корректная эмуляция OPL миди треков
- ну и еще 1000 нюансов эмуляции ванильного геймплея, которые расписывать нет смысла, но идея надеюсь понятна
Как ты предлагаешь реализовывать это в unity/ue4, и сколько на это уйдет лет? Если не 10летий. Даже сам гздум и думсдей писались шарящими программистами 10летиями, а теперь представь, сколько времени понадобится мне, в разы менее шарящему
А так же не забудь, что я хочу иметь возможность все это моддить при минимальных усилиях и временных затратах. Например захотел изменить поведение оружия - replaces, пара правок, и все готово и работает. Получится ли реализовать такой движок на unity/ue4, и сколько времени на это уйдет?
3) Я хочу полную совместимость с такими вадниками как masters of chaos, scourge of viscerus, scythe 2, day of the acolyte и т д, а также ванильными ивадниками
Это подразумевает, что мне нужна поддержка не только ванильной механики, но и decorate, acs, zscript и т д
Автор думсдея до сих пор не реализовал поддержку здум фич, хотя планировал. Авторы зандронума тоже не успевают. Ибо поддерживать это все до актуальных версий - геморрой еще тот. Даже для шарящих
4) Я хочу поддержку хайрез графики (настолько хайрезной, насколько это возможно)
5) Я хочу, чтобы для тех объектов, где мне понравилась как хайрез графика так и ванильный спрайт (отфильтрованный в XBRZ4x и другими фильтрами), чтобы отображался по рандому, либо лоурез спрайт либо хайрез графика (это может быть хайрез спрайт, нейросетевой хайрез спрайт, 3д модель и т д)
Следовательно, движок должен уметь еще и в спрайты. Т.е. фраза "где не будет лоурез вообще понятия" отпадает - мне важно лоурез понятие. Особенно на фоне того, что для кучи ассетов хайрезов банально нет (например ассеты из masters of chaos (пример такого ассета смотреть здесь на 10:17) )
6) Я хочу работоспособность моих прошлых геймплейных, звуковых и графических модов (т.е. полную совместимость с ними), ведь переписывать их заново нет ни времени ни желания. Многие из них я использую при игре чуть ли не в каждый вадник
7) Я хочу работоспособность моих геймплейных, звуковых и графических модов (т.е. полную совместимость с ними), которые сейчас частично написаны и разрабатываются конкретно сейчас (например вот этот мод, который еще не готов, но который я очень сильно уже хочу постримить), ведь переписывать уже написанное заново нет ни времени ни желания. Нет времени и желания даже декорейт на зскрипт переписать, про unity и ue4 вообще молчу
8) Я хочу поддержку текущих ассетов, например с realm 667 или с уже готовых маппаков/модов. И чтобы их легко и просто можно было добавить в мой мод
А также хочу поддержку маппаков/модов моих зрителей. Помнишь например, когда вот этот юзер давал тебе свои карты и ты их проходил? Вот я тоже хочу проходить на стрим его карты, но со своими модами на графику (что я уже, кстати, делал: раз, два)
Или более сложный вариант (который я с ним уже обсуждал, и он согласен): я сделаю мод, позволяющий в думе юзать оружия дума и страйфа (оружия страйфа будут спецом отобраны и модифицированы так, чтобы был баланс и было интересно играть), а он сделает карты, где расставит оружия/патроны и дума и страйфа, и задумает геймплей карты так, чтобы каждое оружие пришлось использовать
9) Я хочу чтобы была поддержка старого md2/md3 формата, так как много годного (на мой взгляд) контента сделано именно в этом формате (пример такого контента смотреть здесь на 6:36). Причины две: во-первых, даже если в будущем сделают аналоги на более совершенном формате, то они будут выглядеть по другому, и мне все равно захочется увидеть в игре и md2/md3 варианты тоже, а во вторых - для большинства текущего контента других вариантов нет (ну либо есть, но они мне не понравились стилистически)
10) Я хочу поддержку перевода и озвучки на русский язык (как оригиналов так и маппаков/модов, в том числе и своих)
11) Гздум и думсдей вышли в 1999 (плюс минус), и текущие их версии до сих пор совместимы с большинством маппаков и модов, которые выходили за все это время. Теперь представь, что будет на UE4: вот через 5 лет выйдет UE5 - как мне сделать совместимость UE5 с UE4 ? Или вечно сидеть на устаревшем UE4 ? Одна из основных проблем UE4 и Unity - совместимость со старыми версиями
Пункты объединены союзом И. Чем больше пунктов удовлетворяется, тем лучше. Часть пунктов ключевые, и их неработоспособность полностью множит на ноль мое желание этим пользоваться.
Теперь вопрос: сколько 10летий понадобится чтобы научить unity или ue4 во все 10 пунктов?
Надеюсь доступно объяснил и вопросы отпали.
Самое смешное, что мы сейчас делаем один секретный проект, связанный с хайрез графикой (как будет готово, я создам тему и расскажу там, что он из себя представляет, где скачать и как им пользоваться, а также постримлю его), в который вложено примерно $5000 (точную цифру лень считать, посчитаю когда буду анонсировать, но не суть), и у нас был выбор, делать его для ue4, unity, любого другого движка из существующих или doomsday, и как ни удивительно, но выбор пал на думсдей, мы даже попросили автора порта спецом для нас реализовать несколько дополнительных фич.
Ну, и напоследок, напомню: графу надо БАЦ - и перейти на UE4 (с)
И еще - вот насколько я знаю упаковка в Zip/pk3/pkxxx это как раз мера оптимизации а не повышения уровня лагов, потому как у нас идет предраспаковка всех нужных ресурсов еще до старта игры. А сборка в пак нам дает 1 файл который как раз с диска в оперативку загружается быстрее, тем более если он без сжатия (хотя как раз для медленных дисков но с быстрым софременным сжатие это опять же скорее плюс ведь с диска читается меньше инфы).
использование wav вместо ogg в сжатом zip/pk3 дает потенциально лучшую упаковку на диске при более высоком качестве звука, в отличии от вада, где сжатие самого wav в архив не осуществляется
по поводу TGA vs PNG - однозначно PNG лучше для хранения, потому как один хер он при загрузке в видеопамять раскрывается в немного другой RAW формат, так же как и TGA и BMP и JPG, который по сути наверное все же будет ближе к BMP (но это не 100%)
преимущество PNG тут в том что он не сжатый, он просто не хранит ту информацию которой в файле нет (тут лучше почитать на Wiki или на специализированных форумах), но грузится он весьма и весьма прямолинейно)
при сохранении в PNG в xnview есть параметр "степень сжатия 0..9"
при сохранении в PNG в xnview есть параметр "степень сжатия 0..9"
оно есть еще в Gimp, irfan view, Adobe photoshop, и это только то чем я пользовался, но тут "степень сжатия" вернее будет назвать "качество", или "степень потери оттенков", думаю такими формулировками сразу куда понятнее становится что речь не об архивациях.
Вообще если быть проще и говорить обычным языком, то ты как раз таки хочешь ведьмак и дум 2016 но про сюжет ванили с учетом твоих уже имеющихся наработок под уже заранее выбранный порт. Если бы не "уже имеющихся наработок под уже заранее выбранный порт", то как раз таки научить юнити или уе классическому геймплею поди проще было бы чем сделать GZDoom нормальным движком для современного графония. В остальном ясно понятно, удачи в разработке)
оно есть еще в Gimp, irfan view, Adobe photoshop, и это только то чем я пользовался, но тут "степень сжатия" вернее будет назвать "качество", или "степень потери оттенков", думаю такими формулировками сразу куда понятнее становится что речь не об архивациях.
Я это имел в виду. Т.е. PNG это по сути архив (в отличии от BMP). Насколько я знаю, PNG не умеет терять оттенки (или любую другую информацию о контенте изображения), и его степень сжатия это как раз алгоритм архивации данных, который либо быстрый и "плохо сжимает", либо медленный и лучше сжимает.
Вот JPG да - он, кроме самого факта архивации, еще и потери умеет вносить (как оттенков так и других вещей)
Формат APNG вроде как умеет в потери, но мы сейчас ведем речь не о нем (гздум вроде не умеет в него, как и в WebP)
Вообще если быть проще и говорить обычным языком, то ты как раз таки хочешь ведьмак и дум 2016 но про сюжет ванили с учетом твоих уже имеющихся наработок под уже заранее выбранный порт.
1) Не только под заранее выбранный порт. Есть и такие, которые при случае, могут быть перенесены с других портов
2) Не только мои. Есть куча маппаков и модов, которые делались под разные порты, но чудом так получилось, что они работают и в гздуме (а некоторые и в думсдее). Часть сможет работать после небольшой доработки напильником
Если бы не "уже имеющихся наработок под уже заранее выбранный порт", то
то встает вопрос, как я это дальше буду моддить, и какое будет соотношение "усилия_время/результат". Под моддингом я сейчас имею в виду в первую очередь геймплей. А также встает вопрос, как я смогу использовать то, что другие уже сделали для других портов. А также встает вопрос, что я буду делать, когда выйдет UE5 UE6 и т д, как я заставлю их поддерживать мои наработки для UE4
то как раз таки научить юнити или уе классическому геймплею
Т.е. классический геймплей это только маленькая часть. Научить еще придется адекватному инструментарию по моддингу этого геймплея, и чтобы моддить было легко, а не пол года писать с++ код
Дело в том, что в дум комьюнити создано уже куча контента на декорейте acs зскрипте, и чтобы это юзать, придется пилить и поддержку этих фич тоже
научить юнити или уе классическому геймплею поди проще было бы чем сделать GZDoom нормальным движком для современного графония
ответ простой: гздум и думсдей пишу не я, поэтому так как для unity и ue4 еще нет ничего такого, что удовлетворило бы всем моим пунктам, а гздум и думсдей уже есть (и развиваются дальше), то выбор очевиден
более того: кто сказал, что их не будут постепенно оптимизировать в будущем? Для думсдея автор запланировал постепенный перенос ресурсоемких вычислений на GPU, для гздума тоже постепенно, хоть и медленно, но процесс идет, могу даже пруф найти касательно моделей, где я с графом что-то подобное обсуждал
Движки UE4 и Unity хороши когда ты делаешь точечный проект, который не привязан к дум комьюнити и его наработкам, как например игра alekv. В случае же дум проекта с функционалом гздума, даже если бы граф и скайджек в начале разработки решили "БАЦ - и начать разрабатывать сразу на UE" (не помню уже, какой UE был тогда, пускай для примера это будет UE2), то тогда при выходе UE3 они бы столкнулись с вопросом совместимости контента UE2, а при выходе UE4 - совместимости с UE3 и UE2. А потом выйдут UE 5 6 7
Проекты для дум комьюнити, в моих глазах, это в первую очередь проекты по вертикальной (уметь в то что было сделано под прежние версии) и горизонтальной (уметь в то что сейчас делают другие моддеры и мапперы) совместимости, и UE4/Unity сюда очень плохо вписываются имхо
(ну при условии, что мы хотим графон), то получится следующая проблема: мы застынем на технологиях UE4 навсегда. А теперь посмотри как это было в думсдее: в 1999 он умел только в md2 (формат моделей квейка 2 1997 года), а сейчас он умеет уже в FBX (формат моделей, который используется в UE4, пример), а в 2025 году например научится в X_CSF (гипотетический формат чего-нибудь графонистого, который будет юзаться в гипотетическом UE5), но, тем не менее, останется совместимость и с MD2 97 года и с FBX из UE4. Соответственно, смысл оставаться на UE4 ?
Кстати, по поводу модели из примера выше - недавно Brian Raffel (основатель Raven Software, которая разрабатывала еретик и хексен, также он рисовал там некоторые спрайты, как например вот этот по ссылке), постучался в ЛС к автору модели и захотел у него купить все его наработки, с целью распечатать себе на 3D принтере (в первую очередь речь шла про серпент стафф), но он дал ему их бесплатно, так как они бесплатные
Движки UE4 и Unity хороши когда ты делаешь точечный проект, который не привязан к дум комьюнити и его наработкам, как например игра alekv. В случае же дум проекта с функционалом гздума, даже если бы граф и скайджек в начале разработки решили "БАЦ - и начать разрабатывать сразу на UE" (не помню уже, какой UE был тогда, пускай для примера это будет UE2), то тогда при выходе UE3 они бы столкнулись с вопросом совместимости контента UE2, а при выходе UE4 - совместимости с UE3 и UE2. А потом выйдут UE 5 6 7
Никто не запрещает делать свою загрузку форматов так-то, а не полагаться на встроенную в UE/юньку. У меня есть движок на юньке в котором почти всё читается с диска (из аналога wad).
Основной блокер в невозможности собирать новые шейдеры в юньке из кода. Только при сборке проекта. А так было бы вполне возможно реализовать функционал как в гз.
В теории, можно это обойти (вызывать компилятор шейдеров в момент запуска игры и сохранять это в asset bundle, после чего грузить бандл). Но на практике, я такими извращениями не занимался — специфика именно моего движка не располагает, у меня там игра 1999 года, работающая на спрайтах с палитрой. Пользовательские шейдеры не нужны.
Вообще говоря, да, если вы хотите длинный проект (5+ лет разработки) на юньке, нужно приготовиться к тому что нужно ОЧЕНЬ хорошо выбирать какими инструментами пользоваться.
И очень много писать руками, чтобы не было зависимости от сторонних инструментов.
Хотя конечно да, никто не застрахован от внезапной смерти всех авторов юньки и банкротства компании. Как и от удаления гитхаба и многих других интересных катастроф )
Никто не запрещает делать свою загрузку форматов так-то
Я правильно понимаю, что ты имеешь в виду "самому на c++ написать тот код, который граф и скайджек писали для гздума и думсдея" ? Если да, то в случае гздума и думсдея за меня это делают граф и скайджек (а также стоит учесть, что придется еще и учить соответствующие нюансы программирования таких вещей, уверен, что человеку без опыта разработки таких нюансов и не знающему исходников думсдея и гздума, будет адски трудно и долго в это все вникать)
Так то да, никто не мешает это все самому написать на с++, но надо понимать, сколько времени и усилий на это уйдет
И кстати, еще вопрос возникает: unity и ue4 за тебя ж сами ничего не заоптимизируют, верно? Т.е. тебе придется тратить тонны усилий и времени, чтобы твой проект был оптимизирован и работал без лагов, верно? Вот как пример, игра WFTO, сделанная на юнити изначально - насколько я знаю, на ее лаги жаловались все кому не лень, даже мой друг, у которого 10 лет опыта работы в геймдеве с UE4, высказывал мне тонны ненависти в стиле "почему разработчики WFTO собрали кучу бабла на кикстартере и не сделали адекватную оптимизацию?"
Собственно - насколько сложно и долго реализовывать оптимизацию на таких движках, особенно если до этого ты ничего не кодил на с++ конкретно для геймдева? Не выйдет ли так, что уход от гздума/думсдея на ue4/unity будет сменой шыла на мыло, и лаги все равно останутся?
Вообще говоря, да, если вы хотите длинный проект (5+ лет разработки) на юньке, нужно приготовиться к тому что нужно ОЧЕНЬ хорошо выбирать какими инструментами пользоваться.
И очень много писать руками, чтобы не было зависимости от сторонних инструментов.
Хотя конечно да, никто не застрахован от внезапной смерти всех авторов юньки и банкротства компании. Как и от удаления гитхаба и многих других интересных катастроф )
Ну от смерти графа/скайджека (или просто от их ухода из проекта, как например в свое время это сделал ренди) тоже никто не застрахован
А как скоро гздум тот же нагонит технологичность UE4? как думаешь? мне кажется лет через 20. А ты учитывай как свободно тот же уе4 с шейдерами работает, как он оптимизирован, какие форматы карт держит (полигоналка, не надо никаких изъебств с 3д полами. но тут опять же - вопрос твоего личного желания нежелания портировать кучу наработок на него. я это могу понять - долго, и не факт что оправдает ожидания, не факт что хватит терпения итд. потому отношусь все же с пониманием к твоему выбору но не согласен что застрявание на уе4 было бы плохим вариантом.
Правила 
Поиск
