А что срач, за не юзать С++?

за обратное

почему сразу срач? спор

все споры рано или поздно сходятся: - на ВР хорошо прототипирование - на С++ хороша большая разработка Если в команде 1-2+ программиста, то вероятно уже ВР будет больно. и т.д и т.п. Я уже молчу что плюсы все же дают больший аспект возможностей. Но для многих маленьких разработок на одного разработчика ВР может быть с головой и будет прекрасно

так сам факт перехода на плюсы не решает "больно". На плюсах в гите тоже можно писать один и тот же исходник и потом страдать при слиянии. А когда твой код затирают и ты даже по логу не можешь найти кто и за что его затер? За то и говорю, что плюсы это не панацея, а принты недооценивают потомучто на них чаще пишут новички.

Ты говорил. Что у тебя есть еще притензии к статье? Мне было бы интересно узнать какие)

@ivcgl

То есть только про с++? Ты просто говорил много претензий...

"Дизайнить UMG виджеты в С++ вы не сможете" - это вообще как понимать? Собираешься кодом раскидывать компоненты по форме?

Скорее собираюсь отговорить людей так делать :-)

Ну а когда со студии убрали WinForm в одной из версии разве оно не было так? вы в VS работаете?

И как только HTML с 93-ого года могли таким заниматься... Ужас!

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

Ну разве что из-за IE6 и местами от отсутствия полной поддержки спецификаций некоторыми браузерами

да я со всем работаю и в VS С++/C# и js и php. Но вроде как-то не было проблем с WinForm, оно осталось в легаси и мы его не трогали )

Примерно так, да ))) но это как раз следствие того, что я написал выше )

"Под взаимодействием объектов в рамках игры мы обычно понимаем вызов функций из одного объекта в другом. Или вызовы из одной группы объектов в другую (например разные игровые системы)." - мне кажется, здесь не достаточно или слишком запутано раскрывается необходимость работы с интерфейсами/событиями. Их основная польза в том, что они позволяют избежать ненужных зависимостей, а именно - никакой объект 1 не должен знать о структуре другого объекта 2, если только объект 2 не является дочерним по отношение объекту 1. В тех проектах, что мне доводилось рефакторить-оптимизировать это была прям серьезной проблемой для внесения изменений.

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

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

Такие проверки могут вызвать лаги

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

есть пример, когда branch вызывал лаги в тике?

Если ты чекаешь bool в bp в тике, это уже оверхед, это уже вызов в vm. И так с каждым тикающим объектом в твоем мире.

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

Этому точно стоит научится самому, я считаю

Когда ты проверяешь допустим на nullptr что-то на тике - это потенциально кэшмис + бранч мисспредикшин

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

о, кешмис, забавно 😂

?