В том-то и дело, что существует не только вэб-программирование. Можно связать жизнь с чем-то другим и с линуксом вообще никогда не сталкиваться. Если уж на то пошло, то для клиентских приложений лучше подходит Макось, потому что на чем-то другом разрабатывать под Айос нельзя, а клиентские программы очень хотят существовать и там тоже. Нельзя именно из-за хитрой лицензии Эппл, запрещающей разработку на чем-то другом.
Статья слишком сильно манипулирует выводами на основе субъективных ощущений автора
Она и начинается с дисклеймера о субъективности написанного. Но при этом в самой статье встречаются радикальные заявления о понятии "инженер", что немножко противоречит дисклеймеру.
Спасибо за статью. Очень ëмко и просто навела на некоторые мысли.
Я не мог начать пользоваться Rust пять лет назад из-за того, что просто не представлял, как со всеми этими ограничениями можно что-то сделать. То есть нужно действительно начать мыслить по-другому.
Сейчас у меня есть опыт параллельного программирования в С++, в этом очень сильно помогли умные указатели, которые следят за владением объекта и чисткой памяти. Они гарантируют отсутствие битых указателей, т.к. пока какой-то поток "одолжил" указатель, память в нем не чистится. Как недостаток, нельзя сказать точно, когда в рантайме объект освободится и в какой момент запустится деструктор, а главное из какого потока (например, к OpenGL можно обращаться только из главного потока, поэтому просто так из деструктора объекта, хранящиеся в shared_ptr, данные OpenGL не удалишь).
Тем не менее умные указатели и ссылки в плюсах - очень крутые средства, спасающие от выстрела в ногу. Мне кажется, заставив себя на них перекатиться, я постепенно дойду и до понимания Rust.
А теперь вопрос (он наверняка гуглится, но если всë гуглить, то о чем писать в комментах?). Rust многие вещи делает в компиляторе. Это ведь и по эффективности получается лучше, чем ООП в плюсах со всякими контейнерами и умными указателями? В плюсах это наверняка сплошной рантайм и достаточно тяжелый.
Приведу пример, как можно сделать делегат с параметрами без создания обертки, так это обычно и используют:
public class Health {
public delegate void DamageTaken(float damage);
public event DamageTaken OnDamageTaken; // will be triggered on damage
public delegate void PlayerDead(); // will be triggered when dead.
public event PlayerDead OnDead;
private float health = 100;
// call this to do damage
public void TakeDamage(float damage) {
if (health <= 0) return;
health -= 20;
if (OnDamageTaken != null) // null check is required because if there is no subscribers it produces error when invoking
{
OnDamageTaken.Invoke(damage);
}
if (health <= 0) {
if (OnDead != null) {
OnDead.Invoke();
}
}
}
}
С переменными идея понятна, т.к. хочется, чтобы можно было подписываться на изменение переменной. Но всё равно делать их публичными - очень плохое архитектурное решение. Если нужно подписаться на изменение здоровья извне, надо создать соответствующий ивент или делегат. Иногда можно нарушать правила, но в подобных статьях я не делал бы этого. Новичков и так постоянно учат плохому.
Насчет ссылок и указателей плохо понял. В С# любая переменная, содержащая объект, это аналог shared_ptr из C++ со всеми вытекающими проблемами. Есть кстати в C# и обычные C указатели, ими можно пользоваться в unsafe коде. Узнал недавно и удивился :)
P.S.: в этом примере делается проверка на null, но есть более короткая форма OnDamageTaken?.Invoke(damage);
По этой статье совершенно непонятно, зачем нужна обертка вокруг делегата, которая делает в точности то же самое, что и он? Также странное решение делать публичные переменные, обернутые в обертки. Какой-то ужасно приторный синтаксический сахар просто чтобы показать, что автор умеет писать шаблонные методы. Все это можно накодить в 3 строчки кода, если просто правильно пользоваться знанием среды и языка, не изобретая велосипед. Возможно, я неправ.
Подход делить логики и использовать делегаты сам по себе неплох. Но это тоже подходит не для всего. В некоторых случаях просто необходимо забить логику гвоздями просто чтобы никто ее не сломал неправильной настройкой компонентов. А делегаты - это больше чтобы звуки и партиклы на персонажа вешать
Автор сам себя дискредитировал тем, что пошел кодить критичную к производительности задачу совершенно не подходящим для этого способом. Там не только switch и c-стайл, но и ассемблер будет не лишним.
А чистый код это больше высокоуровневая архитектура и вот это вот все. Какие-нибудь сервисы, общающиеся с 1000 других сервисов. И это происходит в вэбе, в котором такие задержки, что выигрыш в паре тактов процессора вообще не принесет пользы.
Ну тут видимо изучалось одно конкретное явление. Вообще у ЧД уйма замудрённых свойств таких как специфические магнитные поля, виртуальные фотоны, смещение спектра (упомянутого в сообщении выше). В результате вращения ЧД ореол диска немного искажается и сбоку становится видно небольшой "пузырёк" (тоже линзирование, можно найти картинки с ним). Не представляю как вообще возможно было бы всё это симулировать :) Ну а в данном конкретном видео очевидно — сферическая черная дыра в вакууме.
На gamedev.ru гуляет легенда о том что те, кто пишут с нуля 3д движки, сходят с ума. И там еще был список из форумчан которые реально легли в дурку и скриншоты их наработок достаточнр
о неплохие
ну это уж слишком, зачем так-то жестко разваливать? это же удар ниже пояса. даже не знаю теперь как отмыться от такого позора. "обычная игра на анриле/юнити" — боже как я до этого докатился! пойду качать nvidia sdk и гуглить аудио библиотеки. вот прям чувствую, сразу все изменится
Ну можно вывести не треугольник, а два треугольника, получится квадратный спрайт. Практически готовый графический движок для 2д игр. Иронизирую конечно, но для легких мобилок актуально.
Есть еще разные уровни велосипедизма. Можно собирать движок из готовых библиотек, а можно начать с кода инициализации из туториалов по opengl. Или вообще запилить софтверный рендер. Я все три проходил, одну игру даже смог доделать (остальные забаговались), но сейчас слишком стар для этого
Справедливости ради стоит заметить, что чаще всего портирование одной кнопкой, как заявлено аторами движков, не работает в том плане, что все равно нужно частично что-то переделывать, оптимизировать, да и platform specific features никуда не деваются. Что-то может сломаться, не сработать на одной из платформ, самописные шейдеры могут не отрисоваться, все это надо отлаживать, а на это нужно время.
В засчиту Unity скажу то, что в нём предусмотрена переработка графического конвейера. В традиционном рендере есть Command Buffer, которым реально полностью убрать систему освещения и написать свою. Плюс у меня есть статья, где я костыльно улучшал освещение, модифицируя встроенные шейдеры (на этом принципе, а возможно даже на и моих наработках, реализован ассет Next Gen Soft Shadows). В новых версиях разработчики пошли дальше и сделали программируемый рендер конвейер, который можно полностью переписать, и в нем из коробки реализованы красивые штуки уровня Unreal.
Это все про рендер, то есть про самую требовательную для ресурсов и для многих критичную часть. Резюмирую: все можно переделать под себя или даже заменить полностью.
Что касается остального, то если допустим вам не нужна 2д физика, выключаете компонент, и ресурсы попросту не тратятся. Конечно, библиотеки все равно будут занимать в памяти драгоценные мегабайты, но это та цена, которая осознанно платится за удобство кроссплатформенности.
Что касается скриптов, системы объектов и всего прочего, то в самописном движке вы придете к тому же самому. Не знаю как тесно вплетено все в код Unreal и как трудно от этого отойти, но в Юнити можно реализовать кучу разных подходов, систем сообщений, достаточно легко пишутся расширения редактора чтоб сделать удобные тулзы. И даже ярый велосипедист окажется рад перекатиться в эту среду разработки, если приложит минимальное усилие на начальном этапе.
В целом в статье всё до банального очевидно. Если планируется совсем лютый эксперимент или мобилка — лучше не пользоваться тяжёлым движком.
Но абзац про динамические библиотеки в Unity и Unreal поставил в тупик. Мало того что библиотеки там вообще не для игрового кода ну никак, а для расчетов каких-то жестких или для расширений конкретного движка. Так еще и рассматривается вероятность в серьезном проекте поменять движок в середине разработки. Это как бы ошибка планирования и так делать не надо. Либо это долгострой, в котором на определенном этапе лучше что-то написать заново.
Как правило, люди, много читающие, жанровые книги предпочитают экспериментальным. Кто если не эти люди будут покупать инди-книги. Они отнюдь не "идиоты", а скорее, наоборот, начитанные интеллигенты, которым в какой-то момент стало мало того, что продается в магазинах, в том или ином смысле.
Ради собственного удовольствия можно писать максимум рассказики в интернете. Но даже с ними приходится проводить серьезную скучную работу, если дело доходит до самого мелкого конкурса (не ради победы так ради того чтобы попасться на глаза новым читателям и желательно не отхватить тухлых помидоров). А уж когда нужно довести до конца роман, не такая уж и большая разница — жанровый он или экспериментальный. Работы непочатый край. С книгой мечты, наверное, даже больше мучений. Особенно если учесть, что скорее всего, это пишется в стол.
Этот ход часто использовали в фильмах и книгах: сначала идёт эпизод из кульминации, чтобы завлечь в сюжет, а потом уже можно перейти к тому, «как всё начиналось».
Игра начинается в общественном туалете, что помогает игроку свыкнуться с тем, что его ждёт в игре. Когда я это написал, мне начало казаться, что это действительно могло быть задумкой авторов, учитывая их неординарность.
В том-то и дело, что существует не только вэб-программирование. Можно связать жизнь с чем-то другим и с линуксом вообще никогда не сталкиваться. Если уж на то пошло, то для клиентских приложений лучше подходит Макось, потому что на чем-то другом разрабатывать под Айос нельзя, а клиентские программы очень хотят существовать и там тоже. Нельзя именно из-за хитрой лицензии Эппл, запрещающей разработку на чем-то другом.
Она и начинается с дисклеймера о субъективности написанного. Но при этом в самой статье встречаются радикальные заявления о понятии "инженер", что немножко противоречит дисклеймеру.
Спасибо за статью. Очень ëмко и просто навела на некоторые мысли.
Я не мог начать пользоваться Rust пять лет назад из-за того, что просто не представлял, как со всеми этими ограничениями можно что-то сделать. То есть нужно действительно начать мыслить по-другому.
Сейчас у меня есть опыт параллельного программирования в С++, в этом очень сильно помогли умные указатели, которые следят за владением объекта и чисткой памяти. Они гарантируют отсутствие битых указателей, т.к. пока какой-то поток "одолжил" указатель, память в нем не чистится. Как недостаток, нельзя сказать точно, когда в рантайме объект освободится и в какой момент запустится деструктор, а главное из какого потока (например, к OpenGL можно обращаться только из главного потока, поэтому просто так из деструктора объекта, хранящиеся в shared_ptr, данные OpenGL не удалишь).
Тем не менее умные указатели и ссылки в плюсах - очень крутые средства, спасающие от выстрела в ногу. Мне кажется, заставив себя на них перекатиться, я постепенно дойду и до понимания Rust.
А теперь вопрос (он наверняка гуглится, но если всë гуглить, то о чем писать в комментах?). Rust многие вещи делает в компиляторе. Это ведь и по эффективности получается лучше, чем ООП в плюсах со всякими контейнерами и умными указателями? В плюсах это наверняка сплошной рантайм и достаточно тяжелый.
С этим соглашусь
Приведу пример, как можно сделать делегат с параметрами без создания обертки, так это обычно и используют:
С переменными идея понятна, т.к. хочется, чтобы можно было подписываться на изменение переменной. Но всё равно делать их публичными - очень плохое архитектурное решение. Если нужно подписаться на изменение здоровья извне, надо создать соответствующий ивент или делегат. Иногда можно нарушать правила, но в подобных статьях я не делал бы этого. Новичков и так постоянно учат плохому.
Насчет ссылок и указателей плохо понял. В С# любая переменная, содержащая объект, это аналог shared_ptr из C++ со всеми вытекающими проблемами. Есть кстати в C# и обычные C указатели, ими можно пользоваться в unsafe коде. Узнал недавно и удивился :)
P.S.: в этом примере делается проверка на null, но есть более короткая форма OnDamageTaken?.Invoke(damage);
По этой статье совершенно непонятно, зачем нужна обертка вокруг делегата, которая делает в точности то же самое, что и он? Также странное решение делать публичные переменные, обернутые в обертки. Какой-то ужасно приторный синтаксический сахар просто чтобы показать, что автор умеет писать шаблонные методы. Все это можно накодить в 3 строчки кода, если просто правильно пользоваться знанием среды и языка, не изобретая велосипед. Возможно, я неправ.
Подход делить логики и использовать делегаты сам по себе неплох. Но это тоже подходит не для всего. В некоторых случаях просто необходимо забить логику гвоздями просто чтобы никто ее не сломал неправильной настройкой компонентов. А делегаты - это больше чтобы звуки и партиклы на персонажа вешать
Автор сам себя дискредитировал тем, что пошел кодить критичную к производительности задачу совершенно не подходящим для этого способом. Там не только switch и c-стайл, но и ассемблер будет не лишним.
А чистый код это больше высокоуровневая архитектура и вот это вот все. Какие-нибудь сервисы, общающиеся с 1000 других сервисов. И это происходит в вэбе, в котором такие задержки, что выигрыш в паре тактов процессора вообще не принесет пользы.
Ну тут видимо изучалось одно конкретное явление. Вообще у ЧД уйма замудрённых свойств таких как специфические магнитные поля, виртуальные фотоны, смещение спектра (упомянутого в сообщении выше). В результате вращения ЧД ореол диска немного искажается и сбоку становится видно небольшой "пузырёк" (тоже линзирование, можно найти картинки с ним). Не представляю как вообще возможно было бы всё это симулировать :) Ну а в данном конкретном видео очевидно — сферическая черная дыра в вакууме.
В какой-то мере потемнение справа на симуляции НАСА можно отнести к этому эффекту.
Возможно, на симуляции не видимый спектр, а диапазон радиоизлучения (как на снимке, сделанном в этом году).
На gamedev.ru гуляет легенда о том что те, кто пишут с нуля 3д движки, сходят с ума. И там еще был список из форумчан которые реально легли в дурку и скриншоты их наработок достаточнр
о неплохие
ну это уж слишком, зачем так-то жестко разваливать? это же удар ниже пояса. даже не знаю теперь как отмыться от такого позора. "обычная игра на анриле/юнити" — боже как я до этого докатился! пойду качать nvidia sdk и гуглить аудио библиотеки. вот прям чувствую, сразу все изменится
( ;-p )
Ну можно вывести не треугольник, а два треугольника, получится квадратный спрайт. Практически готовый графический движок для 2д игр. Иронизирую конечно, но для легких мобилок актуально.
Есть еще разные уровни велосипедизма. Можно собирать движок из готовых библиотек, а можно начать с кода инициализации из туториалов по opengl. Или вообще запилить софтверный рендер. Я все три проходил, одну игру даже смог доделать (остальные забаговались), но сейчас слишком стар для этого
Справедливости ради стоит заметить, что чаще всего портирование одной кнопкой, как заявлено аторами движков, не работает в том плане, что все равно нужно частично что-то переделывать, оптимизировать, да и platform specific features никуда не деваются. Что-то может сломаться, не сработать на одной из платформ, самописные шейдеры могут не отрисоваться, все это надо отлаживать, а на это нужно время.
В засчиту Unity скажу то, что в нём предусмотрена переработка графического конвейера. В традиционном рендере есть Command Buffer, которым реально полностью убрать систему освещения и написать свою. Плюс у меня есть статья, где я костыльно улучшал освещение, модифицируя встроенные шейдеры (на этом принципе, а возможно даже на и моих наработках, реализован ассет Next Gen Soft Shadows). В новых версиях разработчики пошли дальше и сделали программируемый рендер конвейер, который можно полностью переписать, и в нем из коробки реализованы красивые штуки уровня Unreal.
Это все про рендер, то есть про самую требовательную для ресурсов и для многих критичную часть. Резюмирую: все можно переделать под себя или даже заменить полностью.
Что касается остального, то если допустим вам не нужна 2д физика, выключаете компонент, и ресурсы попросту не тратятся. Конечно, библиотеки все равно будут занимать в памяти драгоценные мегабайты, но это та цена, которая осознанно платится за удобство кроссплатформенности.
Что касается скриптов, системы объектов и всего прочего, то в самописном движке вы придете к тому же самому. Не знаю как тесно вплетено все в код Unreal и как трудно от этого отойти, но в Юнити можно реализовать кучу разных подходов, систем сообщений, достаточно легко пишутся расширения редактора чтоб сделать удобные тулзы. И даже ярый велосипедист окажется рад перекатиться в эту среду разработки, если приложит минимальное усилие на начальном этапе.
В целом в статье всё до банального очевидно. Если планируется совсем лютый эксперимент или мобилка — лучше не пользоваться тяжёлым движком.
Но абзац про динамические библиотеки в Unity и Unreal поставил в тупик. Мало того что библиотеки там вообще не для игрового кода ну никак, а для расчетов каких-то жестких или для расширений конкретного движка. Так еще и рассматривается вероятность в серьезном проекте поменять движок в середине разработки. Это как бы ошибка планирования и так делать не надо. Либо это долгострой, в котором на определенном этапе лучше что-то написать заново.
Автор в конце статьи так умильно показывает пример, мол, вот видите, вот и рассылочка )
Как правило, люди, много читающие, жанровые книги предпочитают экспериментальным. Кто если не эти люди будут покупать инди-книги. Они отнюдь не "идиоты", а скорее, наоборот, начитанные интеллигенты, которым в какой-то момент стало мало того, что продается в магазинах, в том или ином смысле.
Ради собственного удовольствия можно писать максимум рассказики в интернете. Но даже с ними приходится проводить серьезную скучную работу, если дело доходит до самого мелкого конкурса (не ради победы так ради того чтобы попасться на глаза новым читателям и желательно не отхватить тухлых помидоров). А уж когда нужно довести до конца роман, не такая уж и большая разница — жанровый он или экспериментальный. Работы непочатый край. С книгой мечты, наверное, даже больше мучений. Особенно если учесть, что скорее всего, это пишется в стол.