суббота, 28 сентября 2013 г.
пятница, 20 сентября 2013 г.
Журнал "FPS" №26

Читайте в этом номере:
> Tube Open Movie. Интервью с Бассамом Курдали
> Обзор дополнений Blender, выпуск 5
> GIMP: ломо-эффект как в Instagram
> Физический движок своими руками, часть III
> Making-of: логическая мини-игра Arrow
> Генерация случайных уровней
> Осваиваемся в SDL2
> Пишем плагин для DeleD на D
> Как я стал D-шником или Путь художника в IT
> Игровые новости из мира СПО и Linux
> "Корпорация зла". Почему у Microsoft нет будущего
Номер доступен для онлайн-чтения и загрузки на сервисе Issuu.com, Документах Google и Dropbox.
Последние новости по проекту вы можете узнать в публичной странице журнала в социальной сети Google+: http://gplus.to/fpsmag. Добавляйте нас в круги, оставляйте свои комментарии и отписывайтесь в нашем сообществе.
Архив номеров журнала здесь.
пятница, 13 сентября 2013 г.
Как я стал D-шником
С тех пор, как
у меня появился компьютер, меня всегда
интересовало то, как он работает. Надо
сказать, что, хотя по профессии я художник,
я всю жизнь интересуюсь механизмами и
электроникой. Больше всего, конечно,
меня привлекает создание и обработка
изображений при помощи вычислительной
техники. Но знакомства с одними только
графическими редакторами мне оказалось
мало – гораздо интереснее изучить и
понять, как, собственно, все эти фотошопы
и 3ds-max'ы устроены. Ну и, конечно, игры –
куда же без них? Мне кажется, что
компьютерные игры можно считать «восьмым
искусством» после кино. Эволюция четко
прослеживается: сначала были статические
картины, затем появились «движущиеся»
– кинематограф и мультипликация; логично
допустить, что следующее поколение
произведений искусства должно быть
интерактивным: зритель сам должен
принимать участие в раскрывающемся
перед ним действии. Художники XXI века –
это создатели игр...

До кубиков,
правда, дело дошло нескоро – ведь
необходимо было изучить азы. В этом
большую помощь оказали школьные уроки
информатики: помимо непосредственно
азов (устройство компьютера, двоичная
система, теория алгоритмов и т.д.), на
них изучался всеми любимый и тепло
вспоминаемый Pascal. Конечно, работать в
DOS-режиме Windows 95 было еще тем удовольствием,
но именно тогда началось мое знакомство
со всем семейством паскалеподобных
языков, что не могло не сказаться на
будущих предпочтениях.
Однако Паскаль,
при всех его достоинствах, не слишком
хорошо подходил для моей главной цели
– создания 2D-игр (трехмерная графика
Blitz BASIC мне тогда была еще не по зубам).
И тут мне посчастливилось наткнуться
на Game Maker – специализированную среду
для быстрой разработки игр с собственным
редактором уровней, объектной системой,
графическим редактором и встроенным
скриптовым языком GML. Это была некая
смесь Pascal и C++: можно было либо использовать
фигурные скобки, либо begin/end.



Закрытость и
несвободность ПО – это зло, которое в
равной степени вредит и его пользователям,
и разработчикам. Пользователям – потому
что они никогда не могут быть уверены,
что закрытая программа не следит за
ними, не ворует их информацию. А
разработчикам – потому что закрытую
программу труднее поддерживать, улучшать
и исправлять: ведь этим занимаются
только работники фирмы, владеющей
программой. В результате ошибки в ПО
исправляются годами – а то и вовсе не
исправляются (и это не шутка). А если бы
исходный код был публично доступен,
любой квалифицированный программист
сразу исправил бы найденный баг, отправил
бы разработчикам патч, предложил бы
рекомендации к улучшению тех или иных
конструкций. И таких помощников были
бы сотни – взгляните на крупные открытые
проекты, развиваемые сообществом.
Наконец, если фирма, занимающаяся
разработкой программы, обанкротится,
то сообщество ее пользователей, не имея
на руках исходного кода, оказывается
асболютно беспомощным – но зачастую
люди продолжают использовать такие
«мертвые» программы годами и десятилетиями,
если им нет альтернативы. Такая ситуация,
к примеру, наблюдается в нашей
промышленности и оборонной технике.
Вот такие абсурды порождает собственническое
отношение к коду.
Осознав все
это, я пришел к выводу, что проприетарная
Xtreme3D (к тому же, по всей видимости,
заброшенная автором) – это тупиковый
путь. В разработке ПО нужно пользоваться
только свободными инструментами – и я
начал изучать C++, выбрав этот язык как
наиболее доступный из всех компилируемых.
Моей первой IDE под Windows стала Dev-C++ - среда,
основанная на инструментарии GCC/MinGW.
Язык сразу поразил меня своей красотой
и выразительностью – до этого я не имел
никакого понятия о ООП и составных типах
данных. Впечатлившись этим богатством
и относительной простотой его использования
(Dev-C++ позволяла устанавливать пакеты
расширения – можно было найти пакеты
для работы с OpenGL, DirectX, Irrlicht и т.д.), я
загорелся идеей написать свой собственный
3D-движок для Game Maker.

Дело в том, что
я неизлечимо болен перфекционизмом. Я
постоянно улучшаю уже написанное и
многократно переписываю все с нуля.
Очень редко я бываю доволен сделанным,
поэтому у меня не наберется и тысячи
стабильных строк кода, которые бы я
никогда не менял.
Другая причина
– переход на язык D. Поскольку я
любитель-одиночка, я могу позволить
себе роскошь выбирать язык по своему
вкусу – и я знаю, что все профессионалы
завидуют таким, как я, хотя и тщательно
скрывают это под маской снобизма и
показной крутизны. К счастью, к тому
моменту, когда я познакомился с D, у меня
еще не была накоплена слишком большая
кодовая база, и не было таких инструментов,
от которых я не мог бы отказаться.
dlib начиналась
как библиотека линейной алгебры
(манипуляции над векторами, матрицами,
кватернионами и т.д.) – такие пишет для
себя каждый игровой программист. Алгебра
сейчас составляет пакет dlib.math. Потом
были добавлены средства вычислительной
геометрии (dlib.geometry) – игровому движку
требуются функции обнаружения пересечений
фигур, пространственные измерения и
т.д. Вслед за ней – пакет для хранения
и обработки изображений (dlib.image), который
родился в результате изучения мной
различных алгоритмов фильтрации. Эта
часть dlib еще далека от завершения – к
примеру, полностью поддерживается
только формат PNG, не реализованы многие
другие функции. Однако dlib.image уже вполне
годится для использования в играх. Чем
будет dlib в будущем? Вероятнее всего,
универсальной вычислительной библиотекой:
в перспективе я планирую добавить
поддержку обработки и кодирования аудио
и видео. dlib можно будет применять как
backend для построения игровых движков,
симуляторов, аудио- и видеопроигрывателей,
программ-конвертеров, различных
графических редакторов, инструментов
монтажа и композитинга.
Подписаться на:
Сообщения (Atom)