Работа посвящена погрешностям округления, возникающим при вычислениях у чисел с плавающей запятой. Здесь будут кратко рассмотрены следующие темы: «Представление вещественных чисел», «Способы нахождения погрешностей округления у чисел с плавающей запятой» и будет приведен пример компенсации погрешностей округления.

В данной работе примеры приведены на языке програмиирования C.

На фоне общей увлеченности созданием ботов для Telegram я бы хотел рассказать об API не очень широко известного мессенджера Tox и показать на примере простого echo-бота, как можно так же легко и быстро создавать собственных.

Всем привет!

Две недели назад в Москве прошла очередная встреча CodeFreeze. Нашим гостем стал Евгений Кривошеев, признанный российский эксперт в области архитектуры программных систем, консультант из Scrumtrek/Skilltrek. Евгений прочитал офигеннейшую лекцию по архитектуре, как он любит и умеет.



В рамках этой встречи Евгений предложил обсудить последовательность решений, критичных для архитектуры любой системы. Выстраданная последовательность действий такова:

• Точки зрения на систему, или Почему мы слепнем при проектировании
• Адресация ключевых рисков, или Гордыня убивает
• Учитываем контекст, или Как не долбиться в закрытую дверь

Приглашаю всех присоединиться к переводу книги. За перевод первой главы спасибо Лилии Кутуевой.
Начало тут.

Несмотря на то, что могут быть (и есть) и более фундаментальные определения этого понятия, тем не менее, Виртуальные Миры (ВМ) всегда придерживаются определенных условий, отличающих их от других родственных виртуальных пространств. Самыми основными будут следующие:

1. В основе ВМ лежат базовые автоматизированные правила, которые побуждают игроков производить в нем изменения (однако, они не могут менять сами правила, которые дают им такую возможность). Таковы физические основы ВМ.
2. Игроки играют своих персонажей «внутри» мира. Они могут обладать частичным или полным влиянием на войско, команду или группу людей, но в этом мире есть лишь одна игровая сущность, которой они представлены и с которой прочно связаны – это их персонаж. Поэтому и все взаимодействия с миром и другими игроками опосредованы этим персонажем.
3. Взаимодействие с миром осуществляется в режиме реального времени. Соответственно, когда вы что-то в нем делаете, можете ожидать немедленной ответной реакции.
4. Этот мир – многопользовательский.
5. Этот мир – стабилен (по крайней мере, до некоторой степени).

Игровой чат не является ВМ, потому что не имеет заданных физических параметров. Варгейм-стратегия не проецирует игрока на персонажа, которым он играет. Игра по электронной почте не происходит в режиме реального времени. Игра с одним игроком не является многопользовательской. Мир шутера от первого лица неустойчив.
В некоторых примерах аргументы не столь однозначны. Например, являются ли настольные РИ виртуальными мирами? Нет, потому что они не автоматизированы, но уже недалеки от этого. Может ли образовательный МПМ из двух игроков быть назван виртуальным? Возможно. Будет ли таковым мир игры на 500 игроков, мир столь большой, что некоторые игроки могут никогда друг с другом и не встретиться? Да, но это спорный вопрос.
На поверку определить, является ли мир виртуальным или нет, довольно легко – достаточно проверить его происхождение. Если его устройство в значительной степени списано с устройства существующего ВМ, почти наверняка это – ВМ; если же нет, тогда почти наверняка это не он.

Когда я начинал строить свою карьеру в игровой индустрии шесть лет назад, то часто задавался вопросами по геймдеву. Начиная от поиска общего понимания того, как разрабатываются и оперируются онлайн-игры, до частных вопросов типа того, как лучше рекламировать конкретную игру. Тогда было мало структурированной информации по созданию и продвижению игр, новичку разобраться и найти ответы было исключительно сложно. Практически единственным источником информации был собственный опыт и консультации более опытных коллег. Сейчас ситуация кардинально изменилась. Информации по игровой индустрии настолько много, что рискуешь в ней просто утонуть. Для того, чтобы упростить процесс получения нужных мне знаний, я структурировал и делал себе пометки по всем источникам информации о геймдеве. Далее в статье предлагаю всю эту информацию в удобной форме для общего пользования.

Самое интересное в игре, как правило, связано с напряжением. С другой стороны, постоянно находиться в напряжении нельзя, поэтому требуется «отпускать» игрока и давать ему расслабиться.

Механика базы работает чертовски просто:

1. В игре создаётся некое место, где игроку приятно и безопасно проводить время.
2. После периода напряжения игрок отправляется в это место.
3. Закончить в этот момент сложно. Кто будет отказываться от приятного «отдыха»? Нет, из игры не выходят перед приятной частью.
4. Далее мы стараемся без перехода выводить игрока в следующий цикл, требующий напряжения – так, чтобы игрок не успел понять, как там оказался.

В итоге получается механика, когда игрок просто не может остановиться перед следующим сложным этапом, потому что вместо выбора и рефлексии он уже там.

Git — штука не то чтобы особо сложная, но гибкая. Иногда эта гибкость приводит к забавным последствиям. К примеру, посмотрите на этот коммит на GitHub. Он выглядит как нормальный коммит, но если вы клонируете себе данный репозиторий, то такого коммита в нем не найдете. Потому что это потерянный коммит, более известный как git loose object или же orphaned commit. Под катом — немного про внутренности Git, откуда такое берется и что делать, если оно вам встретилось.

Реализация поведения юнитов в RTS играх может стать серьезной проблемой. Компьютер, зачастую, контролирует огромное количество юнитов, в том числе и принадлежащих игроку, которые должны передвигаться в большом динамическом мире, попутно избегая столкновения друг с другом, выискивая врагов, защищая собственные базы и координируя атаки для истребления противника. Стратегии реального времени работают в реальном времени, что делает довольно сложным слежение за планированием действий и навигацией.

Этот урок описывает метод планирования течения игры и навигации юнитов, который использует многоагентные потенциальные поля. Он основан на работах под номерами [1, 2, 3]. (Смотри в конце статьи ссылки на используемые материалы)

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

Каждый день в робошколе проходят занятия на которых, ученики собирают роботов и слушают о них лекции. И вот на днях как-то встал вопрос кто из русских фантастов оказал на НФ самое большое влияние. Оказалось, что имя Павла Клушанцева не знает никто. А ведь на западе это главный русский фантаст, о стругацких там не слышали, а вот в подражание Клушанцеву Лукас снял свои замечательные Звездные войны. Давайте это исправлять.



Если нужно посмотреть всего один фильм для знакомства с ХХ веком, звездные войны вне конкуренции. Нет фильма оказавшего больше влияние на поп-культуру, подтверждением тому Рейган назвавший СССР Империей зла и объявивший ей «Звездные Войны» СОИ. Почему именно Звездные Войны завоевали такую популярность?

Секрет успеха звездных войн лежит на поверхности если вы хоть немного знакомы с теорией кино или т.н. «электронных средств коммуникации». Вся теория укладывается в четыре слова «Media is the message». Медиа и есть сообщение — впервые вывел в своей книги Маршалл Макклюен в своей книге «Понимание медиа». Она вышла в 1968 небольшим тиражом, но просочилась в среду хиппи и киношников Голливуда. Книга была довольно заумной, местами малодоказательной и похожей на эзотерику хиппи, но его схемы безупречно объясняли, что происходит. Например, почему телевизор с плохой картинкой неожиданно оказался гораздо популярнее кино.

Стараюсь читать все статьи на Хабре по электронике для начинающих, DIY, Arduino. И вот только что прочитал статью «Ардуино. 6 шагов». Под впечатлением решил попробовать закинуть свои 5 копеек.

Основная деятельность напрямую не связана с электроникой. Она, как и программирование, всегда были лишь хобби. Семь лет назад я стал папой и вот пришло время научить сына, заодно попутно вспомнить всё, ну и научиться самому.

Вступление

Последние два с половиной года я активно занимаюсь созданием игр как инди-разработчик. За это время накопилось много опыта, в том числе полученного путём ходьбы по граблям. В этой статье я хочу поделиться своими наблюдениями насчёт того, как правильно подготовиться к созданию новой игры, что из себя представляет пре-продакшн, что такое оценка рисков и почему она нужна, как лучше собирать команду «на энтузиазме». Также я изложу несколько своих идей по организации командной работы, важности наличия руководителя даже в инди-проекте, расскажу о некоторых подводных камнях.

В продолжении статьи про blowfish хотелось бы поговорить про его основу — сеть Фейстеля. Люди «в теме» слышали про неё не одну сотню раз — эта сеть используется в подавляющем большинстве блочных шифров. Но вот вам, только честно, что нибудь понятно из картинки справа? Ну, допустим в одну сторону(шифрование) понятно, а обратно?
Если нет, то прошу под коврик

«Бог всегда на стороне больших батальонов» — Жак д'Эстамп дела Ферте, французский маршал

Рис. 1

Во многих компьютерных играх необходимо симулировать сражения без отображения их хода на экране. Например, это может быть Rogue-like пошаговая игра, в которой компьютер должен посчитать только исход сражения (кто победил) и потери сторон. Даже в интерактивных играх сражения, которые происходят за пределами поля видимости игрока, можно моделировать упрощенно. Я разработал интересную математическую модель для такого моделирования и представляю ее читателям.

В статье рассматривается «непрерывный» подход — то есть силы сторон являются непрерывными величинами, а их взаимодействие происходит в непрерывном времени. Это позволяет воспользоваться методами мат. анализа и получить решение в явном виде. Для армий, состоящих из большого количества боевых единиц, такое упрощение не вносит большой погрешности. Вместе с тем, решение в явном виде позволяет понять многое о задаче.

Однажды судьба свела меня с ней. С первого взгляда я был ослеплен и долгое время не мог отвести от нее взгляд. Шло время, но она не переставала меня удивлять, иногда казалось, что я изучил ее вдоль и поперек, но она снова переворачивала все мои представления. Ее гибкости не было предела, а потом я узнал, что она умеет еще и… ООП!

Как-то я всерьез занялся покорением ООП в lua. И все, что я находил в интернете по этой теме, было вырвиглазными нагромождениями кода с обилием нижних подчеркиваний, которые никак не вписывались в элегантность этого языка. Поэтому я решил искать простое решение.

После прочтения множества умных книжек и разбора нескольких ужасных реализаций ООП, я, крупица за крупицей, собирал все самое полезное и простое, пока не выработал свой стиль объектно ориентированного программирования на lua.

Эта статья — взгляд на тестирование ММО с «другой стороны баррикад», с точки зрения геймера. Я хочу рассказать о том, как сделать альфа-тест, ЗБТ и ОБТ эффективнее. И о том, почему бета-тестеры перестают писать баг-репорты и переходят «в оппозицию» к проекту.

Предисловие

За свою жизнь я участвовал в ЗБТ и ОБТ примерно 30 игр. И самый главный вывод, который я для себя сделал – гейм-девелоперы совершенно не умеют распоряжаться теми людскими ресурсами в виде нескольких тысяч жаждущих прокликать весь функционал геймеров, которые им сваливаются на голову. И именно поэтому и был написан данный материал. От геймера – разработчику, сидящему по ту строну экрана. От тестера – компаниям, которые не понимают, как правильно организовать процесс тестирования усилиями игроков.

Статья разбита на четыре раздела и написана в разговорном стиле. Я по порядку разбираю ошибки разработчиков на альфа-тесте, ЗБТ/ОБТ и при наборе тестеров после релиза. Те, кто хочет конкретики без долгих прелюдий и размышлений, могут сразу листать к последнему абзацу каждого раздела и выводам.

Цель статьи

Документирование получения системы кросс-компиляции под Linux для Windows x32/x64/static/shared и сборка последней на момент описания Qt 5.4.1 в лайт-версии (для указанных четырех целей). Для себя, глубоко-обожаемого, ну и для пользы обществу.

Назначение

Многие разработчики приходят к выводу, что использование *nix (в частности Linux) более предпочтительно для разработки приложений, используя фрэймворк Qt. И тому есть причины. Qt изначально ориентирована на *nix инструментарий, типа autotool, make, perl… И второй момент, под никсами есть прекрасный инструмент — valgrind, под виндой порта пока его не видел. Ну и последняя причина: просто удобно иметь набор инструментария для создания приложений под различные целевые платформы — в одном месте.

Почему лайт-версия Qt5

Фрэймворк-Qt имеет модульную структуру, но, увы, не совсем совершенную. Некоторые зависимости от внешних библиотек «вешаются» не на модуль, требующий эти библиотеки, а на Qt5Core. Иными словами, нужна вам эта библиотека, или нет — вынь да положЪ в дистрибутив. Пример тому «монстрик» — библиотека ICU. Весит она почти 25 метров! Зависимость вешается, как я упоминал выше, на Qt5Core… а требует ее модуль Qt5WebKit (который по сути в 99% случаев не используется, по крайней мере мной). Что делаем? Вырезаем и отрезаем. Хотите получить фулл-версию Qt5? Об этом упомяну в заключении. Поехали.

Здравствуйте.
В первой части статьи я расскажу о некоторых стилистических «косяках», которые придают текстам характерный канцелярский унылый стиль. Вторая часть посвящена более серьёзной ошибке, которая, к сожалению, грозит в ближайшее время стать правилом.

Мы часто видим ошибки и опечатки в интернете. Как правило, принято или с достоинством пройти мимо, в глубине души презирая неграмотного (или невнимательного) писателя, или, наоборот, с увлечением развернуть просветительскую деятельность (не всегда, к сожалению, уважительную). В лучшем случае, если на сайте установлен Orphus — нажать Ctrl+Enter.

Так поступал и я, пока однажды с ужасом не заметил, что написал «вООбщем» или нечто подобное. Разрушительное влияние чтения форумов, да и, что уж там, самого Хабра, на читательскую грамотность — налицо. А между тем — сейчас есть многое, что могло бы облегчить участь наших бедных глаз!

Когда вы захотите обновить версию Visual C++ компилятора (например, перейти с Visual Studio с 2013 на 2015), будет не лишним узнать, почему вы можете столкнуться с тем, что код, который прежде успешно компилировался и выполнялся, теперь будет вызывать ошибки компиляции и/или ошибки времени выполнения.
Эти проблемы могут быть вызваны многочисленными изменениями компилятора для соответствия стандарту С++, изменениями в сигнатурах функций или изменениями расположения объектов в памяти.