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

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

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

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

Не понимаю людей, которые спрашивают "а можна-ли на 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, не надо так кричать, я слышу. У нас проблема перенести сюжет один в один ЧН в ЗП, а вы тут о глобальном.

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

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

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

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

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

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

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

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

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

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

Без эффекта

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

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

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

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

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

Зачем?

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

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


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

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

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

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

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


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

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

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

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

Живой пример с практики, есть канал Е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мб никому не нужен

Вот печалька в другом, даже в корпортивном секторе сейчас тенденция нарисовалась жуткая. Давеча ставили тут одну софтину по мониторингу от alcatel-lucent самую распоследнюю и купленную за сумму в которой больше шести нолей и циферка в общемто несуразно огромная, отдельно к ней еще специализированный сервак (на itanium камне на самом то деле) который тоже стоит космических цифер и сверху еще покупка лицензии оси hp-ux. Так вот по сути и сухому факту все что делает софт на сервере это тупо выполняет snmp мониторинг и опятьже через snmp дает конфигурировать железки. В старых версиях т.к. демон на java веб морда рисовалась тупо явовскими аплетами, сейчас как известно на смену пришел jnlp который очень крут. Но разрабы пошли другими путями, сотворили месево из контейнеров, куски явы, кучи бд, клиенское приложение появилось отдельное и оно на электроне, веб морду рисует вообще непонятное нечто поверх ноды. При всем этом весь этот колхоз за просто бешенные деньги постоянно падает, тупит и жрет ресурсы просто непонятно на что. В тоже время старые версии где была только жаба спокойно крутилась на очень скромном железе и работает до сих пор не один десяток лет уже. А тут проХресс, красивые анимации и плавные переходы которые занимают уйму времени, тормоза на сервере и у клиентов, просто сказака современных технологий.

Собрал рендеры в кучу, пришлось напречься. То исходники партиклов, то шейдера, то тупизна разные. А у меня какого то хрена на dx9 грофоний лучше, чем на dx10. Не вру, на полном дин. освещении и на улучшеном дин.освещении, ну ваще очуметь. Нафига пысы делали dx10? Типа хотели оптимизироваться?

На DX10 еще и SSAO тупит. Это фича или баг? Сейчас такой рендер есть в играх:

Как по мне, то дх8 красивее дх9, который красивее дх10)))
По сути игра на дх8 и дх9 это две визуально разные игры. Разные цвета, погода, свет.
Вопрос, зачем было делать дх9?

Ты это таво, давно в ЗП играла? Не надо это писать больше ни где. Это касаемо ТЧ однако и всё.

Решил проблему с полосами в тени?

xrModder, нет. Это не баг движка рендера - это какая то околизия в освещении статики. Скорее всего.
Всяко разно регулировал - не лечится.

Почитай ответ в предыдущем странице.

Как меняется (исключая эффект рельефа, блеска) картинка с выкл./вкл. бампами:

(внутри)

бамп отключен (bump_mode[none])


бамп включен, material[0] в textures.ltx


бамп включен, material[0.5] в textures.ltx


бамп включен, material[1] в textures.ltx


(снаружи)

бамп отключен (для текстур дома)


бамп включен, material[0] в textures.ltx


бамп включен, material[0.5] в textures.ltx


бамп включен, material[1] в textures.ltx


Почти у большинства текстур в тч, material: 0.5 - 1, есть 3 и даже 5-6.

Привет, сталкеры. У меня тут в 4A Engine отражения на воде. Настоящие, не на основе только видимой картинки.

А у вас?

У нас... почти настоящие. Ручная работа, кстати.

Modera, можно пониже камеру опустить?

А пониже

Круто. Сколько по времени создание заняло?
В 4А попроще, воду на уровень поставил и она отражает.


А пониже будет видно траву и асфальт через волны, у водички есть параметр на каком расстоянии становится прозрачной.
На скриншоте я на заборе стою.

Yara, какой способ более удобен — хранить настройки текстуры в textures.ltx или в thm-файлах?

xrModder, 2. А вообще мне оба не нравятся.

Второй был бы удобен, если thm имел текстовый формат, а не бинарный. Открывать постоянно АЕ чтобы поменять циферку это ппц.

ForserX, есть лучшие легко-реализуемые варианты?..

Тоже интересует

Хотя, идея от RayTwitty мне больше нравится. Непонятно, зачем разрабы сделали thm-ки бинарными, более удобен текстовый формат по типу ltx конфигов.

Это шейдер?

Нет, это геометрия.


Непосредственно псевдоотражения деревьев кажись делал единым копипастом "всё выделить и перевернуть". А вот потом каждое развернуть правильно вокруг оси... наверно несколько дней. А вот на реализацию эффекта кувшинок на воде ушло несколько лет. И то получилось только для r1.

Вин виста?



А как реализовал? Нельзя просто геометрией без коллизии?

dPlayer, она самая

Modera, красотаааа. Люблю ее интерфейс, на втором месте по красоте после брутально-сексуально-тестостеронового вин 9х

Могу перехфигачить.


Есть, но я ещё их не придумал....

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


Не знаю. В теории, возможно было бы проще. На практике пока сложно ответить.

Ага. Вроде через AXRToolset теперь можно тоже thm смотреть/править, особо не ковырял.
https://github.com/revolucas/AXRToolset

Как и бывает, забыл о главном - на тех скринах (их лучше просмотреть последовательно) замечен сдвиг текстур при включении бампов, и сильное затемнение (особенно в бункере сидора) при повышении material.

http://ap-pro.ru/forum/129-89104-938619-16-1479480600
Я здесь вроде фиксил, для статики точно. На р2 вроде тоже что-то пытался, но не помню, получилось ли.


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


Табличку когда-то K.D. скидывал.

1. Почему нельзя сделать редактор с ассоциацией ему тхмок и встроенный пункт в контекстное меню?
2. Почему нельзя придумать расширение форматов ддс, обжект, огф с вшитыми в них метаданными?

А тхмы в текстовом формате будут так же быстро обрабатываться, как бинарные?


Нихнера оно не блинн и уж тем более не фонг. По-моему, в сталкире везде какой-то ламберт, а блеск поверхностей реализован чем-то другим.