>1. Обращение к transform. Надо сделать локальную переменную, в которую сделается один запрос:
Всё верно. Тут всё достаточно понятно.
В своём коде я добавил поле public Transform tr; в базовый класс для всех объектов, и инициализирую его в Awake(). Сначала сделал его приватным, но потом оказалось, что лучше его сделать публичным. И теперь у всех объектов есть уже инициализированное поле tr с кэшированной ссылкой на компонент. Удобно.
>2. Обращение к forward. Надо сделать локальную переменную, в которую сделается один запрос:
А это верно до тех пор, пока не поменяем rotation. Тогда transform.forward будет показывать на новое направление, а старое закэшированное значение
>var forward = cachedTransform.forward;
будет всё ещё показывать на старое направление. Но само обращение к cachedTransform.forward будет верным.
не такая большая разница — динамичная игра или нет, важна частота кадров. Важно, будет ли хоть сколько-то значительный позитивный эффект от отказа от локальных переменных в пользу полей класса.
И это предложение делали не разработчики Юнити, а в некоторых статьях по Юнити на хабре, когда говорили про оптимизацию.
В Юнити используется Mono, и ещё не самая новая.
Здесь я спрашиваю в надежде, что знатоки C# смогут что-то подсказать.
В одной статье по игровому движку Unity видел совет по оптимизации, который заключается в том, что локальные переменные в часто вызываемых методах делать не локальными переменными, а полями класса.
В Юнити у игровых объектов есть метод Update(), который вызывается каждый кадр (до 60 раз в секунду). И объектов на сцене может быть сотни и тысячи, и у каждого из них каждый кадр вызывается Update(). С одной стороны, при каждом вызове метода на стеке создаются локальные переменные. Но ведь это делается очень быстро.
Предположим, что у нас 1000 объектов, и FPS 60 кадров в секунду, что приводит к 60000 вызовам метода в секунду. Если посчитать, что выделение памяти для локальных переменных занимает 1 такт 1 ГГц процессора, то только на эти выделения памяти для локальных переменных уйдёт до 60 микросекунд — что составляет 0,0006% производительности.
Как вы оцениваете эффективность такой оптимизации? Стоит ли заморачиваться?
Вопрос был не о том, сложно ли взломать 10-символьный пароль. А в том, зачем ограничивают максимальную длину пароля? Видел не один раз верхнюю границу — «ваш пароль слишком длинный, пароль должен быть от 8 до 16 символов». Зачем? Есть у кого какие мысли?
Некоторое время назад на хабре была статья habrahabr.ru/post/211645/, в которой обсуждали уязвимость bcrypt в плане его ограничения на длину хэшируемой строки. То есть, по крайней мере для некоторых алгоритмов, верхняя граница длины пароля существует. Но не 16-20 же символов?
Я бы тоже сам не рекомендовал. Мне была интересна именно юридическая оценка вышеприведённых мной слов. Я слышал такое мнение, которое привёл выше, и хотел уточнить у специалиста. Спасибо за ответ.
Хорошая и важная тема, и правда, мало рассмотренная. Спасибо за статью.
Насколько я знаю, в России юридические документы не являются интеллектуальной собственностью и объектом авторского права. То есть, как я понимаю, вполне дозволяется «позаимствовать» чужой набор документов и исправить в них названия на свои. Хотя лучше, конечно, значительно переработать документы под свои нужды, используя чужие как макет.
Являются ли юридические документы интеллектуальной собственностью в других странах?
>Понравилась ли Вам подборка?
Сделайте больше градаций ответа, чем просто Да/Нет.
Я не могу сказать, что не понравилась, но именно полезного для меня, что мне захотелось бы открыть почитать подробнее, сегодня не было (кроме гремлинов :) но их я уже видел ранее). Поэтому я бы поставил оценку 4/5 — материалы хорошие, все по теме, просто мне не подходят.
Если вам важно получать отзывы от читателей, то, возможно, вам больше подойдёт более длинная градация ответов.
но там не написано, что трос диаметром с размах рук будет цельным, а очень даже наоборот, указаны картинки такого троса — несколько нанотрубок, вложенных друг в друга. Диаметр трубки — метр, толщина стенки трубки — нано (толщина в один атом).
На самом деле, Angular — это браузерный javascript, для его работы не нужен веб-сервер. Только вот браузеры ограничивают загрузку файлов шаблонов с диска по своей политике безопасности — при запуске страницы непосредственно с диска не работает ajax. Поэтому и нужен веб-сервер.
Ну и в моей реализации бэкенд (папка back) сделан на php, поэтому нужно использовать веб-сервер, поддерживающий php. Но его можно очень легко переделать на Node.js (вот, например, из последних статей на хабре по теме — habrahabr.ru/post/213931/). Либо вместо php-бэкенда отдавать готовый json с данными, но тогда добавление/изменение записей не будет работать.
Перевод официальной документации можно найти на angular.ru, кое-что ещё можно найти вот тут: stepansuvorov.com/blog/2012/12/%D1%81-%D1%87%D0%B5%D0%B3%D0%BE-%D0%BD%D0%B0%D1%87%D0%B0%D1%82%D1%8C-%D0%B8%D0%B7%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-angularjs/
Да, сейчас мой сайт, на котором была демка, отключен. Попробую выложить на Github Pages. Кину сюда ссылку, как сделаю.
Вообще, нужно взять содержимое папки app/ репозитория и положить его в корень сайта (или в подпапку), для этого нужно иметь запущенный веб-сервер. Например, если установлен Денвер, то нужно содержимое папки app положить в z:\home\ng-admin\www\ и запускать его в браузере по адресу ng-admin/ (после рестарта денвера, конечно же).
> Проблема решается отделением модели от коллайдера в иерархии
То есть навесить коллайдер не на модельку птички, а на её родительский (пустой?) объект, который не будет вращаться, но будет перемещаться, так?
Но тогда вращение нужно делать на внутренний объект с моделью, а перемещение — на внешний с коллайдером и внутренним. Или я что-то не понял?
Покажите, пожалуйста, скриншот окна иерархии, чтобы было понятнее.
Я попробую ответить вам (сам я минусы не ставил).
Я считаю, что верстка — это совершенно отдельная профессия, весьма далёкая от программирования.
Вот я программист, и для меня вёрстка (чем иногда приходится заниматься) даётся сложно, гугл стонет от запросов в некоторых случаях. Для меня использование бутстрапа может стать чем-то вроде отдушины, ибо он (по крайней мере, для меня) приближает вёрстку к более формальному процессу из-за наличия компонентов.
Я пока использовал бутстрап только в админках и прототипах своих проектиков (чтобы было хоть что-то). Благодаря этой статье, я разобрался, как его применить для чего-то более серьёзного, за что автору большое спасибо.
Из комментов выше я понял, что профи вёрстки не используют бутстрап вообще, либо умеют его отлично готовить к месту, благодаря своему опыту. Я опыта не имею (и не так уж хочу получать, ибо не моё), и бутстрап для меня хороший инструмент, в некоторых применениях.
Ваш скепсис тоже очень понятен, и минусуют вас не за ваш опыт (который только в третьем комменте и видно), а за категоричность. Хабр не любит категоричность, и всегда за него наказывает. Что, в принципе, и правильно.
Такой информации у меня нет. Но, судя по всему, ограничений на тип трафика нет. Если будут приходить жалобы — будут разбираться (как обычно в Европе разбираются :)
Всё верно. Тут всё достаточно понятно.
В своём коде я добавил поле public Transform tr; в базовый класс для всех объектов, и инициализирую его в Awake(). Сначала сделал его приватным, но потом оказалось, что лучше его сделать публичным. И теперь у всех объектов есть уже инициализированное поле tr с кэшированной ссылкой на компонент. Удобно.
>2. Обращение к forward. Надо сделать локальную переменную, в которую сделается один запрос:
А это верно до тех пор, пока не поменяем rotation. Тогда transform.forward будет показывать на новое направление, а старое закэшированное значение
>var forward = cachedTransform.forward;
будет всё ещё показывать на старое направление. Но само обращение к cachedTransform.forward будет верным.
И это предложение делали не разработчики Юнити, а в некоторых статьях по Юнити на хабре, когда говорили про оптимизацию.
В Юнити используется Mono, и ещё не самая новая.
Здесь я спрашиваю в надежде, что знатоки C# смогут что-то подсказать.
Можно в VS померить, конечно же…
В Юнити у игровых объектов есть метод Update(), который вызывается каждый кадр (до 60 раз в секунду). И объектов на сцене может быть сотни и тысячи, и у каждого из них каждый кадр вызывается Update(). С одной стороны, при каждом вызове метода на стеке создаются локальные переменные. Но ведь это делается очень быстро.
Предположим, что у нас 1000 объектов, и FPS 60 кадров в секунду, что приводит к 60000 вызовам метода в секунду. Если посчитать, что выделение памяти для локальных переменных занимает 1 такт 1 ГГц процессора, то только на эти выделения памяти для локальных переменных уйдёт до 60 микросекунд — что составляет 0,0006% производительности.
Как вы оцениваете эффективность такой оптимизации? Стоит ли заморачиваться?
Некоторое время назад на хабре была статья habrahabr.ru/post/211645/, в которой обсуждали уязвимость bcrypt в плане его ограничения на длину хэшируемой строки. То есть, по крайней мере для некоторых алгоритмов, верхняя граница длины пароля существует. Но не 16-20 же символов?
Насколько я знаю, в России юридические документы не являются интеллектуальной собственностью и объектом авторского права. То есть, как я понимаю, вполне дозволяется «позаимствовать» чужой набор документов и исправить в них названия на свои. Хотя лучше, конечно, значительно переработать документы под свои нужды, используя чужие как макет.
Являются ли юридические документы интеллектуальной собственностью в других странах?
Сделайте больше градаций ответа, чем просто Да/Нет.
Я не могу сказать, что не понравилась, но именно полезного для меня, что мне захотелось бы открыть почитать подробнее, сегодня не было (кроме гремлинов :) но их я уже видел ранее). Поэтому я бы поставил оценку 4/5 — материалы хорошие, все по теме, просто мне не подходят.
Если вам важно получать отзывы от читателей, то, возможно, вам больше подойдёт более длинная градация ответов.
А Node.js будет? тоже ведь популярная технология.
Ну и в моей реализации бэкенд (папка back) сделан на php, поэтому нужно использовать веб-сервер, поддерживающий php. Но его можно очень легко переделать на Node.js (вот, например, из последних статей на хабре по теме — habrahabr.ru/post/213931/). Либо вместо php-бэкенда отдавать готовый json с данными, но тогда добавление/изменение записей не будет работать.
Перевод официальной документации можно найти на angular.ru, кое-что ещё можно найти вот тут: stepansuvorov.com/blog/2012/12/%D1%81-%D1%87%D0%B5%D0%B3%D0%BE-%D0%BD%D0%B0%D1%87%D0%B0%D1%82%D1%8C-%D0%B8%D0%B7%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-angularjs/
Вообще, нужно взять содержимое папки app/ репозитория и положить его в корень сайта (или в подпапку), для этого нужно иметь запущенный веб-сервер. Например, если установлен Денвер, то нужно содержимое папки app положить в z:\home\ng-admin\www\ и запускать его в браузере по адресу ng-admin/ (после рестарта денвера, конечно же).
То есть навесить коллайдер не на модельку птички, а на её родительский (пустой?) объект, который не будет вращаться, но будет перемещаться, так?
Но тогда вращение нужно делать на внутренний объект с моделью, а перемещение — на внешний с коллайдером и внутренним. Или я что-то не понял?
Покажите, пожалуйста, скриншот окна иерархии, чтобы было понятнее.
И продолжение об оптимизации — habrahabr.ru/post/182690/
Я считаю, что верстка — это совершенно отдельная профессия, весьма далёкая от программирования.
Вот я программист, и для меня вёрстка (чем иногда приходится заниматься) даётся сложно, гугл стонет от запросов в некоторых случаях. Для меня использование бутстрапа может стать чем-то вроде отдушины, ибо он (по крайней мере, для меня) приближает вёрстку к более формальному процессу из-за наличия компонентов.
Я пока использовал бутстрап только в админках и прототипах своих проектиков (чтобы было хоть что-то). Благодаря этой статье, я разобрался, как его применить для чего-то более серьёзного, за что автору большое спасибо.
Из комментов выше я понял, что профи вёрстки не используют бутстрап вообще, либо умеют его отлично готовить к месту, благодаря своему опыту. Я опыта не имею (и не так уж хочу получать, ибо не моё), и бутстрап для меня хороший инструмент, в некоторых применениях.
Ваш скепсис тоже очень понятен, и минусуют вас не за ваш опыт (который только в третьем комменте и видно), а за категоричность. Хабр не любит категоричность, и всегда за него наказывает. Что, в принципе, и правильно.