Нижеизложенный материал, вероятно, знаком, или даже хорошо известен, программистам, имевшим опыт работы с OpenGL, между тем, я счел уместным напомнить о модели oblique frustum, отчасти наблюдая (и разделяя) интерес читателей Хабра к вопросам OpenGL и в целом трёхмерного моделирования, отчасти из несогласия с позицией некоторых разработчиков вроде «…чтобы это использовать, вовсе не обязательно разбираться в том, как работает матрица проекции», отчасти из уважения и благодарности к Эрику Ленгелу|Eric Lengyel, изобретательная мысль которого обогатила приемы работы в среде OpenGL.

Если в моделируемых вами сценах присутствуют зеркальные отражения, и вы подзабыли или не слышали про «oblique frustum», то возможно, что эта статья не будет для вас бесполезной.

Несмотря на то, что я, вслед за Эриком Ленгелом, более придерживался при изложении материала представлений OpenGL, все последующие рассуждения легко распространяются на любые другие системы трёхмерного моделирования.

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

---

Совсем немного истории

Головоломка «Instant Insanity» (Мгновенное Безумие), возможно, одна из самых востребованных для иллюстрации применимости теории графов в решении задач подобного ей типа.

Android Studio — очень надежный инструмент. Он имеет самый простой и вместе с тем самый гибкий интерфейс для разработки пользовательского интерфейса для всех типов устройств.
Мы можем перетаскивать элементы представления и виджеты в нашем редакторе макетов и детально настраивать через несколько строк в xml.

Студия обладает лучшими в отрасли инструментами для редактирования кода, отладки и отслеживания производительности.

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

Художники нарисовали яркую графику, программисты встроили ее в игру, аниматоры добавили движения — казалось бы, все, готово. Но нет, менеджерам не нравится:

«Надо убрать серые пятна и белые линии. Тут пульсирующая кнопка дергается, там прогресс-бар лесенкой идет».

Смотришь игровые ресурсы — нет в них ничего такого, все спрайты обрезаны. Читаешь код — формулы правильные, точности шейдера хватает. Но результат все равно получился неважный. Где ошибка?



Небольшой опрос для тех, кто уже знает откуда берутся артефакты. Что делать в такой ситуации?

1. Нужна мощная видеокарта и свежие драйверы;
2. Стоит сделать скачиваемые наборы графики для всех возможных разрешений экрана;
3. У квадратных текстур с размерами степени двойки нет таких проблем;
4. Это все из-за сжатия графики (PVRTC/DXT5/ETC1/...);
5. В графическом редакторе придется слегка размазать края;
6. Так и должно было получиться, ведь мы не подготовили графические данные;
7. Поможет только антиалиасинг;
8. Нужны текстуры и таргеты в режиме premultiplied alpha.

Какой вариант ответа правильный, почему именно он и как побороть артефакты графики читайте под катом.

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

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

Android содержит массу способов для организации данного подхода, но одним из самых удобных можно признать использование AsyncTask и ProgressDialog.

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

Привет. Из названия темы вы могли заметить, что речь пойдет о том, как устроены Tasks и Back Stack в Android. Эта статья будет являться свободным переводом официального источника. Тема больше ориентирована на новичков, но я думаю, что и опытный разработчик сможет узнать что-то новое, т.к. тема специфична и не часто приходится кастомизировать поведение наших Activity.

На Stackoverflow часто встречаются вопросы по выполнению на Android фоновых задач, в т.ч. и повторяющихся с заданным промежутком времени. Как правило, первое, что используется, это Service.

Такой подход в некоторых случаях может привести к тормозам и низкой скорости ответа пользовательского интерфейса. Расскажу когда так бывает и как с этим бороться…