Сообщение отредактировал ForserX - 21.07.2020, 13:58

zibit_93, ты смертельно обидел(а) RedMagic. Это Юнити-5.

Expropriator, никаких наездов, простая логика. Юнити = говно, ты его ешь => вывод очевиден.

Вот Унреал 4, там да, сталкер делается особенно легко. А вы навмеш видели? Там пару блюпринтов дописать, и получится алайф. Всё просто, вот Джамакаси с утра опохмелится и наверняка распишет с примерами.

Пьяный проспится, а БутчерПит никогда.
Я само говно не ем, я ем контент. Это типа воробушка: он клюёт пшеничку там, а само то гомно он не ест.

Сообщение отредактировал Expropriator - 31.10.2018, 12:03

Не понимаю людей, которые спрашивают "а можна-ли на Unity сделать инвентарь". 2К18, Doom работает даже на холодильниках, на Unity есть даже фанатский порт TES II Daggerfall, с инвентарём, блэкджеком и заклинаниями


Туториал по инвентарю в Unity:
https://unity3d.com/learn/tutorials/project...orial/inventory
Остаётся только расширить функционал и переписать реализацию отрисовки (чтобы инвентарь открывался по hotkey и содержал больше ячеек).

Так то с jamakasi я согласен, ибо сам отношусь к таким людям, которых он описывает. Базовую теорию не знаю, но быдлокод пишу, он работает и его можно разрабатывать дальше. Я вообще уже наступал на грабли, когда ручками на low level писал код для генераци строки SQL запроса, а нужно было просто юзать Enity Framework. Поэтому теперь я меньше времени трачу на понимание low level, и больше времени уделяю изучению API и полезных фреймворков, чтобы быстрее делать большие проекты и набираться опыта в области архитетектуры, чтобы знать, какие фреймворки мне нужны (например мне нужен angular.js, чтобы быстрее дефайнить поведение интерфейса).
Общее понимание важнее, чем знаний деталей, и лучше учиться деталям на практике, пиля свои проекты, чем конкретно ботанить, дрочить на классы и разбираться где лучше int, а где лучше byte.


JS вообще как-то обходятся с "var", и никто ещё не умер (только нужно уметь правильно парсить).

Иногда возникает впечатление, что знатоки основ кодинга просто завидуют high level кодерам без теоретических знаний, мол "захера я дрочил байтовые операции, если этот хрен может без таких познаний запилить нормальный функционал, скомбинировав готовые фреймворки?" И пофиг, что дистрибутив аппликации будет занимать больше места и содержать хвосты - не так уж часто мы упираемся в ограничения по ресурсам, а в веб-программировании всё больше функционала переносится на front-end, где даже мобильный хром может выполнять операции с массивами и шустро отрисовывать chart.js с анимациями на canvas.
Вот где нужны опытные кодеры, разбирающиеся в low level оптимизации, так это back-end. На клиентской части эффективный код нужен например для рендера или математических задач.

Просто сейчас такое время, что low level познания особо не нужны, можно тупо на JS пилить логику и юзать фреймворки. Ну и опять-же code snippets всё юзают. Ящитаю, что лучше невозбранно юзать готовые примеры и потом их модифицировать. С опытом работы всё откладывается в голове, но документацию и примеры всё-же нужно подсматривать - мало-ли что добавили/изменили? Опять-же, таких "кодеров" нельзя считать за программистов, потому что у них нет своего опыта и у них нет понятия "архитектура". Локально что-то работает и пофиг, что мелкое изменение функционала может потребовать переделки кучи кода. Но работодатель не хочет нанимать оболдуев, которые под каждую новую фичу будут переписывать пол проекта.

И да, инвентарь запилить жутко просто. Это просто массив или список с айдишниками обьектов. При отрисовке инвентаря просто берём objectID, потом находим baseID, потом смотрим в base какая-там иконка и имя предмета, а потом отрисовываем в инвентаре. Так оно работает в MMORPG, где все айтемы занимают по одной ячейке в инвентаре. Остаётся только разобраться с самими методами отрисовки GUI в конкретном движке.

Столкир сортирует хабар в инвентаре основываясь на размерах предмета в ячейках + на координатах. Т.е. большие иконки в начале, а самые мелкие предметы с высоким значением координат отрисовываются в конце инвентаря. Т.е. новые "одноклеточные" иконки, которые были добавлены внизу ui_icons_equipment.dds, окажутся в дне инвентаря.

И даже если забыдлокодить инвентарь, реализовав его на неэффективных функциях и сделав какой-нибудь или даже несколько loop'ов, инвентарь равно не будет отжирать производительность, если он апдейтится только когда надо, т.е. по event'ам.

Блэт, да некоторые AAA игори вообще режут FPS до 30, когда игрок открывает инвентарь или меню. Это кард-бланш на любой дичайший быдлокод в реализации инвентаря, лишь бы без учечек памяти и критических ошибок. Если инвентарь не заставляет делать "hold X to @action", то это уже успешный инвентарь.

Сообщение отредактировал Cossack-HD - 31.10.2018, 12:33

Ты так и не въезжаешь в "особенно просто", "можно реализовать" и прочие новояз-обороты Они обозначают ровно одно - "ничего нет", ни инвентаря, ни алайфа - ни-че-го.

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

Сообщение отредактировал Cossack-HD - 31.10.2018, 15:16

Cossack-HD, не надо так кричать, я слышу. У нас проблема перенести сюжет один в один ЧН в ЗП, а вы тут о глобальном.

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

Я тут читаю некоторые комменты, типа "перенести сталкер на другой движок — проще простого", но если это так просто, то где полноценный "тот самый сталкер" на другом двигателе? Я понимаю, что перенести некоторые элементы сталкера, типа инвентарь и погода, не составит большого труда, но перенести рабочий A-Life на другой движок — насколько это сложно?

TES II Daggerfall переносят на Unity уже несколько лет
Конкретно инвентарь - это мелочь. Но раз уж люди задаются вопросами типа: "А в CryEngine можно сделать инвентарь?", то шансов на создание полноценного фреймворка на CE для запуска ресурсов XRAY просто нет.

Проще сделать игру вообще с нуля, чем пытатья реализовать труЪ функционал столкира на другом движке. И порт столкира просто обязан подвергнуться критике и прямому сравнению с оригиналом. Дело может дойти до идиотизма типа имитации багов XRAY на Unity.

Да и если кодер хорошо разбирается в XRAY (что по любому необходимо для переноса фичей на другой движок), то намного проще модифицирововать XRAY, добавив новые фичи (PhysX добавляли), чем интегрировать тысячи фичей XRAY в другой движок.

Вы думаете, почему Беседка в 2К18 юзает движок Morrowind, а не переходят на что-то модное? У Battlefield тоже старый движок, но чё-то не переносят батлу на анрыл. Да они просто больше потеряют, чем выиграют от перехода на другой движок.

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

Сообщение отредактировал Cossack-HD - 31.10.2018, 15:46

В RISC поцессорах byte не нужен, при арифметике он всё-ровно превратится в int.
Но почему-то он там есть. Почему?

Может быть он в storage меньше места занимает по сравнению с int?
Я так понимаю, для ответа на этот вопрос нужно задротить компиляторы и прочее. Лучше потренироваться в распараллеливании задач: от этого будет больше прока, чем от педантичных оптимизаций типов данных.

Касательно шейдеров:

Без эффекта

С эффектом (более "пушисто")

Я модифицировал шейдерный пост-эффект "cartoon" в SweetFX, чтобы он сильнее реагировал на зелёные пиксели и сильный контраст. Это позволяет делать кроны деревьев на фоне неба "пушистыми" и смегчает aliasing, но отображается как шахматные клеточки. Суперсэмплинг даёт похожий эффект и без артефактов, но по цене топовой видеокарты
Если не менять правила выборки пикселей, то "пушисто-шахматными" станут контура камней на фоне неба и прочее. Да и выборка по цвету и контрасту соседних пикселей - далеко не идеальный вариант.

Собственно, было-бы интересно получить возможность применять пост-обработку только на отдельные обьекты. Типа если рисуем крону дерева или траву, то применяем на них соответствующий шейдерный эффект. Насколько сложно это в пайплайне? Шейдер теней ведь рисуется на отдельных обьектах? Тогда можно после отрисовки теней на обьекте провести локальную пост-обработку. Получается per object post processing.

Я немного курил шейдеры Skygraphics, смотрел на эффект parallax relief. Там есть референс идёт на бамп. А можно "грязным хаком" смотреть, какая текстура юзается у обьекта, и если она соответствует текстуре кроны дерева, то юзать шейдер?

В MGS V даже на ультрах часто видно дешёвый checkerboard pattern при отрисовке полупрозрачности например неба и растительности, то есть япошки уличены в применении дешёвых шейдеров по типу того, что я показал выше.

Сообщение отредактировал Cossack-HD - 31.10.2018, 16:46

Зачем?

Так и есть. Перенос на другой движок = сделать игру заново используя готовые ассеты (модели, текстуры, звуки).

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


В FF XV дизеринг используется для прорисовки всех объектов. Более того, там даже тени так рендерятся. Хотя по правде сказать - это не так привлекает внимание за счет плавности появления. Больше всего тоже заметно на растительности.

Исходники движка UDK3 2010 года в открытую валяются в интернете и ни кто не банит.
А рендер в 2010 без отражения в воде - я что то даже не понял?

Да ну нафиг, надо завязывать с этой гадостью, я в гробу видел эту udk.

Сообщение отредактировал Expropriator - 31.10.2018, 21:55

Cossack-HD, c одной стороны можно это называть low level, c другой же, как говорил jamakasi, можно называть это основами. "low level" в большинстве случаев - основа, которая позволяет отвечать на такие вопросы, а так же на кучу других вопросов(и про архитектуру тоже), не задротя компиляторы, интернет, SO и т.п.

Ты написал правильный вывод:


Но общее настроение твоего поста в защиту "такого времени", когда не требуются основы - вызывает диссонанс. Или ты пришёл к правильному выводу пока писал пост?

Есть два варианта:

1. Встроить функцию по управлению r2_sun_naer_border прямо в движок:

2. Расширить r2_sun_naer_border до 3 (например) и создать ползунок в меню настроек

Сообщение отредактировал xrModder - 01.11.2018, 08:50

Живой пример с практики, есть канал Е1 в котором всего через 1 таймслот прокинут обычный ethernet и скорость у него всего лишь 64 кбит\с т.е. в переводе величин это всеголишь 8 килобайт в секунду. Данных которые идут через такой канал очень много как и огромное количество таких каналов. Кроме того все эти данные необходимо хранить очень длительное время т.е. по возможности вообще их не удалять и в догонку все эти данные еще нужно очень хитро переваривать и часть отдать дальше. Так вот многие делают круглые глаза с вопросами а почему не жсонами передают, а зачем вообще париться и упаковывать многие данные в байты а некоторые битовыми операциями в целочисленные и т.д. Короче мрак полнейший.
Щас ктонить скажет что это частный случай использования и там это оправдано. Отвечаю что абсолютно аналогичное нужно применять и в других задачах к примеру в тех же играх продуманная сетевая архитектура и максимально экономные передаваемые данные по сети дадут огромный выйгрыш всего сетевого стека. Сейчас ситуация такая что подавляющее число привыкло к логике. Надо игру по сети сделать, ооо тут короч фреймворк есть ща скопипастю пример, о работает, игроки жалуются на пинги и глюки? ну так сами виноваты, че не могут себе инет завести в гигабит чтоли.
Аналогичная ситуация сейчас везде в целом, все чхать хотели на то что используя что то универсальное от когото они в лучшем случае режут производительность частично а в худшем вообще гробят полностью с чего получается что ссаный калькулятор весит 50 мегабайт и тормозит как топ игра просто потому что на электроне.
Я бесспорно рад что сейчас такое обилие языков и тонн фреймворков к ним, это очень удобно чтобы быстро собрать прототип и проверить концепцию но потом нужно обязательно переписать все почистовой с максимальными оптимизациями под поставленную задачу.

Это исправляется в r2_sun_depth_*, ставь вместо них это:
r2_sun_depth_far_bias 0.
r2_sun_depth_far_scale 1.
r2_sun_depth_near_bias 0.
r2_sun_depth_near_scale 1.

И ещё:
r2_sun_near 30.
r2_sun_near_border 1.

Neo][, я писал как-бы в защиту, потому-что сам не сталкивался с проблемами scale-ability и боттлнеков, а вот фреймворки заметно облегчают жизнь.

jamakasi, да, неткод - это очень чувствительная к оптимизации область. Как и другие реалтаймовые задачи с цикличным выполнением. Там то да, важно использовать компактные типы данных и вообще грамотно пакетировать.

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

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

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

Всё хорошо в меру Калькулятор на 50мб никому не нужен