День добрый.

Не так давно начал изучать работу Libgdx и обнаружил, что не так много статей по сему фреймворку на русском языке. Встречал, конечно, статьи на русском, но они были лишь переводами офф. мануалов. Были правда и статьи, где разработчики пытались рассказать о своих творениях. Но в одной статье всё не обхватить, в итоге в подобных статьях было всего понамешано.

Я задался целью поэтапно писать статьи о различных аспектах/частях LibGDX, чтобы в итоге, любой человек мог более-менее работоспособную версию своей собственной игрушки сделать. В этой статье хотел бы рассказать про Box2D, который присутствует в LibGDX.

Поздравить всех хабравчан с неофициальным днем компьютерной графики! В этот день я хочу рассказать вам о том как я сделал онлайн версию старой игры.

Возможно многим знакома игра DX-Ball, Я играл в нее еще в дошкольном возрасте, а уже в школе коротал за ней уроки информатики. Поэтому мне было интересно делать ее на HTML5.

Все доброго времени суток!
Хочу рассказать об одной интересной проблеме и ее решении, которое я применил в одном из своих проектов.
Суть проблемы такова:
Есть несколько детекторов сигнала (допустим, базовые станции GSM). И эти детекторы присылают на сервер уровень сигнала для некоего источника. Необходимо вычислить и отобразить на карте координаты источника
Если вам интересно, как это сделать, добро пожаловать под кат.

Многие уже наверняка сталкивались с проблемой OutOfMemoryError и находили достаточно толковый мануал Displaying Bitmaps Efficiently. Но если вы еще не успели изобрести свой велосипед на основе мануала, предлагаю свое готовое решение с объяснениями, которое умеет получать изображения:

• В формате Bitmap и byte[]
• Уменьшенное с сохранением пропорций
• Уменьшенное с вырезанием (crop) до заданного размера width x height
• Оптимизированное для 2g
• Всегда в правильной ориентации (учитывая EXIF orientation)

Мир разработчиков программного обеспечения разделен на два лагеря. Знатоки языков поют дифирамбы мощи высокоуровневого программирования — функциям высшего порядка, метапрограммированию, аспектно-ориентированному программированию, рефлексии и т.д. Знатоки инструментов имеют хорошие навыки использования утилит для сборки и отладки, документирования и автодополнения, рефакторинга и тестирования. Знатоки языков склоняются к использованию для разработки текстовых редакторов типа emacs, vim или подобных — они хорошо подходят для почти любых языков, включая новые. Знатоки инструментов выбирают IDE, такие как Visual Studio, Eclipse, или IntelliJ, включающих в себя целые наборы специализированных средств разработки.



Новые языки программирования, такие, к примеру, как Laszlo или Groovy, и новые расширения языков, такие как AOP, обычно доступны только для использования средствами универсального текстового редактора, пока не получат полноценную поддержку в какой-нибудь IDE. Спустя какое-то время, если язык действительно «выстрелил», эта поддержка, несомненно, появится. Это происходит не потому, что сделать нужный инструментарий слишком сложно. Это происходит потому, что вложение усилий в разработку языка и вложение усилий в разработку средств для него находятся в несколько ортогональных плоскостях и порой даже вытесняют друг друга. И вот почему.

Оригинал: Starting out on Game Programming

Путь в индустрию игровых разработок не близок. Эта статья призвана помочь понять с чего лучше начать это путешествие.

Вы только что закончили ваш первый курс по С++ и хотите начать делать игры. Кто-то указал вам на этот сайт и вы, возможно, поэкспериментировали немного с руководством. Вы изучили несколько лаконичных примеров, но не нашли руководства о том, как сделать целую игру. И на то есть причина.

Руководства хороши для обучения чему-то шаг за шагом, например тому, как перемещать изображение точки по экрану. Для того чтобы собрать игру воедино, вам нужны навыки решения возникающих проблем, приобретаемые лишь с опытом. Это не то, чему можно научиться из руководств. Лучший способ научиться делать игры — это начать их делать.

0. Оглавление

• 1. Предисловие
• 2. Хак eMMC памяти HTC Desire HD с целью изменения идентификационной информации телефона
• 3. Создание телефона-оборотня с использованием криптографии
• 4. Ложная безопасность: обзор угроз несанкционированного доступа к данным
• 5. Заключение

1. Предисловие

Мобильные гаджеты стали неотъемлемой частью нашей повседневной жизни, мы доверяем им свои самые сокровенные тайны, а утрата такого устройства может привести к серьезным последствиям. Сегодня много внимания уделяется освещению вопросов мобильной безопасности: проводятся конференции, встречи, крупные игроки выпускают комплексные продукты для персональной и корпоративной защиты мобильных устройств. Но насколько такие средства эффективны, когда устройство уже утрачено? Насколько комфортны они в повседневном использовании – постоянные неудобства с дополнительным ПО, повышенный расход батареи, увеличенный риск системных ошибок. Какие советы можно дать беспокоящимся за сохранность своих мобильных данных? Не хранить ничего важного на смартфоне? Тогда зачем он такой нужен – не птичек же в космос отправлять, в самом деле?
Сегодня я хочу поговорить с вами об устройствах под управлением ОС Android, созданной глубокоуважаемой мною компанией Google. В качестве примера я использую неплохой смартфон прошлых лет от компании HTC – Desire HD. Почему его? Во-первых, именно с него мы начали свою исследовательскую деятельность в области безопасности Android-устройств, во-вторых – это все еще актуальный смартфон с полным набором функций среднестатистического гуглофона. Он поддерживает все версии Android, в нем стандартный взгляд HTC на организацию файловой системы и стандартная же раскладка разделов внутренней памяти. В общем, идеальный тренажер для защиты и нападения.
С этим докладом я выступил на вот-вот только прошедшей конференции ZeroNights 2012 и теперь хочу презентовать его хабрасообществу. Надеюсь он будет вам интересен и даже немного полезен.

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

В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

Арифметика с плавающей запятой почему-то считается экзотической областью компьютерных наук, учитывая, что соответствующие типы данных присутствуют в каждом языке программирования. Я сам, если честно, никогда не придавал особого значения компьютерной арифметике, пока решая одну и ту же задачу на CPU и GPU получил разный результат. Оказалось, что в потайных углах этой области скрываются очень любопытные и странные явления: некоммутативность и неассоциативность арифметических операций, ноль со знаком, разность неравных чисел дает ноль, и прочее. Корни этого айсберга уходят глубоко в математику, а я под катом постараюсь обрисовать лишь то, что лежит на поверхности.

Одним дождливым вечером я размышлял о памяти менеджмент в Java и как эффективно использовать Java коллекции. Я сделал простой эксперимент, сколько записей я могу вставить map с 16 Гб оперативной памяти?

Git – это не только удобная распределенная VCS, но и инструмент подготовки релизов.
В статье будет рассмотрен flow на примере Java-проектов на Maven. Статья может быть полезна для разработчиков малых и средних команд, подразумеваются базовые знания git. Материал частично перекликается с git-flow, но здесь описан более простой вариант.
В классическом случае в репозитории существует одна ветка master, из нее же делаются сборки. Если проект собирается при этом на build-сервере, это может привести к беспорядку – несколько разных билдов под одной версией, не ясен набор коммитов, которые попадают в релиз (например, если сборка делается автоматически по триггеру на VCS).

Наверняка почти все читатели Хабра знают оболочки sh и bash. Так же большинство из нас что-то слышали про zsh и tcsh. Однако на этом список существующих оболочек не заканчивается. Условно можно разделить их на три группы:

• Клоны Bourne shell (bash, zsh)
• C shell (csh, tcsh)
• Базирующиеся на популярных языках программирования(psh, ipython, scsh)
• Экзотические, специфические и все остальные

О наиболее интересных из них и пойдет речь.

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

Под Unix существует множество компиляторов и интерпретаторов, но здесь мы будем обсуждать лишь gcc как средство компиляции C-кода, и коротко коснемся использования perl в качестве примера интерпретатора.

GCC

GCC — это набор компиляторов, обладающий очень почтенным возрастом и распространяемый под лицензией GPL. Он известен как инструмент работы с программами на C и C++. Свободная лицензия и повсеместная распространенность на Unix-подобных системах стали залогом его неизменной популярности, хотя есть и более современные альтернативы, использующие инфраструктуру LLVM, такие как Clang.

Текстовый редактор — это основной инструмент для любого программиста, вот почему вопрос его выбора становится причиной яростных дебатов. Unix традиционно тесно связан с двумя своими многолетними фаворитами, Emacs и Vi, и их современными версиями GNU Emacs и Vim. Эти редакторы имеют очень разный подход к редактированию текста, но при этом сравнимы по мощи.

Поскольку я отношусь к секте Vim, далее мы обсудим неисчерпаемые возможности этого редактора, а также инструменты командной строки, вызываемые прямо из Vim для расширения встроенной функциональности. Некоторые из обсуждаемых дальше принципов могут быть применимы и для Emacs, но не для простых редакторов, вроде Nano.

Одной из важных особенностей IDE является встроенная система управления файлами. Она должна включать в себя как базовые возможности, такие как переименование, удаление перемещение, так и более специфические для разработки: компиляция и проверка синтаксиса. Вдобавок было бы удобно оперировать группами файлов для поиска по размеру, расширению или по маске. В этой первой статье я покажу несколько вариантов использования инструментов, знакомых любому пользователю Linux, для работы с группами файлов в проекте.

Профессиональные программисты, как новички, так и опытные, обычно придерживаются концепции IDE, или «интегрированной среды разработки». Правда, удобно же иметь самые необходимые средства организации, написания, поддержки и тестирования кода в одном приложении с единым интерфейсом для всех инструментов? К тому же, среда, специально спроектированная для программирования, дает ряд преимуществ, таких как автодополнение, проверка и подсветка синтаксиса.

Подобные средства есть для всех распространенных настольных ОС, включая Linux и BSD, и многие из них совершенно бесплатны, так что вряд ли имеет смысл ограничивать себя в Блокнотом Windows, nano или cat.

Однако, в среде поклонников Unix гуляет в разнообразных вариациях мем о том, что «Unix — это IDE», в том смысле, что средства, которыми разработчики располагают в терминале, легко реализуют основные возможности современных IDE. Вы можете соглашаться или отказываться признать Unix «IDE» в том самом смысле, что Eclipse или Microsoft Visual Studio. Так или иначе, вас скорее всего удивит, насколько законченную среду разработки может являть собой скромный Bash.

Оригинальная статья Джона Грэхем-Камминга.
Переведено и опубликовано с разрешения автора.

Я занимаюсь программированием уже более 30 лет, начиная с машин, уже устаревших (на процессорах Z80 и 6502) до современных, используя языки BASIC, ассемблера, C, C++, Tcl, Perl, Lisp, ML, occam, arc, Ruby, Go и многие другие.

Далее следует список того, чему я научился.

David Drysdale, Beginner's guide to linkers (http://www.lurklurk.org/linkers/linkers.html).

Цель данной статьи — помочь C и C++ программистам понять сущность того, чем занимается компоновщик. За последние несколько лет я объяснил это большому количеству коллег и наконец решил, что настало время перенести этот материал на бумагу, чтоб он стал более доступным (и чтоб мне не пришлось объяснять его снова). [Обновление в марте 2009: добавлена дополнительная информация об особенностях компоновки в Windows, а также более подробно расписано правило одного определения (one-definition rule).

Типичным примером того, почему ко мне обращались за помощью, служит следующая ошибка компоновки:

g++ -o test1 test1a.o test1b.o
test1a.o(.text+0x18): In function `main':
: undefined reference to `findmax(int, int)'
collect2: ld returned 1 exit status

Если Ваша реакция — 'наверняка забыл extern «C»', то Вы скорее всего знаете всё, что приведено в этой статье.

Стал тут было народ писать игру под андроид и столкнулись в Andengine(кто не знает, это самый популярный граф. 2D движок под андроид) с такой задачей: есть набор соединённых между собой линий, который предствляют собой ландшафт (как сгенерить, можно почитать тут — gameprogrammer.com/fractal.html). Выглядело это примерно так:



Но нам не нужен “мостик”, нам нужна поверхность, да ещё и с текстурой, вообщем чтобы было вот так…