В начале XXI века программирование графики выглядело кардинально иначе по сравнению с современными подходами, где API высокого уровня и мощные графические движки берут на себя основную работу. Платформа PlayStation 2, выпущенная в 2000 году, стала одной из самых успешных игровых консолей, а её графический процессор – GS (Graphics Synthesizer) – до сих пор остаётся уникальным примером низкоуровневого взаимодействия с игровым железом. Погружение в основы работы с GS помогает лучше понять принципы обработки графики, которые остались актуальными и в наши дни, несмотря на появление новых технологий и архитектур. Этот взгляд с нуля показывает удивительную сложность и изящество тех методов, которые использовались для вывода красивых и динамичных изображений на экран. Главное отличие PlayStation 2 от большинства современных систем заключается в том, что для генерации изображения необходимо напрямую управлять аппаратными регистрами, формируя специальный поток команд, который интерпретирует графический чип.
GS самостоятельно не принимает высокоуровневые вызовы, а «ест» последовательность инструкций, которые точечно конфигурируют его регистры. Такой подход напоминает программирование микроконтроллеров или старых видеокарт, где любой кадр являлся результатом тщательной и детальной работы с железом. Первая задача, с которой сталкивается разработчик, – подготовка «пакета» данных (packet), который GS способен понять и обработать. Для начала необходимо задать основные параметры, такие как режимы работы – включение сглаживания цветов, определение буфера кадра и области вывода на экран. Именно для этого используются специальные пакеты с тэгами GIFTag, которые описывают как и сколько регистров будет записано, а также формат этих данных.
В примере «Hello Triangle» используется пакет, который программирует три ключевых регистра: PRMODE, отвечающий за глобальные настройки (включение гоуро-сглаживания цветов), FRAME, определяющий расположение кадра в памяти видеопамяти VRAM и параметры цвета, а также SCISSOR – прямоугольную область вывода изображения. Важна каждая мелочь: для указания адреса буфера кадра используется деление на 8192, а ширина буфера выражается в блоках по 64 пикселя, что связано с особенностями организации памяти GS. Следующий этап – очистка буфера до определённого цвета, выполняемая с помощью примитива SPRITE. В отличие от современных графических API, где спрайтами управляют с помощью массивов текстур и вершинных шейдеров, здесь используется прямолинейное описание четырехугольника через две координаты – верхний левый и нижний правый углы, выраженные в фиксированном формате с 12-битной точностью после запятой. На практике это означает, что вращение спрайтов на 90 или 270 градусов затруднено, но в таких случаях к работе подключаются уже треугольники.
Чтобы задать цвет спрайта и его размеры, формируется новый пакет, описывающий последовательность регистров, в которые записываются компоненты RGBA и координаты XYZ для вершин. Именно запись координат запускает отрисовку вершины на уровне микропроцессора графического сопроцессора, что по сути является аналогом вызова glVertex3f из OpenGL, только сделанного вручную без абстракций. Главное преимущество этого подхода – полный контроль над каждой командой и пакетом, что даёт простор для оптимизаций и нестандартных эффектов, которые могли быть невозможно реализовать классическими играми и движками того времени. Когда приходит время отрисовки собственно треугольника, создаётся структура, содержащая три вершины, каждая из которых с параметрами цвета и координат, а сам пакет описывает циклическую обработку данных – повторять три раза запись цвета и координат. Это позволяет централизовать и упростить код, подавая данные именно в том формате, который понимает видеочип.
После подготовки всех упаковок данных остается настроить видеоконтроллер CRTC, который отвечает за вывод изображения на экран. Здесь тоже присутствует немало хитростей – включение и отключение отдельных цепей вывода сигнала, выбор видеорежима (например, NTSC стандарт 480i), установка режимов смешивания пикселей, а также параметры масштабирования и позиционирования изображения в области экрана. Особенность GS состоит в том, что все эти настройки задаются вручную через программирование специальных регистров, напрямую влияющих на видео-сигнал. Для разработчика это означает тщательное понимание работы каждого бита и регистра, чтобы добиться корректного и качественного вывода. Благодаря экспериментам и публично доступным реализациям таких пакетов для GS стало возможным создавать и воспроизводить сцены и модели на современных устройствах в рамках эмуляции.
Проект parallel-gs-stream – пример утилиты, позволяющей читать подготовленные потоки данных и транслировать их в видео поверхность, что открывает путь к анимации примитивов без использования сложных API или драйверов, имитируя работу оригинального железа PlayStation 2. За счёт использования конвейерной архитектуры и программируемых примитивов, PS2 графика демонстрирует уникальную комбинацию мощности и простоты, в сравнении с современными методами, где большая часть действий уходит за кадр в виде шейдеров и высокоуровневых команд. Понимание основ низкоуровневого взаимодействия с графическим процессором даёт глубокое удовлетворение и позволяет взглянуть на компьютерную графику не как на готовое волшебство, а как на детальный, кропотливый процесс конструирования изображения из множества мелких кирпичиков. Такой древний способ рендеринга остаётся актуальным для хакеров, энтузиастов и студентов, желающих освоить архитектурные особенности игровых консолей и развить навыки оптимизации графических алгоритмов на уровне железа. В будущем развитие этой темы обещает изучение более сложных техник, таких как простое текстурирование с перспективным искажением, что подчеркнёт эволюцию графического конвейера с начала 2000-х годов до нашего времени.
И хотя программирование PS2 может показаться архаичным и избыточно сложным в эпоху Vulkan и DirectX 12, оно остаётся важной частью истории компьютерной графики и незаменимым опытом для всех, кто хочет понять, как формировались основы современных графических технологий.
