для мобильных игр - это весьма прилично. Если поддерживать слабые девайсы с 1ГБ ОЗУ, то приложению по факту доступно всего около 600мб. В таком случае 35мб может оказаться критично
Это и правда классный подход, но имхо не для всего подходит. Все таки игра не это не только (и далеко не всегда) туча бегающих юнитов, куча рассчетов и т.п. Есть куча UI, особенно в мобайле, где все это просто вредит, т.к. код становится сильно сложнее.
Для такой не требовательной к производительности логике нужно максимальное удобство, и в С++ это дают умные указатели и более простая схема работы
кхм.. мной, с учетом платформ. Ничего специфичного пока в моих планах нет, скорее всего размера 4 + 4 будет достаточно для всех платформ - ios/andoird/mac/win/linux/web. Ну а если понадобится, конечно, добавлю выравнивание здесь
Да, если без фанатизма, то все впорядке. На крайний случай в какие-то тяжелые алгоритмы можно и сырой указатель передать. Умные указатели решают проблему утечек и менеджмента памяти, что в играх весьма актуально
Это работает чисто из-за оптимизации компилятора. Факт остается фактом - это два поинтера. Сравнивать два поинтера, надеясь что там одинаковые данные - не очень хорошо
Сложения строк у вас нет, поставьте между ними плюс. Компилятор считает это одной строкой
И обратите внимание, как пришлось протаскивать конструкторы через два шаблонных класса, чтобы my_vector можно было проинициализировать так же легко, как и std::vector.
my_vector здесь чисто ради примера, потому что std::vector модифицировать я не могу.
Раскомментируйте последнюю строку в функции abcx() и заставьте работать ваш вариант так же, как работает вариант с функцией abcy().
я согласен, чуток универсальности теряется. Но это довольно синтетический кейс, по крайней мере для меня. Мне гораздо чаще нужна работа с конкретной коллекцией. А таких шаблонных функций с алгоритмами внутри мало, над ними можно попариться
я этой лошади баксы платил! Хорошая лошадь
Согласен, справедливости ради эта игра получилось скорее не игрой, а техно-демкой движка и тулсета
и да, и нет. Мои личные выводы про нейрослоп - в конце статьи, отчасти я согласен со всеми хейтерами нерослопа
Но статья о другом, о том что один человек может реализовать свою идею игры и не убить на это джва года
спасибо!
Очень даже тянут )
интересно, спасибо ) но мне как раз хоть какой-то размер нужен, т.к. в через рефлексию могу ссылаться на property по указателю
Так вот в начае же как раз, чтобы иметь нормальный синтаксис математических операций
actor.transform = left.transformrigh.transformup.transform;для мобильных игр - это весьма прилично. Если поддерживать слабые девайсы с 1ГБ ОЗУ, то приложению по факту доступно всего около 600мб. В таком случае 35мб может оказаться критично
По сути этот вариант эквивалентен
SCOPE_EXIT.Автор пишет что такой вариант помог, но еще оставались некомпилируемые тестыСогласен, немного дополнил это место. Спасибо!
Это и правда классный подход, но имхо не для всего подходит. Все таки игра не это не только (и далеко не всегда) туча бегающих юнитов, куча рассчетов и т.п. Есть куча UI, особенно в мобайле, где все это просто вредит, т.к. код становится сильно сложнее.
Для такой не требовательной к производительности логике нужно максимальное удобство, и в С++ это дают умные указатели и более простая схема работы
Плюсую. Как бы аккуратно не был сделан менеджмент памяти в движке, в игровом коде будет ад и содомия
кхм.. мной, с учетом платформ. Ничего специфичного пока в моих планах нет, скорее всего размера 4 + 4 будет достаточно для всех платформ - ios/andoird/mac/win/linux/web. Ну а если понадобится, конечно, добавлю выравнивание здесь
Хм, и я так считал. Но у меня буквально был опыт сравнения двух подходов - сырыу указатели в домашнем проекте и умные на работе.
Тем более что движко позволяет писать игровую логику на С++, и там вероятность ошибки слишком велика. Поэтому умные указатели здесь решают
В целом да, здесь явно не учтено выравнивание, но блок счетчика подбирается как раз под размер выравнивания, поэтому проблемы нет
На самом деле с умными указателями не так все плохо. В целом накладные ресурсы довольно маленькие, а со счетчиком перед объектом и вовсе мизерные
Да, если без фанатизма, то все впорядке. На крайний случай в какие-то тяжелые алгоритмы можно и сырой указатель передать. Умные указатели решают проблему утечек и менеджмента памяти, что в играх весьма актуально
В россии очень любят две вещи: хаять что ничего своего не делают и хаять когда делают свое
Это работает чисто из-за оптимизации компилятора. Факт остается фактом - это два поинтера. Сравнивать два поинтера, надеясь что там одинаковые данные - не очень хорошо
Сложения строк у вас нет, поставьте между ними плюс. Компилятор считает это одной строкой
На лицо skill issues )))
my_vectorздесь чисто ради примера, потому что std::vector модифицировать я не могу.я согласен, чуток универсальности теряется. Но это довольно синтетический кейс, по крайней мере для меня. Мне гораздо чаще нужна работа с конкретной коллекцией. А таких шаблонных функций с алгоритмами внутри мало, над ними можно попариться