По адресу нельзя. Например, макрос AddDynamic просто статически проверяет на этапе компиляции что такая функция есть, но в итоге берет имя функции и биндит по нему.
Сейчас проводим набор на стажировку в компанию, в тестовом у нас есть вопрос про различия делегатов.
Почти у всех вижу, что динамик делегаты можно сериализовать, но почему то никто не пишет, что динамик делегаты биндят функцию по имени, а не по адресу и по этому могут быть использованы в блюпринтах, считаю это упущением данной статьи.
На мой взгляд основное отличие dynamic делегата от статического это именно то, как происходит бинд, от сюда вытакает и все остальное и дает более понимание о механизмах работы.
То есть именно потому что динамик делегат знает имя функции он может быть сериализован, использован в блюпринтах и требует UFUNCTION(). По этому же он и медленнее. Так же хочу заметить, что юникаст динамик делегат тоже может быть использован в блюпринтах как инпут-пин функции.
Еще вопрос на тему текстур стороной в степень 2-ки. Я писал статью ,некоторое время назад, на Habr, про разные советы новичкам и не очень (https://habr.com/ru/post/664036/). Упомянул там power-of-2 текстуры. После чего с одним комментатором обсудили эту тему в комментах, да и сам глубже исследовал эту тему и выяснил, что современные не мобильные GPU и графические API года с 2010, примерно, уже нормально производят все нужные операции и не на po2 текстурах. Но эту инфу я собирал по "обрывкам" (там в целом в комментах можно почитать). Можно попросить подсказать на эту тему? Может статью какую где про это полноценно рассказано или иной материал. С одной стороны я понимаю почему po2 нужно, но если современные железки и софт правда с не po2 нормально работают, то почему это требование до сих пор актуально? Если мы не говорим о обратной сомвестимости с древнегреческим железом или мобильными платформами. Или может я не правильно интерпретировал то, что нашел и современные GPU не работают нормально с не po2 текстурами.
Скажу на тему контроля версий. Работал со всеми, упомянутыми. Скажу что Perforce не люблю больше всего, по ряду причин, основная - отсутствие нормального бранчинга да и бранчинга в принципе, как и многих других нужных фич.
Plastic по заявлением создателей должен решать все наши проблемы при разработке игр: - Жирнющие репы - Предохранение от двойного изменений немержащихся файлов (блокировки, валидация оутдейт файлов и тд) - Сильный бранчинг - Удобная интеграция разных штуковин, типа тех же сборок на коммит в ветку
С жирными репками работает все отлично и относительно быстро. И по началу работы с ним я его боготворил, но после наработки некоторого опыта открылись проблемы. У меня есть и к бранчингу претензии и от двойного изменения файлов не спасает, но локи хотя бы кросветочные, а не как в p4. Да и багов выше крыши (попробуйте, например поменять юзера в пластике, на июльских версиях), а 4 разных гуя, каждый с разными фичами порой подогревают стул. Но по отзывам команды, которая раньше работала на p4, а сейчас на пластике - их все устраивает, а стоит он даже в самой дорогой комплектации почти в 2 раза дешевле перфорса. Но не так бесплатно, как гит, конечно.
Git в целом последнее время оч круто себя показывает, по крайней мере мне очень нравится. Sinbad LFS доработал, теперь с ветками нормально все работает и от двойного изменения ассетов кое как, да спасает (спасибо статус бранчам), кодревью удобные (если развернуть GitLab, например) и все интеграции встраиваются на ура.
Я сейчас пишу статейку про все эти системы контроля версий, как мы со всем этим работали и что я об этом всем думаю. Надеюсь, что скоро выйдет - советую ознакомиться, если будет еще интересно. Или если по пластику вопросы будут - обращайтесь, расскажу что смогу.
Кстати, а что думаете на счет снятия локов при мерже в стабильную ветку? На сколько я знаю на данный момент нету решения, которое спасает от того, что ассет изменился в 2-х фича-ветках. Можем только по "основным" чекать.
И на анриале и на юнити можно делать и мобилки и не мобилки. Но четкий уклон в сторону мобилок у юнити прослеживается и это удобнее и проще на юньке чем на анриляше.
В целом я бы советовал Unreal, на нем все не плохо получается, спецов все еще мало и они востребованы очень.
Если вопрос конкретно такой: "Что писать на макаронах, а что на С++", а не "Как технически дружить макароны и С++". То ответ наверное такой: лучше пробовать все писать на С++, со временем придет понимание о том, что тебе проще делать на С++.
Я обычно стараюсь придерживаться такой идеи: кор какой то фичи делаем на С++, ее вариации на макаронах, если не подразумевается значительных изменений.
Но и в целом тут в статье есть четки советы что на чем делать.
К моему великому сожалению - нигде. Подавляющую часть всего рабочего опыта я занимался VR аркадами и подобным контентом для VR парков/клубов/аттракционов. Там титров нет. Была еще парочка клаудгейминго-образных не игровых проектов - там тоже нет.
Из ближайшего - скоро выйдет в софтлаунч мобильная музыкальная аркада, но это очень маленькая и простая игра. Кстати, если вы или кто-то имеет компетенции в проведении мягкого запуска и/или релиза мобильных игр и готов ими поделиться - буду рад если вы мне напишите в личку.
1 - Текущий цвет сцены - нужно сделать выборку пикселя по UV сцены 2 - Вывод эмиссива - нужно сделать выборку пикселя по UV и/или вычислить исходя из UV меша 3 - Вывод опасити - нужно сделать выборку пикселя по UV и/или вычислить исходя из UV меша
Ну как минимум тут еще выборка пикселей для операций происходит из 3-х источников, а не из двух. Текстурные выборки опять же весьма дорогие в мобильниках.
Я может когда нибудь сделаю небольшой материал про эти шейдермодели, UV в вертексных шейдерах и что нибудь еще туда запихаю.
Ну кстати пару миллисекунд "из воздуха" то она приносит. Как мне кажется проблема в том, что надо писать понятный код для нативизатора, а не для исполнителя макарон.
Из самых проблем что я помню лично: нативизатор часто не корректно выводил типы. Но иногда он правда делает вообще непонятно откуда взявшиеся баги :(
Суть нативизации как мне кажется в том, что бы сгенерить наиболее оптимизируемый компилятором код. Именно от туда бесконечные свичкейсы. А функцию сложения компилятор спокойно размотает до простого lea.
Прямо перед вышей цитатой 4 пункта есть для основных классов. Положу сюда тоже: - все UObject — PostInitProperties, PostLoad - AActor — PostInitializeComponents, OnConstruction, (и другие) - UActorComponent — OnRegister, InitializeComponent - UUserWidget — OnNativeInitialized, OnNativeConstruction
Конкретный кейс - клиент подключается на сервер: - Его павн, контроллер, стейт вызывают бегин плей и на новом клиенте и везде. - Все актеры и компоненты жившие на сервере до подключения не вызывают. Например, если есть какая то логика инициализации в павнах на ремоут клиентах она вызовется только для вас и игроков подключившихся после вас.
Modulate и Additive подразумевают под собой одну операцию умножения или сложения соответственно. Просто берется текстура сцены, берется вывод эмиссива и производится операция. Translucent имеет больше одной операции, и вроде как там есть деление. Эта оптимизация отлично работает на мобилках, да и в целом помогает.
По поводу нанита и сложной геометрии сказать точно не могу но судя из логики - вы правы, на тяжелой модели видимых вертексов может быть столько же или больше чем видимых пикселей -> вертексный шейдер будет дороже.
По адресу нельзя. Например, макрос AddDynamic просто статически проверяет на этапе компиляции что такая функция есть, но в итоге берет имя функции и биндит по нему.
Сейчас проводим набор на стажировку в компанию, в тестовом у нас есть вопрос про различия делегатов.
Почти у всех вижу, что динамик делегаты можно сериализовать, но почему то никто не пишет, что динамик делегаты биндят функцию по имени, а не по адресу и по этому могут быть использованы в блюпринтах, считаю это упущением данной статьи.
На мой взгляд основное отличие dynamic делегата от статического это именно то, как происходит бинд, от сюда вытакает и все остальное и дает более понимание о механизмах работы.
То есть именно потому что динамик делегат знает имя функции он может быть сериализован, использован в блюпринтах и требует UFUNCTION(). По этому же он и медленнее. Так же хочу заметить, что юникаст динамик делегат тоже может быть использован в блюпринтах как инпут-пин функции.
Спасибо, обязательно посмотрю!
Еще вопрос на тему текстур стороной в степень 2-ки. Я писал статью ,некоторое время назад, на Habr, про разные советы новичкам и не очень (https://habr.com/ru/post/664036/). Упомянул там power-of-2 текстуры. После чего с одним комментатором обсудили эту тему в комментах, да и сам глубже исследовал эту тему и выяснил, что современные не мобильные GPU и графические API года с 2010, примерно, уже нормально производят все нужные операции и не на po2 текстурах. Но эту инфу я собирал по "обрывкам" (там в целом в комментах можно почитать). Можно попросить подсказать на эту тему? Может статью какую где про это полноценно рассказано или иной материал.
С одной стороны я понимаю почему po2 нужно, но если современные железки и софт правда с не po2 нормально работают, то почему это требование до сих пор актуально? Если мы не говорим о обратной сомвестимости с древнегреческим железом или мобильными платформами. Или может я не правильно интерпретировал то, что нашел и современные GPU не работают нормально с не po2 текстурами.
Скажу на тему контроля версий. Работал со всеми, упомянутыми. Скажу что Perforce не люблю больше всего, по ряду причин, основная - отсутствие нормального бранчинга да и бранчинга в принципе, как и многих других нужных фич.
Plastic по заявлением создателей должен решать все наши проблемы при разработке игр:
- Жирнющие репы
- Предохранение от двойного изменений немержащихся файлов (блокировки, валидация оутдейт файлов и тд)
- Сильный бранчинг
- Удобная интеграция разных штуковин, типа тех же сборок на коммит в ветку
С жирными репками работает все отлично и относительно быстро. И по началу работы с ним я его боготворил, но после наработки некоторого опыта открылись проблемы. У меня есть и к бранчингу претензии и от двойного изменения файлов не спасает, но локи хотя бы кросветочные, а не как в p4. Да и багов выше крыши (попробуйте, например поменять юзера в пластике, на июльских версиях), а 4 разных гуя, каждый с разными фичами порой подогревают стул.
Но по отзывам команды, которая раньше работала на p4, а сейчас на пластике - их все устраивает, а стоит он даже в самой дорогой комплектации почти в 2 раза дешевле перфорса. Но не так бесплатно, как гит, конечно.
Git в целом последнее время оч круто себя показывает, по крайней мере мне очень нравится. Sinbad LFS доработал, теперь с ветками нормально все работает и от двойного изменения ассетов кое как, да спасает (спасибо статус бранчам), кодревью удобные (если развернуть GitLab, например) и все интеграции встраиваются на ура.
Я сейчас пишу статейку про все эти системы контроля версий, как мы со всем этим работали и что я об этом всем думаю. Надеюсь, что скоро выйдет - советую ознакомиться, если будет еще интересно. Или если по пластику вопросы будут - обращайтесь, расскажу что смогу.
Кстати, а что думаете на счет снятия локов при мерже в стабильную ветку?
На сколько я знаю на данный момент нету решения, которое спасает от того, что ассет изменился в 2-х фича-ветках. Можем только по "основным" чекать.
И на анриале и на юнити можно делать и мобилки и не мобилки. Но четкий уклон в сторону мобилок у юнити прослеживается и это удобнее и проще на юньке чем на анриляше.
В целом я бы советовал Unreal, на нем все не плохо получается, спецов все еще мало и они востребованы очень.
Тогда все просто - используй не только принты ;-)
Если вопрос конкретно такой: "Что писать на макаронах, а что на С++", а не "Как технически дружить макароны и С++". То ответ наверное такой: лучше пробовать все писать на С++, со временем придет понимание о том, что тебе проще делать на С++.
Я обычно стараюсь придерживаться такой идеи: кор какой то фичи делаем на С++, ее вариации на макаронах, если не подразумевается значительных изменений.
Но и в целом тут в статье есть четки советы что на чем делать.
Ну я как уже и писал выше хочу сделать небольшой материал на эту тему. Когда конкретно - не знаю пока что. Но я вас оповещу!)
К моему великому сожалению - нигде. Подавляющую часть всего рабочего опыта я занимался VR аркадами и подобным контентом для VR парков/клубов/аттракционов. Там титров нет. Была еще парочка клаудгейминго-образных не игровых проектов - там тоже нет.
Из ближайшего - скоро выйдет в софтлаунч мобильная музыкальная аркада, но это очень маленькая и простая игра. Кстати, если вы или кто-то имеет компетенции в проведении мягкого запуска и/или релиза мобильных игр и готов ими поделиться - буду рад если вы мне напишите в личку.
Конечно можно, константные значения очень дешевые. Но в проде то у нас тяжелющие шейдеры с кучей текстур :)
Могу ошибаться, но, кажется, у Additive нету вывода опасити и следовательно 3-го семплирования?
Только стоит учесть, что при запуске мультиплеера в эдиторе, если я правильно помню, сначала подключаются все клиенты - потом вызывается бегин плей.
Так что нужно запустить парочку стандалонов и консолькой их подключить.
1 - Текущий цвет сцены - нужно сделать выборку пикселя по UV сцены
2 - Вывод эмиссива - нужно сделать выборку пикселя по UV и/или вычислить исходя из UV меша
3 - Вывод опасити - нужно сделать выборку пикселя по UV и/или вычислить исходя из UV меша
Ну как минимум тут еще выборка пикселей для операций происходит из 3-х источников, а не из двух. Текстурные выборки опять же весьма дорогие в мобильниках.
Я может когда нибудь сделаю небольшой материал про эти шейдермодели, UV в вертексных шейдерах и что нибудь еще туда запихаю.
Ну кстати пару миллисекунд "из воздуха" то она приносит. Как мне кажется проблема в том, что надо писать понятный код для нативизатора, а не для исполнителя макарон.
Из самых проблем что я помню лично: нативизатор часто не корректно выводил типы. Но иногда он правда делает вообще непонятно откуда взявшиеся баги :(
Подумал, что и так сойдет). Ща будет.
Суть нативизации как мне кажется в том, что бы сгенерить наиболее оптимизируемый компилятором код. Именно от туда бесконечные свичкейсы. А функцию сложения компилятор спокойно размотает до простого lea.
Зависит от ваших целей, проекта, команды и задач. Со всем сразу вы точно не столкнетесь.
Прямо перед вышей цитатой 4 пункта есть для основных классов. Положу сюда тоже:
- все UObject — PostInitProperties, PostLoad
- AActor — PostInitializeComponents, OnConstruction, (и другие)
- UActorComponent — OnRegister, InitializeComponent
- UUserWidget — OnNativeInitialized, OnNativeConstruction
Конкретный кейс - клиент подключается на сервер:
- Его павн, контроллер, стейт вызывают бегин плей и на новом клиенте и везде.
- Все актеры и компоненты жившие на сервере до подключения не вызывают. Например, если есть какая то логика инициализации в павнах на ремоут клиентах она вызовется только для вас и игроков подключившихся после вас.
Modulate и Additive подразумевают под собой одну операцию умножения или сложения соответственно. Просто берется текстура сцены, берется вывод эмиссива и производится операция. Translucent имеет больше одной операции, и вроде как там есть деление. Эта оптимизация отлично работает на мобилках, да и в целом помогает.
По поводу нанита и сложной геометрии сказать точно не могу но судя из логики - вы правы, на тяжелой модели видимых вертексов может быть столько же или больше чем видимых пикселей -> вертексный шейдер будет дороже.