Но эти 100 мелких светящихся засранцев наваливались на батарейки так, что потребление было около 1А. Сколько работал первый набор батареек я не засёк, перешёл на аккумуляторы, но и их выносило за 2-3 часа.
Я с такими гирляндами поступил проще: припаял 3мм гнездо под трубчатый штекер параллельно крайним контактам батареек и подключал к старому нокиевскому ЗУ (туда на конец провода соответствующий штекер припаял, благо я давно штекеров и гнёзд таких пару десятков для самоделок покупал).
Т.е. можно отключать от ЗУ и снова вставлять батарейки.
С другой такой гирляндой сделал ещё проще: припаял таким же образом гнездо microUSB и подключаю старое ЗУ на 700мА через стандартный шнур.
P.S. Напротив гнёзд, естественно, в корпусе сделаны отвертстия под соответствующие штекеры. Ну и сами гнёзда зафиксированы термоклеем.
Что то ну очень замудреный алгоритм. Чем плох алгоритм со временем жизни ячеек?
Hidden text
Максимальное значение - это длина, а его координаты - голова змейки. Каждую итерацию проходимся по всем ячейкам и уменьшаем их значение на единицу. Затем в зависимости от направления движения змейки, в следующую ячейку записываем значение равное длине змейки.
По сути получается нужны только массив данных, длина змейки и текущие координаты головы.
Может кому пригодиться. Мой список «требований» к дизайнерам при создании svg-иллюстраций:
иллюстрации должны быть подогнаны по пиксельной сетке
не должно быть дробных значений в размерах, по максимуму избегать их
по минимуму использовать кисть, только кривые Безье или простые геометрические фигуры, чем меньше узловых точек, тем лучше
пересекающиеся фигуры с одинаковыми стилями должны быть по возможности объединены, т.е. чем меньше сущностей — тем лучше (хотя это по идее умеет делать svgo)
одинаковые фигуры не должны копироваться. Вместо этого создать образец (в палитре образцы) и копировать уже его (тогда в коде вместо повторений фигур будет использоваться тег <use xlink:href> который будет ссылаться на данную фигуру, что экономит итоговый размер svg)
размер монтажной области в конце подогнать по границам иллюстрации
убрать все лишние вспомогательные слои (растровые подложки и т.д.)
Есть специальные движки для текстовых игр. Для тех, кто хотя бы немного знает веб-разработку, есть Undum, Raconteur и Salet. Для тех, кто не хочет заморачиваться — Twine и русская AXMA Story Maker.
Если сесть и разобраться, то Twine рулит. Особенно как консольный компилятор, потому что визуальный редактор будет тормозить на масштабных разработках (консольная и визуальная версии очень плохо совместимы). Вы можете выбрать любой из кучи форматов (на вики перечислены только три, на самом деле форматов больше) и быстро набросать всё что захочется. Но документация сильно размыта, а вики в основном рассказывает про Twine 1. Правда, недавно вышел учебник-справочник.
.
Это не так и формат зависит от того, что было выбрано.
а вот оставлять Automatic Truecolor не рекомендуется, потому что (как показал опыт) он может восприняться системой как RGBA32.
Опыт показал наплевательское отношение к подготовке контента — юнити переводит текстуру в RGBA16 / RGBA32 только при наличии альфа-канала и никогда при его отсутствии. Т.е. нужно бить по рукам тем, кто готовит контент и пропускает такой треш в проект. Так же — всегда оставлять для текстур без альфы автокомпрессию — на android они автоматически сожмутся в ETC1, что просто несоизмеримо по размерам с RGB24 с минимальным ухудшением качества. На ios это будет PVRTC4.
Снизить качество изображений в настройках импорта по схеме: 32 bit -> 24 bit -> 16 bit, наблюдая за тем, чтобы уровень качества изображения оставался в пределах допустимого.
Никогда так не делать. Для непрозрачных текстур всегда автокомпрессия, для прозрачных — выбирать RGBA16 или RGBA32, в зависимости от наличия градиентов. Ну и отключать мипмапы для текстур гуя.
Ограничить maxTextureSize для изображений, для которых это возможно с сохранением приемлемого качества.
Опять же — наплевательское отношение к контенту. Пережимание текстур в юнити убивает их качество, правильнее делать даунскейл до нужного размера в том же фотошопе с правильным фильтром. Для gles2 максимальный размер текстур — 2048х2048, как бы ни хотелось делать больше — нельзя.
Тщательно вручную удалять неиспользуемые ассеты в папках Resources
Принять за правило: папка Resources — должна быть пуста в принципе. Это не хранилище контента для всего проекта. Если нужно что-то инстанцировать по имени и не обойтись явным указанием префаба — только тогда туда складывать нужный ассет.
Для изображений JPG: сменить расширение файла на bytes и он превратится в TextAsset. После чего воспользоваться функцией Texture2D.LoadImage() для загрузки картинки.
Никогда так не делать — LoadImage грузит текстуру исключительно в RGB24 / RGA32 ориентируясь на наличие альфа-канала в ней с соответствующим потреблением памяти. Texture2D.Compress не работает на мобильных платформах — выпилен юнитеками сознательно.
По возможности использовать MP3, а не WAV.
Стараться не играть больше 4 звуков одновременно и не более 1 длинного звука, например, фоновой мелодии. Все держать в wav — это позволит выбирать метод компрессии и битрейт прямо в юнити + позволит убрать обрезание последней полсекунды музыки в mp3 — есть такая особенность в юнити, хорошо видна на зацикленных мелодиях. Так же на ios можно будет поставить галочку аппаратной декомпрессии 1 аудиопотока. Все короткие звуки (sfx-ы взрывов, выстрелов и т.п.) держать прямо в wav — декомпрессия хорошо жрет процессор и вызывает просадки фпс на бюджетных устройствах. Ну и разумеется — все только моно, 22кгц — sfx, 32кгц — музыка, битрейт для всего достаточен в 96кбит. Для голоса параметры нужно подбирать отдельно.
Потому, получается, что официальная документация Unity в этом месте не совсем релевантна.
Потому что System будет использована в любом случае, различается только в каком виде и будет ли отрезан неиспользуемый остаток (microkernel, strip code). С приходом il2cpp это будет неактуально.
А вот использования других (необязательных) dll желательно избегать во имя снижения размера сборки.
Размер dll-ек обычно копеечный по сравнению с текстурами и аудио-данными. Конкретно что сколько занимает можно посмотреть в Editor log после билда — там будет все расписано.
Просьба рассматривать данный материал как более-менее систематизированные результаты исследования, а не как универсальное руководство к действию.
Можно приписать в заголовок «вредные советы» — тогда это можно использовать по назначению.
Незаслуженно обойдены вниманием генераторы Hexo и Assemble, оба на NodeJS. У обоих очень широкие возможности. Например, встроенной поддержкой интернационализации i18n может похвастать далеко не каждый генератор.
На базе NodeJS есть несколько генераторов попроще, но тоже достаточно популярных: Metalsmith, Harp, Wintersmith.
Мне особо импонирует генератор Techy, реализованный целиком посредством task-runner'а Gulp. Сам его еще не пробовал, но есть подозрение, что, имея минималистичный функционал, он может оказаться самым гибким по настройке и наиболее расширяемым, благодаря огромной базе плагинов Gulp.
Я не знаю что делают вышеуказанные, из описаний выходит вот что они делают (пишу так, чтоб можно было в bash функцию положить):
git branch -a
— получить список всех бранчей.
BRANCH=${1:?«Supply branch name»} && git stash && git checkout $BRANCH && git stash pop
— переключиться на ветку
git checkout -b newbranch
— переключиться на новый бранч с содержимым текущего
git checkout into-branch && git merge branch && git branch -d branch
— слить первый бранч во второй и удалить первый. Можно сливать только локальный бранч.
git stash && CUR=$(git rev-parse HEAD) && git checkout branchname && git push origin branchname && git checkout $CUR && git stash pop
— Добавить удалённый бранч из соответствующего локального.
git push origin :branch
— Убрать удалённый бранч.
Я не совсем понимаю что делает sync, но явно что-то не сложнее
git stash && CUR=$(git rev-parse HEAD) && git checkout master && git pull && git checkout $CUR && git rebase master && git stash pop
Т.е. можно отключать от ЗУ и снова вставлять батарейки.
С другой такой гирляндой сделал ещё проще: припаял таким же образом гнездо microUSB и подключаю старое ЗУ на 700мА через стандартный шнур.
P.S. Напротив гнёзд, естественно, в корпусе сделаны отвертстия под соответствующие штекеры. Ну и сами гнёзда зафиксированы термоклеем.
Что то ну очень замудреный алгоритм. Чем плох алгоритм со временем жизни ячеек?
Hidden text
Максимальное значение - это длина, а его координаты - голова змейки.
Каждую итерацию проходимся по всем ячейкам и уменьшаем их значение на единицу. Затем в зависимости от направления движения змейки, в следующую ячейку записываем значение равное длине змейки.
По сути получается нужны только массив данных, длина змейки и текущие координаты головы.
Может кому пригодиться. Мой список «требований» к дизайнерам при создании svg-иллюстраций:
Если сесть и разобраться, то Twine рулит. Особенно как консольный компилятор, потому что визуальный редактор будет тормозить на масштабных разработках (консольная и визуальная версии очень плохо совместимы). Вы можете выбрать любой из кучи форматов (на вики перечислены только три, на самом деле форматов больше) и быстро набросать всё что захочется. Но документация сильно размыта, а вики в основном рассказывает про Twine 1. Правда, недавно вышел учебник-справочник.
.
Это не так и формат зависит от того, что было выбрано.
Опыт показал наплевательское отношение к подготовке контента — юнити переводит текстуру в RGBA16 / RGBA32 только при наличии альфа-канала и никогда при его отсутствии. Т.е. нужно бить по рукам тем, кто готовит контент и пропускает такой треш в проект. Так же — всегда оставлять для текстур без альфы автокомпрессию — на android они автоматически сожмутся в ETC1, что просто несоизмеримо по размерам с RGB24 с минимальным ухудшением качества. На ios это будет PVRTC4.
Никогда так не делать. Для непрозрачных текстур всегда автокомпрессия, для прозрачных — выбирать RGBA16 или RGBA32, в зависимости от наличия градиентов. Ну и отключать мипмапы для текстур гуя.
Опять же — наплевательское отношение к контенту. Пережимание текстур в юнити убивает их качество, правильнее делать даунскейл до нужного размера в том же фотошопе с правильным фильтром. Для gles2 максимальный размер текстур — 2048х2048, как бы ни хотелось делать больше — нельзя.
Принять за правило: папка Resources — должна быть пуста в принципе. Это не хранилище контента для всего проекта. Если нужно что-то инстанцировать по имени и не обойтись явным указанием префаба — только тогда туда складывать нужный ассет.
Никогда так не делать — LoadImage грузит текстуру исключительно в RGB24 / RGA32 ориентируясь на наличие альфа-канала в ней с соответствующим потреблением памяти. Texture2D.Compress не работает на мобильных платформах — выпилен юнитеками сознательно.
Стараться не играть больше 4 звуков одновременно и не более 1 длинного звука, например, фоновой мелодии. Все держать в wav — это позволит выбирать метод компрессии и битрейт прямо в юнити + позволит убрать обрезание последней полсекунды музыки в mp3 — есть такая особенность в юнити, хорошо видна на зацикленных мелодиях. Так же на ios можно будет поставить галочку аппаратной декомпрессии 1 аудиопотока. Все короткие звуки (sfx-ы взрывов, выстрелов и т.п.) держать прямо в wav — декомпрессия хорошо жрет процессор и вызывает просадки фпс на бюджетных устройствах. Ну и разумеется — все только моно, 22кгц — sfx, 32кгц — музыка, битрейт для всего достаточен в 96кбит. Для голоса параметры нужно подбирать отдельно.
Потому что System будет использована в любом случае, различается только в каком виде и будет ли отрезан неиспользуемый остаток (microkernel, strip code). С приходом il2cpp это будет неактуально.
Размер dll-ек обычно копеечный по сравнению с текстурами и аудио-данными. Конкретно что сколько занимает можно посмотреть в Editor log после билда — там будет все расписано.
Можно приписать в заголовок «вредные советы» — тогда это можно использовать по назначению.
На базе NodeJS есть несколько генераторов попроще, но тоже достаточно популярных: Metalsmith, Harp, Wintersmith.
Мне особо импонирует генератор Techy, реализованный целиком посредством task-runner'а Gulp. Сам его еще не пробовал, но есть подозрение, что, имея минималистичный функционал, он может оказаться самым гибким по настройке и наиболее расширяемым, благодаря огромной базе плагинов Gulp.
Dojo — dojotoolkit.org/reference-guide/dojo/declare.html#dojo-declare
Sencha (ExtJS) — www.rogerwilco.ru/2011/04/sencha-extjs.html
qooxdoo — qooxdoo.org/documentation/0.7/oo_feature_summary
MooTools — www.phpeveryday.com/articles/MooTools-Basic-Creating-Classes-MooTools-P919.html
Prototype — www.prototypejs.org/learn/class-inheritance
AtomJS — github.com/theshock/atomjs/blob/master/Docs/Class/Class.md
JSClass — jsclass.jcoglan.com/classes.html
code.google.com/p/jsclassextend/
github.com/jcoglan/js.class
Cobra — justin.harmonize.fm/index.php/2009/01/cobra-a-little-javascript-class-library/
github.com/JustinTulloss/cobra
The $class Library- www.uselesspickles.com/class_library/
Classy — classy.pocoo.org/
YUI 3 — www.yuiblog.com/blog/2010/01/06/inheritance-patterns-in-yui-3/
Coffee-Script — jashkenas.github.com/coffee-script/#classes
JavascriptClasses — code.google.com/p/javascript-classes/
AJS — amix.dk/blog/post/19038
jsFace — github.com/tannhu/jsface
JsOOP — jsoop.codeplex.com/
joot — code.google.com/p/joot/wiki/API
oopsjs — code.google.com/p/oopsjs/
Objs — github.com/tekool/objs/wiki
oorja — maxpert.github.com/oorja/
objx — code.google.com/p/objx/wiki/OClass
jsclassextend — code.google.com/p/jsclassextend/
prolificjs — code.google.com/p/prolificjs/wiki/OOP
objectize — code.google.com/p/objectize/
code.google.com/p/core-framework/wiki/Inheritance
code.google.com/p/sfjsoo/
code.google.com/p/jslproject/
code.google.com/p/magic-classes/wiki/MagicClassesOverview
github.com/ded/klass
github.com/jiem/my-class
github.com/kilhage/class.js
github.com/Jakobo/Sslac
github.com/BonsaiDen/neko.js
github.com/finscn/GT-Class
github.com/deadlyicon/klass.js
github.com/neuromantic/CodeJS
github.com/cj/js-oo
github.com/darthapo/klass.js
github.com/nemisj/zet.js
github.com/k33g/species
github.com/benekastah/JS-Class
github.com/tobeytailor/def.js
github.com/rstrobl/squeakyJS
github.com/shinyplasticbag/MojoClass
github.com/firejune/class
github.com/gcoguiec/jquery-class
github.com/daffl/JS.Class
github.com/pavelz/class.js
github.com/zerodogg/jqsimple-class
github.com/bnoguchi/class-js
github.com/arian/Klass
github.com/kuwabarahiroshi/joo
github.com/iamleppert/SimpleClass
github.com/aenoa/Noode.js
github.com/stomlinson/SuperClass
github.com/jzimmek/klazz
github.com/kbjr/class.js
github.com/jhnns/node.class
github.com/borysf/declare/blob/master/declare.js
github.com/ShadowCloud/BF-Class
github.com/pic-o/jsClass
github.com/rosamez/jquery.klass
github.com/yuki-kimoto/javascript-Class_Simple
github.com/yaksnrainbows/jarb
github.com/thirashima/UnderClass
github.com/arahaya/package.js
github.com/arieh/Class.def
github.com/bogdan-dumitru/jsClass
github.com/pomke/pomke.js
github.com/sgolasch/jClassify
github.com/kbjr/Classy
github.com/cthackers/jClass
github.com/davidjbeveridge/Clasico
github.com/edave64/protojazz
github.com/mrac/solid.js
github.com/benekastah/Classy
github.com/damianmr/JSMiniClass
github.com/benekastah/classesWithCash
github.com/dialog/Resig-Class
github.com/mpodriezov/OJS
github.com/dtinth/twcs.js
github.com/percyhanna/js-class
github.com/jalopez/SimpleClassJS
github.com/jhamlet/proteus
github.com/petebrowne/classify
github.com/TdroL/Classy.js
github.com/azendal/neon
github.com/aulizko/Alan-Point-JavaScript-Library/tree/master/src/oop
git branch -a
— получить список всех бранчей.
BRANCH=${1:?«Supply branch name»} && git stash && git checkout $BRANCH && git stash pop
— переключиться на ветку
git checkout -b newbranch
— переключиться на новый бранч с содержимым текущего
git checkout into-branch && git merge branch && git branch -d branch
— слить первый бранч во второй и удалить первый. Можно сливать только локальный бранч.
git stash && CUR=$(git rev-parse HEAD) && git checkout branchname && git push origin branchname && git checkout $CUR && git stash pop
— Добавить удалённый бранч из соответствующего локального.
git push origin :branch
— Убрать удалённый бранч.
Я не совсем понимаю что делает sync, но явно что-то не сложнее
git stash && CUR=$(git rev-parse HEAD) && git checkout master && git pull && git checkout $CUR && git rebase master && git stash pop