В первой части разработки тетрисоподобной игры Impressive Solids мы реализовали основную часть геймплея, уделив минимальное внимание внешнему виду приложения. Мы и OpenGL-то почти не использовали, всего и делали, что рисовали цветной прямоугольник. Пришла пора заняться оформлением, а также реализовать подсчёт очков и хранение рекорда (high score). Ну что, поехали дальше.

Picture This

Займёмся текстурами. Нам нужно, во-первых, натянуть что-нибудь на фон окна, а во-вторых, сделать приятно выглядящие блоки (сейчас это просто цветные прямоугольники). Понятное дело, сначала надо изготовить текстуры. В этом нам поможет GIMP. Если у вас нет желания заниматься графикой, можете просто скачать архив с готовыми текстурами и переходить к следующему этапу.

Но сперва отмечу один очень важный нюанс. До версии OpenGL 2.0 каждый из размеров текстуры обязан был быть равным степени двойки (т. е. 64×64, 512×256; это POT-текстуры, от англ. power of two). Если текстуры произвольного размера (NPOT-текстуры) не поддерживаются видеокартой или драйвером видеокарты, такая текстура не будет работать. Это имеет место, например, для встроенных видеокарт Intel под Windows XP.

Чтобы гарантированно обезопасить себя от этой проблемы, самое простое и удобное решение — всегда использовать POT-текстуры. Однако это не всегда возможно, и дальше, когда мы дойдём до вывода текста, нам придётся заняться этим моментом.

Once Upon a Time in America

Когда-то, году в 2002-м, на мой компьютер попала интересная игрушка, так сказать, класса тетриса (подробное описание геймплея приведено ниже); она очень полюбилась моей маме, которая играла в эту игру часами. Однако был досадный недостаток: после, кажется, 10 запусков игра начинала требовать регистрацию, которая, что удивительно, была бесплатной, но через интернет, что, само собой, являлось непреодолимым препятствием, поскольку интернета-то никакого тогда в наших краях в глаза не видывали, хоть и слыхали, что есть такая штука. Приходилось постоянно переустанавливать.

Через года три, когда интернет уже провели, а игра успела стать shareware и начать просить за регистрацию сколько-то денег, я попробовал её зарегистрировать, однако сайт производителя был к тому времени скорее мёртв, чем жив, и, по-видимому, остаётся таким и по сей день. В интернете легко находится shareware-версия игры, множество, не побоюсь этого слова, кейгенов, являющихся на самом деле троянами, и ни одной возможности зарегистрировать игру, чтобы мама могла в неё играть уже совсем на другом компьютере. В какой-то момент я подумал: а почему бы просто самому не сделать аналогичную игру и решить тем самым проблему на корню? Заодно из этого может получится какой-никакой hello-world по разработке простой игры для ПК в современных условиях — который я и предлагаю вниманию читателей.

Часто требуется реализовать возможность рейтингового оценивания того или иного объекта (заметки, комментария, цитаты, фотограммы, видеоролика и т. д.) посетителями сайта. Как это запрографировать?

Прежде всего мы имеем объект оценивания и субъект оценивания. Последним могут быть, например, зарегистрированные пользователи, незарегистрированные пользователи (гости) и пр.

Для того, чтобы обеспечить слабую связанность конкретных сущностей предметной области, к которым мы привязываем возможность рейтингового голосования, с модулем, реализующим нашу задачу, мы выделяем отдельные классы для объекта (Rating_Object) и субъекта (Rating_Subject). Оба эти класса — конкретные и реализованы как active record. Чтобы иметь возможность привязывать всяческие статьи и фотограммы к экземплярам Rating_Object, мы предусматриваем интерфейс Rating_Ratable:

interface Rating_Ratable {
    /**
     * @return Rating_Object
     */
    public function asRatingObject();
}

Обсуждая с различными людьми — в большинстве своём опытными разработчиками — классический труд «Приёмы объектно-ориентированного проектирования. Паттерны проектирования» Гаммы, Хелма и др., я с изумлением встретил полное непонимание одного из базовых подходов ООП — различия классов и интерфейсов.

Часто на разнообразных сайтах пользователям предлагают оценить (проголосовать за) тот или иной объект — анекдот, цитату, пост, автора, человека и т. д. При этом, к сожалению, почти всегда совершается одна или несколько ошибок.

Я буду говорить только о тех случаях, когда пользователям предлагают оценить объект положительно или отрицательно. Голосования с выбором одного из нескольких вариантов ответа здесь не рассматриваются.

Вопрос: «Что быстрее — echo или print?» не перестаёт будоражить умы тех, кто считает себя профессиональным программистом на PHP. Руководство пользователя осторожно упоминает об имеющемся различии, но отсылает к статье стороннего авторства; та, в свою очередь, утверждает, что echo быстрее, но не приводит доказательств; трудно найти объективное сравнение, и всё это придаёт проблеме некий мистический ореол, на что клюют многие и многие.

Так не будем же оставаться в стороне и постараемся раз и навсегда разгадать эту загадку!

Более 24 лёт прошло с изобретения доменных имён (и 18 — с создания Всемирной паутины), а люди так до конца и не освоились в вопросе выбора доменного имени для сайта.

До сих пор распространено нелепое суеверие, будто домены третьего уровня менее привлекательны, нежели домены второго уровня; более того, не так давно мне приходилось сталкиваться с утверждениями, будто домен в зоне .info неприличен — и почему? только лишь из-за низкой цены!

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

Однажды вечером я почувствовал, что пришло время расширить 97‐ й параграф «Ководства» Артемия Лебедева.

На клавиатуре одна чёрточка, она обычно правее нуля и повыше букв «З» и «Х». Неосведомлённые люди называют её попеременно то дефисом, то минусом, то тире. Лебедев объясняет нам, что это четыре (учитывая две разновидности тире) различных символа. На самом деле их как минимум девять, и об этом я и расскажу вам сейчас.

Когда-нибудь каждый JavaScript-программист осознаёт, что JS — объектно-ориентированный язык. И здесь его подстерегают некоторые опасности, происходящие от непонимания того факта, что JS — язык не классов (как Паскаль или Цэ-два-креста), а прототипов.
Так, уже многое написано о проблеме наследования (котого в JS нет). Я же постараюсь рассказать о менее освещённом, но едва ли не более важном подводном камне: грамотной реализации методов.
Программисты пытаются объявлять классы в привычной для них форме, из-за чего возникают утечки памяти и прочие неприятные вещи. На самом деле нужно всего лишь научиться использовать прототипы.
Эта статья предназначена прежде всего для начинающих JS-программистов.

Четыре с половиной года назад Артемий Лебедев написал 98-й параграф «Ководства».
Что изменилось с тех пор? Стали ли тексты в вебе человечнее? Может быть. Не так часто уже приходится натыкаться на пассажи вроде «осталось секунд: 1». Люди научились учить роботов говорить «осталась 1 секунда», «осталось 2 секунды», «осталось 5 секунд»; или хотя бы сокращать в этом случае секунды до несклоняемого «с».
И в то же время многие так ничему и не научились за эти почти пять лет.

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