Отличный контент, продолжай. Про репликацию расскажи пожалуйста. И как правильно выстраивать архитектуру сетевой игры. Например в каких классах и какую логику делать
Ну это и так было понятно еще с C#. Я все еще жду краткий курс по профайлеру))) Это действительно важно для оптимизации фреймтайма. Я то об этом знаю, а народ в недоумении. Им рассказываешь как правильно выявлять потенциальные проблемы в производительности кода игры, а они вообще как будто первый раз в движок зашли) Автору печенек, профайлер ждет)))
Отличные видосы но объяснение про Pure некорректное и почти извращенное до наоборот :) Матерые плюсисты поправят, если что. Первое и самое важное. Pure это указание компилятору что функция потенциально является Pure функцией. Это не рубильник и не волшебная палочка. В реальных языках смысл Pure функций в том что они возвращают один и тот же результат при одинаковых аргументах, и исполнятся только один раз если значение аргументов не менялось(и ничего не менялось в памяти между вызовами что могло бы повлиять на результат), но в качестве ограничения не могут изменять ничего вне себя. Полное определение можно прочитать самим. Сколько угодно вызовов одной и той же pure функции с одинаковыми аргументами на входе (при условии что ничего не менялось в памяти между вызовами этой функции что могло бы повлиять на результат) приведёт к 1(одному) вызову фукнции и передачи полученного значения для последующих вызовов. Экономия понятна - если вычисления абсолютно точные и однозначные но тяжелые, то между посчитать 100 раз или 1 раз и 99 просто отдать уже посчитанное разница может быть большая. Примерно так как это было показано в твоём примере с обычной функцией. Посчитала, записала в "память" и раздаёт всем кто спрашивает. С той разницей что pure функция пересчитает снова если что-то изменилось между вызовами что могло повлиять на конечный результат, а твоя обычная функция выдавала то же значение просто потому что была вызвана 1 раз. Отдельная ирония твоего примера что в реальных языках функция выдающая рандомное число по определению не может быть pure. Поэтому в этой галке для этой конкретной реализации смысла нет. Теперь про блюпринты. Основное различие это дизайн вызова. Количество подсоединений к выводу функции с атрибутом pure = количеству её вызовов. Я специально не написал "pure функции", потому что это компилятор решит на самом деле она pure или вам только так кажется и он зря потратил время на проверку. Вызов обычных функций происходит только в определенной последовательности посредством execution pins(белый жирная проводка). Именно поэтому обычная функция(не pure) MyTestFunction в примере с тремя выводами дала одно и тоже значение. Она была в одном экземпляре вызвана(одна нода MyTestFunction c белой проводкой), а результат был запрошен три раза. Если хотели вызвать три раза, так и ноды MyTestFunction должно было быть три. Но это не имеет к чистоте(Pure) функций никакого отношения. Резюме: - если вы вызовите обычную функцию N-раз с одними и теми же аргументами, то она N-раз от начала до конца исполнится. - если вы вызовите функцию N-раз с одними и теми же аргументами у которой стоит галка Pure и она действительно окажется соответствующей определению Pure функции, то она в самом радужном случае исполнится 1 раз от начала до конца и ещё N минус 1 раз просто выдаст уже посчитанное в первый раз значение. В самом НЕ радужном случае она просто исполнится N раз как и обычная функция
Спасибо большое :) На самом деле не вижу противоречий :) Видео не про другие языки, а про блюпринты, и да, блюпринтовый термин "Pure" не является аналогом "Pure" в других языках программирования. И да, Pure-функции в блюпринтах нужны для удобства, для сокращения пинов, по словам самих же эпиков. И если потестите без рандомного интегера, с одинаковым аргументом, то все равно блюпринтовая pure-функция будет выполняться столько раз, сколько тянем пин.
@@UNREALRUSSIA А инфа 100% про то что Pure в блюпринтах никак в конечном итоге не превращается в атрибут для компилятора?) Я не тестил и не смотрел исходники во что выливается BlueprintPure, просто не хотелось бы в таких фундаментальных конструкциях и потенциальной возможности оптимизации чего-то неправильно понимать :) п.с. Ну противоречия были как минимум в противопоставлении одного вызова трём вызовам) Не будет же кто-то в самом деле ожидать что считывание результата единственного вызова выдаст разные результаты)
@@yrussq Тут не нужно так глубоко копать, просто иметь ввиду, что каждый блок подключений к Pure - вызовет её логику повторно. Я столкнулся с этим когда Pure функции были в загрузке инвентаря и всё что с ним связано (что естественно очень быстро должно происходить) в них были циклы поиска и всего всего разного, естественно кому оно нужно циклы гонять одни и те же с одним результатом.
@@gostbastard2569 Учитывая что Блюпринты являются обёрткой для плюсов и существуют с ними бок о бок странно что в одном элементе с известным межязыковым определением и функционалом Эпики вдруг решили пороть отсебятину.
У меня возник маленький вопрос, что за монитор у тебя ?? Просто я тут сижу и думаю на каком мне будет лайтово работать the project 6 (3-6ч в день) что бы не вытекли глаза ;3 на примете 2 моника: 27" Монитор LG UltraGear 27GL850-B и Iiyama G-Master GB3461WQSU-B1 34 " Заранее спасибо за ответ и видос!)
Не хватает информации о том как ведут себя pure функции с несколькими аутпутами. Сколько раз они вызываются? Каждый раз на каждый аутпут? Почему тогда существуют pure функции в движке которые очень нагружают цпу, например поиск пути?
Вроде один раз вызывается, если все выходы подключаются к одному блоку, если к двум, то все выходы просчитаются два раза и т.д.. По поводу нагрузки, эти функции можно сохранять предварительно в переменные, и дальше по логике использовать переменную. Pure функции лично я использую для удобства, при проверки множества булевых переменных, с одним выводом, чтобы каждый раз не громоздить логику, или быстрый поиск чего либо по стрингу или ID.
Автор ролика, нужно проверять информацию, перед тем как создавать видео для неокрепших умов, GetActorLocation константная инлайн функция, НЕ ПЬЮР! Плюсовые конст функции выглядят в БП как пьюр, но они не пьюр! Так что последняя часть ролика - заблуждение.
Спасибо. Весьма полезная информация про привычные казалось бы вещи.
Коммент в поддержку для продвижения полезного видоса,)
Отличный контент, продолжай. Про репликацию расскажи пожалуйста. И как правильно выстраивать архитектуру сетевой игры. Например в каких классах и какую логику делать
Очень классный контент. Посмотрел все уроки. Снимай ещё )
Ждемс еще ролики про паттерны)
Ну это и так было понятно еще с C#. Я все еще жду краткий курс по профайлеру))) Это действительно важно для оптимизации фреймтайма. Я то об этом знаю, а народ в недоумении. Им рассказываешь как правильно выявлять потенциальные проблемы в производительности кода игры, а они вообще как будто первый раз в движок зашли) Автору печенек, профайлер ждет)))
Когда-нибудь докатимся и до профайлера :)
Отличные видосы но объяснение про Pure некорректное и почти извращенное до наоборот :) Матерые плюсисты поправят, если что.
Первое и самое важное. Pure это указание компилятору что функция потенциально является Pure функцией. Это не рубильник и не волшебная палочка.
В реальных языках смысл Pure функций в том что они возвращают один и тот же результат при одинаковых аргументах, и исполнятся только один раз если значение аргументов не менялось(и ничего не менялось в памяти между вызовами что могло бы повлиять на результат), но в качестве ограничения не могут изменять ничего вне себя. Полное определение можно прочитать самим.
Сколько угодно вызовов одной и той же pure функции с одинаковыми аргументами на входе (при условии что ничего не менялось в памяти между вызовами этой функции что могло бы повлиять на результат) приведёт к 1(одному) вызову фукнции и передачи полученного значения для последующих вызовов.
Экономия понятна - если вычисления абсолютно точные и однозначные но тяжелые, то между посчитать 100 раз или 1 раз и 99 просто отдать уже посчитанное разница может быть большая.
Примерно так как это было показано в твоём примере с обычной функцией. Посчитала, записала в "память" и раздаёт всем кто спрашивает. С той разницей что pure функция пересчитает снова если что-то изменилось между вызовами что могло повлиять на конечный результат, а твоя обычная функция выдавала то же значение просто потому что была вызвана 1 раз.
Отдельная ирония твоего примера что в реальных языках функция выдающая рандомное число по определению не может быть pure. Поэтому в этой галке для этой конкретной реализации смысла нет.
Теперь про блюпринты.
Основное различие это дизайн вызова.
Количество подсоединений к выводу функции с атрибутом pure = количеству её вызовов. Я специально не написал "pure функции", потому что это компилятор решит на самом деле она pure или вам только так кажется и он зря потратил время на проверку.
Вызов обычных функций происходит только в определенной последовательности посредством execution pins(белый жирная проводка).
Именно поэтому обычная функция(не pure) MyTestFunction в примере с тремя выводами дала одно и тоже значение.
Она была в одном экземпляре вызвана(одна нода MyTestFunction c белой проводкой), а результат был запрошен три раза.
Если хотели вызвать три раза, так и ноды MyTestFunction должно было быть три.
Но это не имеет к чистоте(Pure) функций никакого отношения.
Резюме:
- если вы вызовите обычную функцию N-раз с одними и теми же аргументами, то она N-раз от начала до конца исполнится.
- если вы вызовите функцию N-раз с одними и теми же аргументами у которой стоит галка Pure и она действительно окажется соответствующей определению Pure функции, то она в самом радужном случае исполнится 1 раз от начала до конца и ещё N минус 1 раз просто выдаст уже посчитанное в первый раз значение.
В самом НЕ радужном случае она просто исполнится N раз как и обычная функция
Спасибо большое :) На самом деле не вижу противоречий :) Видео не про другие языки, а про блюпринты, и да, блюпринтовый термин "Pure" не является аналогом "Pure" в других языках программирования. И да, Pure-функции в блюпринтах нужны для удобства, для сокращения пинов, по словам самих же эпиков. И если потестите без рандомного интегера, с одинаковым аргументом, то все равно блюпринтовая pure-функция будет выполняться столько раз, сколько тянем пин.
@@UNREALRUSSIA А инфа 100% про то что Pure в блюпринтах никак в конечном итоге не превращается в атрибут для компилятора?) Я не тестил и не смотрел исходники во что выливается BlueprintPure, просто не хотелось бы в таких фундаментальных конструкциях и потенциальной возможности оптимизации чего-то неправильно понимать :)
п.с. Ну противоречия были как минимум в противопоставлении одного вызова трём вызовам) Не будет же кто-то в самом деле ожидать что считывание результата единственного вызова выдаст разные результаты)
@@yrussq Тут не нужно так глубоко копать, просто иметь ввиду, что каждый блок подключений к Pure - вызовет её логику повторно. Я столкнулся с этим когда Pure функции были в загрузке инвентаря и всё что с ним связано (что естественно очень быстро должно происходить) в них были циклы поиска и всего всего разного, естественно кому оно нужно циклы гонять одни и те же с одним результатом.
@@gostbastard2569 Учитывая что Блюпринты являются обёрткой для плюсов и существуют с ними бок о бок странно что в одном элементе с известным межязыковым определением и функционалом Эпики вдруг решили пороть отсебятину.
Хотелось бы уроки про наследование классов.
Все супер. Побольше бы таких подробных уроков!
Thanks!
Я знал это! Спасибо за демонстрацию
как же охуенно, главное не бросайте нас
У меня возник маленький вопрос, что за монитор у тебя ??
Просто я тут сижу и думаю на каком мне будет лайтово работать the project 6 (3-6ч в день) что бы не вытекли глаза ;3
на примете 2 моника: 27" Монитор LG UltraGear 27GL850-B и Iiyama G-Master GB3461WQSU-B1 34 "
Заранее спасибо за ответ и видос!)
Спасибо, полезно
Не хватает информации о том как ведут себя pure функции с несколькими аутпутами. Сколько раз они вызываются? Каждый раз на каждый аутпут? Почему тогда существуют pure функции в движке которые очень нагружают цпу, например поиск пути?
Вроде один раз вызывается, если все выходы подключаются к одному блоку, если к двум, то все выходы просчитаются два раза и т.д.. По поводу нагрузки, эти функции можно сохранять предварительно в переменные, и дальше по логике использовать переменную.
Pure функции лично я использую для удобства, при проверки множества булевых переменных, с одним выводом, чтобы каждый раз не громоздить логику, или быстрый поиск чего либо по стрингу или ID.
Спасибо за разъяснение!
Спасибо, было полезно
Вау...
GetActorLocation() является const функцией, а не pure) Хоть и помечается так же
Как бы функция может одновременно быть и pure и const =_=
@@moondi4368 Да, но не в этом случае) Там она BlueprintCallable, можно посмотреть функция K2_GetActorLocation() в Actor.h
++ Спасибо за дополнение!
лукойл
Классы и объекты путаете.
Автор ролика, нужно проверять информацию, перед тем как создавать видео для неокрепших умов, GetActorLocation константная инлайн функция, НЕ ПЬЮР! Плюсовые конст функции выглядят в БП как пьюр, но они не пьюр! Так что последняя часть ролика - заблуждение.