Струйники и максимальная экономия у меня ассоциируются лишь с одним — СНПЧ, чтобы вообще не париться с картриджами. Колхозить не всегда приемлемо, да и не на всякий принтер станет. К счастью конкуренты в лице Epson уже давно выпустили доступную по цене L серию принтеров с заводским СНПЧ и эти принтеры определенно завоевали популярность в людей, даже сам пользуюсь и знакомым рекомендую. Canon позже запилили G серию в ответ, можете про их детальней написать статью?
Спасибо, ваша точка зрения ясна. Но прошу, зрите в корень. В данном случае десятипальцевый является неотъемлемой частью философии вима, иначе человек не сможет использовать этот инструмент эффективно. Поэтому утверждение логично, надеюсь рано или поздно вы сможете осознать это. Ваш «контрпример» лишь ещё раз подчеркивает тот факт, что вы не используете главное преимущество этого редактора, микроскопом тоже можно гвозди забивать, если кому-то это нравится, пожалуйста. Видимо аналогия с «аккордами» вам не полностью понятна, также как и плюсы десятипальцевого, дальнейшее обсуждение просто бессмысленно и действительно скатывается у «флейм» вместо конструктивного разговора по теме.
Правильно, об этом же и речь. Логичный вывод напрашивается сам по себе: если человеку не нужен десятипальцевый метод набора, то ему не нужен и vim. При этом он может быть кем сам пожелает и пользоваться любыми редакторами которыми захочет, но vim ему не подойдёт, это будет просто мучение. Потому что не сможет задействовать самое главное преимущество — редактирование вслепую не отрывая рук, при помощи моторики, своего рода «играя аккорды».
Что за оправдания? :) Вполне нормально использовать ассеты, для этого они и созданы. А на счет скриншотов не соглашусь, ладно там один «профессиональный» например для КПДВ скопипастить, но остальные? Получается красивая замануха, которая не ваша. Гораздо же интересней именно собственный результат показать сообществу, чтобы получить ценные отзывы, замечания, предложения. Дело тут совсем не в HUD, а в том чтобы побольше наполнить статью информацией о том что пишете, в данном случае о вашем проекте.
Контент от Manufactura K4, конкретно вот этот ассет: Pirates Island. К сожалению скриншоты в статье — копипаста, можно было хоть свои сделать. Имхо пока что выглядит не очень круто, мало просто взять готовые ассеты. Пожелаю удачи, потому что ох как не легко плавать в этом бурном но зато свободном indie game dev море :)
Всё перечисленное безусловно полезно, но не в этом заключается соль вима. В первую очередь vim — это слепой десятипальцевый метод редактирования текста. Чтобы не повторяться, вот ссылка на мой развёрнутый коммент ниже.
Много разных объяснений, но что-то никто не обратил внимание на такую мысль: vim — это слепой десятипальцевый метод редактирования текста. Именно это и делает его отличным востребованным инструментом, чтобы эффективно редачить что-либо не отрывая рук от базового положения на клавиатуре. Также можно сравнить с игрой на музыкальном инструменте, примерно те же ощущения будут: когда уже выработана определённая моторика, то человек не думает о том как именно он играет на этом инструменте. Ещё важно понимать такую философию: все профи вимеры используют режим вставки текста только для того чтобы набирать/добавлять новый текст, а не редактировать существующий (исключение — разве что Backspace прямо в текущем слове).
Подытожим, имхо эти пункты важны:
• предпосылка для пользования вимом — необходимо владеть слепым десятипальцевым методом набора;
• понимание в чём собственно преимущество — редактирование вслепую не отрывая рук, при помощи моторики, своего рода «играя аккорды» (а не разные плюшки, плагины, или прочие вещи которые обычно приводятся как аргументы);
• использовать режим вставки текста только по назначению, иначе теряется весь смысл и это лишь приносит боль и страдание.
• таки да, не каждый может стать музыкантом, а некоторым это и не нравится, о вкусах не спорят.
Напоследок хорошее видео про vim от Кирилла из Hexlet
GitLab имеет одно очень вкусное преимущество в сравнению с другими конкурентами — 10 Gb лимит на один репозиторий, Bitbucket замораживает репозиторий после превышения 1 GB (так званый Soft limit), у GitHub — тоже ограничение 1 Gb. Это далеко не всем полезно, потому что код мало весит, но иногда бывает очень кстати для больших проектов с разными жирными файлами. Вот ещё кстати хороший ресурс по сравнению хостингов для кода: Compare Git Hosting.
Поддерживаю, тоже есть желание попробовать такое спустя много лет :) Много было разных Symbian смартов, но больше всего запомнился — 6630, превосходный девайс с одной из самых удобных клавиатур своего времени:
Перечитывал этот абзац много раз, что-то трудно воспринимается:
Это значит, что мы не можем применить необратимые последствия, например, убийство игроков. Такие необратимые последствия можно применять только когда они поступают из GameStateHistory, т.е. когда их больше нельзя перезаписывать.
This means we cannot apply irreversible outcomes, i.e, killing a players, such irreversible outcomes will only be applied when it goes out of the GameStateHistory, ie. when it cannot be rewriten anymore.
Кто в теме, объясните пожалуйста подробней, а то чувствую от меня ускользает полное понимание этой идеи.
Логично выглядит так, что если в серверном буфере GameStateHistory например в GameState N записано что определённого игрока уже замочили, а затем происходит согласование на сервере (появились данные в UnprocessedUserInput которые старше текущего кадра) и будут обновлены GameState N+1, N+2,… — то этот игрок уже никак не может «ожить», это необратимое последствие, перезаписывать в этой ситуации нельзя.
А если наоборот, например в GameState N записано что определённый игрок жив, но затем после согласования (появились данные в UnprocessedUserInput которые старше текущего кадра, скажем от клиента с медленным соединением) оказывается что в следующем GameState N+1 его замочили, то перезаписывается, нельзя же ему оставаться бессмертным :) Это будет выглядеть «как смерть из-за угла», у Valve доках это следствие применения Lag Compensation: For instance, if a highly lagged player shoots at a less lagged player and scores a hit, it can appear to the less lagged player that the lagged player has somehow «shot around a corner».
Правильно ли, что описанная тут методика согласования, является попыткой обобщить Lag Compensation, который специфичен именно для шутеров?
uBlock Origin — это продолжение проекта его основателем Raymond Hill, который вынуждено форкнул и переименовал его из-за проблем с одним не очень хорошим ментейнером Chris AlJoudi, который потянул на себя одеяло и даже косит пожертвования «на развитие проекта». Хоть до сих пор и существуют две версии, но лишь Origin развивается. Если интересно, вот можно почитать подробней: Tuxdiary и Reddit.
Тернистый путь… Что же тут поделаешь, это вынужденная необходимость.
Рекомендую присмотреться к Xposed — превосходный инструмент для тонкой настройки ведроида на низком уровне :) Официальный сайт & исходники. Позволяет на лету патчить в памяти приложения, без изменений apk файлов. Для этого используются модули, на данный момент уже создано множество полезных на любой вкус и цвет. Чем то напоминает старенький RomPatcher+ под Symbian, кто помнит такое — тот поймёт :)
Как ни крути, но рано или поздно возникает вопрос написания собственных шейдеров. Для Unity самый продвинутый инструмент-помощник в этом нелёгком деле — Shader Forge. Темы на форуме юньки: старая & новая.
В качестве хорошего примера могу порекомендовать Ghost of a Tale — действительно достойный проект на Unity, как по геймплею, так и по графике. Вот блог разработчиков, там есть много интересной инфы, в том числе и про использование Shader Forge.
Ох уж эта живучая легаси формула… Прочитал вашу статью и сразу о ней вспомнил :)
Там очень много толковой информации, возможно будет полезно при апгрейде вашей палитры.
Также замечено в комментах: раз и два. Но перевода именно этой статьи раньше не было.
Подытожим, имхо эти пункты важны:
• предпосылка для пользования вимом — необходимо владеть слепым десятипальцевым методом набора;
• понимание в чём собственно преимущество — редактирование вслепую не отрывая рук, при помощи моторики, своего рода «играя аккорды» (а не разные плюшки, плагины, или прочие вещи которые обычно приводятся как аргументы);
• использовать режим вставки текста только по назначению, иначе теряется весь смысл и это лишь приносит боль и страдание.
• таки да, не каждый может стать музыкантом, а некоторым это и не нравится, о вкусах не спорят.
Логично выглядит так, что если в серверном буфере GameStateHistory например в GameState N записано что определённого игрока уже замочили, а затем происходит согласование на сервере (появились данные в UnprocessedUserInput которые старше текущего кадра) и будут обновлены GameState N+1, N+2,… — то этот игрок уже никак не может «ожить», это необратимое последствие, перезаписывать в этой ситуации нельзя.
А если наоборот, например в GameState N записано что определённый игрок жив, но затем после согласования (появились данные в UnprocessedUserInput которые старше текущего кадра, скажем от клиента с медленным соединением) оказывается что в следующем GameState N+1 его замочили, то перезаписывается, нельзя же ему оставаться бессмертным :) Это будет выглядеть «как смерть из-за угла», у Valve доках это следствие применения Lag Compensation: For instance, if a highly lagged player shoots at a less lagged player and scores a hit, it can appear to the less lagged player that the lagged player has somehow «shot around a corner».
Правильно ли, что описанная тут методика согласования, является попыткой обобщить Lag Compensation, который специфичен именно для шутеров?
I Wrote The Fastest Hashtable (оригинал англ.)
Рекомендую присмотреться к Xposed — превосходный инструмент для тонкой настройки ведроида на низком уровне :) Официальный сайт & исходники. Позволяет на лету патчить в памяти приложения, без изменений apk файлов. Для этого используются модули, на данный момент уже создано множество полезных на любой вкус и цвет. Чем то напоминает старенький RomPatcher+ под Symbian, кто помнит такое — тот поймёт :)
В качестве хорошего примера могу порекомендовать Ghost of a Tale — действительно достойный проект на Unity, как по геймплею, так и по графике. Вот блог разработчиков, там есть много интересной инфы, в том числе и про использование Shader Forge.
Там очень много толковой информации, возможно будет полезно при апгрейде вашей палитры.