Виктор Ковылин
Сейчас проводим набор на стажировку в компанию, в тестовом у нас есть вопрос про различия делегатов.
Почти у всех вижу, что динамик делегаты можно сериализовать, но почему то никто не пишет, что динамик делегаты биндят функцию по имени, а не по адресу и по этому могут быть использованы в блюпринтах, считаю это упущением данной статьи.
На мой взгляд основное отличие 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, на нем все не плохо получается, спецов все еще мало и они востребованы очень.
Тогда все просто - используй не только принты ;-)
Если вопрос конкретно такой: "Что писать на макаронах, а что на С++", а не "Как технически дружить макароны и С++". То ответ наверное такой: лучше пробовать все писать на С++, со временем придет понимание о том, что тебе проще делать на С++.
Я обычно стараюсь придерживаться такой идеи: кор какой то фичи делаем на С++, ее вариации на макаронах, если не подразумевается значительных изменений.
Но и в целом тут в статье есть четки советы что на чем делать.
Ну я как уже и писал выше хочу сделать небольшой материал на эту тему. Когда конкретно - не знаю пока что. Но я вас оповещу!)
По адресу нельзя. Например, макрос AddDynamic просто статически проверяет на этапе компиляции что такая функция есть, но в итоге берет имя функции и биндит по нему.