Думается все же звезды должны быть. Динамический диапазон теоретически не при чем, скорей всего автор схалявил, Сатурн удален от солнца почти на 10 а.е., в то время как земля на 1 а.е., таким образом освещенность поверхности Сатурна должна быть в 100 раз меньше чем освещенность поверхности земли или луны, навскидку разница 6.5 стопов выходит, плюс нет атмосферы которая дает засветку.
Там два мотора, вал одного проходит через вал другого, есть готовые комплекты в продаже: раз два
и таких море, типичная соосная схема, управление коптером за счет рулевых поверхностей внизу аппарата
Еще интересней зачем вам наушники с металлическим оголовьем. Если аккуратно использовать вещи то они не ломаются, ни металлические ни пластиковые.
Тем кто будет говорить «ну вот, автор купил три экземпляра довольно средненьких наушников и делает вид, что все понял» и будут опираться на качество звучания дорогих наушников стоит пройти слепой тест и понять что они слили лишние 20к и больше в карман производителю.
Хорошие такие рекомендации наушников за 15-35кило рублей, одни послушать дома, другие на работу, и еще затычки тысячи за три итого 50к.
Перед выбором наушников с учетом качества звучания надо посмотреть несколько видео из канала stalker29218
обязательно именно несколько, чтоб проникнуться всей глубиной маразма аудиофилии. Например Божественный Звук, Отец Аудиофилов, Аудиофильская скрипка. На мой взгляд единственная адекватная причина покупки дорогих наушников — необходимость покупки беспроводных наушников. И то в таком случае 10к это будет верхний предел.
Наверное ошибаюсь, плис для меня черный ящик. Плюс от контроллера будет скорее в удобстве кода, и цены теоретически очень демократичные, я правда сужу по устройстве и ценам хоббийных OSD плат, камер, LCD дисплеев с контроллерами. При использовании МК видеоконтроллер нам дает бонус в виде возможности обновления картинки в любой удобный для нас момент времени не задумываясь о сложных синхронизациях и т.д., Грубо говоря у нас дисплей 50 кадров в секунду чересстрочной развертки. Нам не надо задумываться о выводе одной половины строк, другой половины строк, синхронизации всего этого дела, мы просто в любой удобный момент для нас посылаем в контроллер например для текстового режима матрицу 80х25 или даже ее изменившуюся часть а контроллер уже сам занимается растеризацией этого счастья и вывода на экран, ну и собственно генерацией одной и той же картинки пока не получит новых данных. Тут пожалуй ключевым будет «любой удобный для нас момент» т.е. не важно сколько у нас вычисление занимает времени, пол кадра, кадр, 10 секунд.
Почитал внимательней. Предполагал что вывод графики осуществляется через какой-то встроенный в макетную плату видео контроллер а оказывается видеосигнал генерируется ПЛИСом. Преклоняюсь перед таким хардкором. Тогда да, в таком случае не стоит заморачиваться, в любом случае для какой-то более практической задачи будет проще добавить специализированную микросхему для вывода графики а не мучить ПЛИС.
Не знаю как реализуется в ПЛИС, но хорошей практикой является является использование так называемого видеобуфера. Т.е. Имеется два буфера, назовем А и Б. На экран постоянно, непрерывно и аппаратно производится вывод того что хранится в буфере А. Мы в свою очередь во время хода игрока, каких либо вычислениях выводим данные в буфер Б. После завершения всех вычислений, когда все готово для обновления картинки буферы А и Б переключаются местами и на экран выводится буфер Б.
Есть различные реализации, например с тремя буферами или самая простая когда по завершении вычисления буферы не переключаются, а в буфер А копируется буфер Б с обновленными данными. В любом случае суть в том чтобы не выводить на экран какие-то промежуточные результаты а обновлять картинку только после того как она полностью готова.
Абсолютно ничего не понимаю в ПЛИС, но давным давно реализовывал это на паскале, позже пригодилось для реализации волнового алгоритма при поиске путей. Делал цикл, условие выхода — достигнуто максимальное число повторений либо переменная нулю. Перед входом в цикл переменной присваиваем единицу. В цикле соответственно первым делом обнуляем переменную. Дальше пробегаемся в этом же цикле по всем точкам хранящимся в массиве и проверяем граничащие с ними точки, если есть хоть одна равная нулю то добавляем ее во второй массив, отмечаем на карте как открытую и переменную для выхода из цикла делаем равную единице. После завершения проверки точек первый массив переписываем вторым и цикл повторяется.
В итоге когда вокруг не будет ни одной нулевой точки цикл завершится и останется еще раз по такому же принципу пробежаться чтобы открыть точки граничащие с нулевыми.
Они могут иметь профит ограничивая регистрацию ящиком mail.ru, но принадлежать mail.ru они не обязаны, наподобие установок яндексбара при установке какого-либо ПО. Хотя в целом закон кармы никто не отменял, вы наделали мультов обманув браузерные игрушки, браузерные игрушки обманули вас наслав вам спама, очередной раз убеждаюсь что в мире все взаимосвязано :)
Если я правильно понял описанное то мульты mail.ru использовались на определенных деньгокачалках которые этого требовали сами. Так как это были мульты то предполагаю что регистрировались они в деньгокачалках с маленьким промежутком времени, возможно даже в рамках одной сессии а следовательно вас вполне могли «по айпи вычислить» :) ну точнее деньгокачалка могла сохранять айпи адреса с которых проводилась регистрация аккаунтов с указанием email. Ну а больше никаких данных и не надо чтоб сопоставить с некоторой вероятностью родственность e-mailов.
Вопрос реализации СКУДа гораздо сложнее, особенно на крупном предприятии. Первое что приходит в голову:
-Обязательное наличие базы данных меток. Именно в этой базе должна проверяться метка при ее считывании
-Кэширование меток из БД на случай недоступности базы данных
-База должна хранить различные уровни доступа для меток так как СКУД это не турникет на входе здания. Для примера — ни к чему офисному планктону иметь возможность открыть карточкой кабинет гендиректора и ни к чему начальнику отдела кадром иметь доступ в серверную.
-Из предыдущего пункта вытекает возможность построения сети из меток т.е. должно быть центральное устройство с которым синхронизируются локальные считыватели соответственно необходима сеть для девайсов СКУД, например работа по локальной сети.
-Логирование.
-Автоматическая разблокировка в случае ЧП (пожар, землетрясение и т.д.)
-Работа от автономного источника питания (пропал свет, вырубили щиток)
-Контроль входа выхода (один человек не может войти два раза подряд не выйдя из помещения)
в целом таких пунктов наверное еще пачка наберется если почитать про СКУД и цена будет гораздо выше.
Виноват, ошибся датасторами, тестировал клиентов на медленном, единственное различие с быстрым — при копировании через vSphere скорость около 500 мегабит в секунду, через SCP скорость также 100 мегабит.
Мне кажется хранение vmdk в корне datastore не очень хорошая практика, можно схватить небольших граблей.
P.S. Ради интереса протестировал скорость копирования по гигабитной сети через SCP клиента и vSphere клиента:
через WinSCP — средняя скорость 100 мегабит в секунду, загрузка 12% ЦПУ
Через vSphere — средняя скорость 200 мегабит в секунду, загрузка 7% ЦПУ
копировании на виртуальную машину скорость 950 мегабит в секунду
И да, в бесплатной версии ESXi вроде было ограничение на закачку файлов на датастор в виде 5мб/с
В таком случае экономия будет только для ЦОДа, а тепло будет отдаваться в окружающую среду не совершая полезной работы, офисное помещение потребует дополнительных затрат на обогрев и суммарная затраченная энергия будет больше. Если же рассмотреть офис и ЦОД как одно целое тогда экономия будет на лицо — тепло не будет пропадать даром а будет обеспечивать обогрев здания убивая двух зайцев — меньше затрат на охлаждение цода, меньше затрат на обогрев офиса. Intel этим уже давно пользуется ru.intel.com/business/community/index.php?automodule=blog&blogid=7605&showentry=2485
кажется не упоминали, но если в лабиринте много ветвлений или мы стоим в центре карты то волновой алгоритм расходится во все стороны, количество ячеек в волне увеличивается и соответственно увеличивается время просчета поэтому в таких случаях лучше использовать оптимизацию и пускать две волны — одну из начала лабиринта, другую из конца, поиск пути заканчивается когда волны соприкасаются, в некоторых случаях такая оптимизация дает очень значительный прирост производительности.
Всегда использовал оперу, удобные вкладки, избранное, иконки, встроенный почтовый клиент, удобный менеджер закачек, все что было нужно, с выходом новой хромоподобной оперы был крайне разочарован, как сейчас помню как обновился и все… жизнь разделилась на «до» и «после», поставил FF, но получил местами непонятные баги с флешем, прям как насильно был притянут за уши к хрому. Пошел качать Vivaldi в надежде что вы скорее доведете его до состояния той родной и греющей душу оперы.
Еще можно взглянуть на игру с другого ракурса, как на покер например.
В покере две составляющих:
-математическая (просчет вероятности победы, поражения, все ясно думаю)
-человеческая (анализ реакции игроков, поведение, блеф и т.д.)
И если с математической составляющей все довольно просто и много раз описано то с человеческой точки зрения не все так однозначно.
Так как в морской бой играют между собой два человека и расположение противника заведомо неизвестно то никто не мешает жульничать :)
Например есть игрок А и игрок Б. Игрок А выстрелил и ранил корабль игрока Б. Игрок Б в свою очередь может сказать правду, сознаться в ранении корабля, либо проанализировав карту сказать что игрок А промахнулся и переместить корабль в другое свободное место. Возможен и другой вариант, игрок А ранил корабль игрока Б большой длины и начинает обстреливать клетки вокруг для определения направления корабля. Опять же игрок Б может анализировать свою карту и поворачивать корабль, конечно если это не нарушает правил игры.
При игре двух компьютерных игроков такая игра может продолжаться практически до заполнения всего поля :) при игре компьютера с человеком можно использовать например несколько уровней сложности, допустим компьютер не может двигать корабли, может двигать только один раз, два, три и т.д. Причем для человека тоже можно дать такую возможность мухлежа :) Мне кажется именно возможность мухлежа сделает игру более интересной и приближенной к человеческой игре нежели обычный обстрел по данным матстатистики.
раз
два
и таких море, типичная соосная схема, управление коптером за счет рулевых поверхностей внизу аппарата
Тем кто будет говорить «ну вот, автор купил три экземпляра довольно средненьких наушников и делает вид, что все понял» и будут опираться на качество звучания дорогих наушников стоит пройти слепой тест и понять что они слили лишние 20к и больше в карман производителю.
Перед выбором наушников с учетом качества звучания надо посмотреть несколько видео из канала stalker29218
обязательно именно несколько, чтоб проникнуться всей глубиной маразма аудиофилии. Например Божественный Звук, Отец Аудиофилов, Аудиофильская скрипка. На мой взгляд единственная адекватная причина покупки дорогих наушников — необходимость покупки беспроводных наушников. И то в таком случае 10к это будет верхний предел.
Есть различные реализации, например с тремя буферами или самая простая когда по завершении вычисления буферы не переключаются, а в буфер А копируется буфер Б с обновленными данными. В любом случае суть в том чтобы не выводить на экран какие-то промежуточные результаты а обновлять картинку только после того как она полностью готова.
В итоге когда вокруг не будет ни одной нулевой точки цикл завершится и останется еще раз по такому же принципу пробежаться чтобы открыть точки граничащие с нулевыми.
-Обязательное наличие базы данных меток. Именно в этой базе должна проверяться метка при ее считывании
-Кэширование меток из БД на случай недоступности базы данных
-База должна хранить различные уровни доступа для меток так как СКУД это не турникет на входе здания. Для примера — ни к чему офисному планктону иметь возможность открыть карточкой кабинет гендиректора и ни к чему начальнику отдела кадром иметь доступ в серверную.
-Из предыдущего пункта вытекает возможность построения сети из меток т.е. должно быть центральное устройство с которым синхронизируются локальные считыватели соответственно необходима сеть для девайсов СКУД, например работа по локальной сети.
-Логирование.
-Автоматическая разблокировка в случае ЧП (пожар, землетрясение и т.д.)
-Работа от автономного источника питания (пропал свет, вырубили щиток)
-Контроль входа выхода (один человек не может войти два раза подряд не выйдя из помещения)
в целом таких пунктов наверное еще пачка наберется если почитать про СКУД и цена будет гораздо выше.
P.S. Ради интереса протестировал скорость копирования по гигабитной сети через SCP клиента и vSphere клиента:
через WinSCP — средняя скорость 100 мегабит в секунду, загрузка 12% ЦПУ
Через vSphere — средняя скорость 200 мегабит в секунду, загрузка 7% ЦПУ
копировании на виртуальную машину скорость 950 мегабит в секунду
И да, в бесплатной версии ESXi вроде было ограничение на закачку файлов на датастор в виде 5мб/с
В покере две составляющих:
-математическая (просчет вероятности победы, поражения, все ясно думаю)
-человеческая (анализ реакции игроков, поведение, блеф и т.д.)
И если с математической составляющей все довольно просто и много раз описано то с человеческой точки зрения не все так однозначно.
Так как в морской бой играют между собой два человека и расположение противника заведомо неизвестно то никто не мешает жульничать :)
Например есть игрок А и игрок Б. Игрок А выстрелил и ранил корабль игрока Б. Игрок Б в свою очередь может сказать правду, сознаться в ранении корабля, либо проанализировав карту сказать что игрок А промахнулся и переместить корабль в другое свободное место. Возможен и другой вариант, игрок А ранил корабль игрока Б большой длины и начинает обстреливать клетки вокруг для определения направления корабля. Опять же игрок Б может анализировать свою карту и поворачивать корабль, конечно если это не нарушает правил игры.
При игре двух компьютерных игроков такая игра может продолжаться практически до заполнения всего поля :) при игре компьютера с человеком можно использовать например несколько уровней сложности, допустим компьютер не может двигать корабли, может двигать только один раз, два, три и т.д. Причем для человека тоже можно дать такую возможность мухлежа :) Мне кажется именно возможность мухлежа сделает игру более интересной и приближенной к человеческой игре нежели обычный обстрел по данным матстатистики.