секреты demo-кодинга

ДМИТРИЙ ГРАМОТЕЕВ

Хакер, номер #075, стр. 078

ПРОГРАММИРОВАНИЕ ДЕМОК: СОВЕТЫ ГУРУ

ДЕМКА - ЭТО ПРОГРАММА, КОТОРАЯ В РЕАЛЬНОМ ВРЕМЕНИ ОСУЩЕСТВЛЯЕТ ПРОРИСОВКУ СЛОЖНЫХ ГЕОМЕТРИЧЕСКИХ И ИНЫХ ГРАФИЧЕСКИХ ФИГУР В УСЛОВИЯХ СТРОГОЙ СИНХРОНИЗАЦИИ С МУЗЫКОЙ, ИСПОЛЬЗУЯ ВЫЧИСЛИТЕЛЬНЫЕ И МУЛЬТИМЕДИЙНЫЕ ВОЗМОЖНОСТИ КОМПЬЮТЕРА. ЗВУЧИТ СЛИШКОМ НАПЫЩЕННО? ТОГДА, ПОЖАЛУЙ, ОСТАНОВИМСЯ НА ТОМ, ЧТО ДЕМКА - ЭТО ПРОСТО ПРОГРАММА

[demo internal mechanics.]

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

Современные демки достигают размеров 20 мегабайт. Спрашивается, а не проще ли перегнать с помощью kkapture все это счастье в такого же размера AVI и смотреть на любом компьютере и в любом разрешении? Ан нет! Ни один из существующих видеокодеков не способен при сопоставимом размере результирующего файла передать попиксельное качество картинки демки. Более того, если позволяют вычислительные мощности, то изображение на экране будет меняться не со скоростью классических AVI’шных 25 кадров в секунду, а со скоростью 100 и даже 200! Да, сам факт осознания того, что все это делается в реальном времени, добавляет демкам стоимости.

[на чем пишутся демки?]

Первый вопрос при написании демо, который встает перед большинством людей, решивших, что им пора написать собственное произведение, – «а на чем это пишется?». Демы пишутся на том языке программирования, который более удобен автору. Чаще всего они пишутся на C\C++ (VC, GNU C). Конечно, не стоит думать, что выбор, доступный программисту, это «C++ or die». Единственный реальный бонус, который получают люди, которые пишут на приплюснутом Си перед другими языками программирования, это то, что примеры из MSDN, Direct-X SDK и море туториалов написаны именно на этом языке. Все остальное - just rumors. Других объективных причин преимущества C\C++ особо и нет. На Delphi, VB или даже на «голом» ассемблере можно написать абсолютно то же самое, а то и что-нибудь покруче (собственно, люди так и поступают :-)).

Еще демки пишутся в демосистемах. Демосистемы – это специализированные программы–оболочки, которые посредством графического интерфейса создают скрипты демок. Такие демо-системы в результате экспортируют исполняемый файл плеера и набор скриптов. Сам скрипт содержит информацию в стиле «что, как и когда показывать» и пользовательские медиаданные. Демосистемы бывают очень разные. Для работы с каждой из них тебе будет необходимо прочитать мануалы и разобраться в туториалах (может, еще не поздно почитать книжку про C++?). С большим отрывом по функциональности и качеству лидирует система Werkkzeug. Просто обалденная штука (при правильном применении =)). Список поддерживаемых фич можно перечислять до конца статьи. От демомейкера не требуется ничего, кроме его креатива. Для оценки масштаба трагедии смотрим потрясающую работу от Farbrausch - fr-025 (на соответствующих картинках).

Между прочим, на сайте WZ именно этот проект лежит в исходниках и полностью доступен для скачивания и «ковыряния»! Полноценные и «съедобные» русскоязычные туториалы по WZ притаились на сайте www.vova4age.narod.ru. Еще одним классическим примером демосистемы является Moppy Demopaja. Но, в отличие от WZ, Demopaja не таскает «все в одном флаконе», и тебе придется пыхтеть и писать специальные плагины для твоих супер-пупер эффектов самому (зато редактор сцен и сплайнов удобный). Кроме этого, советую обратить внимание на демосистему neon v2 от группы xplsv и отечественный opensource проект Plasticator.

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

ПОПУЛЯРНЫЕ ДЕМОТУЛЗЫ

Werkkzeug

http://www.theprodukkt.com/werkkzeug1 - аll-in-one, включая даже средство от комаров

Moppy Demopaja

http://demopaja.org - удобное управление сценами, но халтура не пройдет – все plugin’ы придется написать самому

Neon v2

http://www.neonv2.com - к демосистеме существует большое количество плагинов и эффектов, но другие варианты более гибки и функциональны

Plasticator

http://plasticator.heroez.net - отечественный проект, предлагает очень много и сразу, главное – не запутаться в интерфейсе

[графика.]

Графика в демке может быть растровой и векторной. Растровая графика рисуется в редакторах а-ля Фотошоп, а вот с векторной все несколько сложнее. Для хранения растровой графики любого содержания нам хватит PNG и JPG, а вот форматов векторной графики – тьма, ведь каждый редактор сохраняет ее в своем формате. Стандартом де-факто является 3ds. Для всех остальных «тяжелых случаев» существуют программы-конверторы векторных графических файлов (очень хороший пример – Deep Exploration).

Но это все теория, а на деле матерые демомейкеры частенько брезгуют стандартными форматами, выдумывая свои. И правильно делают! Это позволяет делать код более гибким, использовать легковесный загрузчик и оптимизировать данные под конкретные задачи.

Загрузить растровое или векторное изображение можно с помощью различных библиотек. Как вариант - написать самому, но стоит ли изобретать велосипед? На том же www.sourceforge.net есть множество библиотек для загрузки данных любых форматов. И, вспоминая боянистую фразу на ярлыке мужской рубашки «dry wash only, 40*C, no bleach, inside out, no machine washing – OR – just give it to your wife – it’s her job», все остальное скидываем на художника. Это его работа - рисовать и сохранять в правильный формат. Если будет сопротивляться, то покажи ему, кто в доме хозяин ;).

Вершиной искусства демомейкинга является генерация изображений текстур исключительно посредством кода. Тут речь идет не о простых градиентах с шумом, а именно о сложных изображениях. Остановимся на этом моменте и идем смотреть 64кб интру Fr-08: The Produkkt (соответствующая картинка).

Смотрим до самого конца и внимательно вникаем в цифры в титрах – впечатляет! Разобраться, как работают генераторы текстур, можно на отличном примере проекта Александра Кухаренко (hi, f0x!) - plasticator (http://plasticator.heroez.net). Вообще говоря, этот проект – полноценная отечественная демосистема, на которой были сделаны различные интры и демки, но нас на данной стадии будет интересовать только то, каким образом можно получить сложные рисунки посредством минимума кода. Копаем исходники, крутим кнопки – осознаем how to. Дельфинам, да и остальным, рекомендуется посмотреть интересный проект www.ainc.de – «Texture»

Он также укомплектован сорцами и крайне познавателен. Функциональные возможности, конечно, не фонтан, по сравнению с plasticator, но все более чем съедобно. Использование генерируемых текстур радикально изменяет размер демки на носителе.

[как все это показать на экране?]

Процесс отрисовки картинки на экране называется рендерингом. Рендеринг может быть программный (software) или с помощью средств графических библиотек OpenGL / DirectX (hardware accelerated).

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

Доступ к возможностям видеоускорителя осуществляется через библиотеки OpenGL и DirectX. Возможности последних версий OpenGL и DirectX более чем сравнимы, хотя, с моей точки зрения, DirectX более programmer-friendly. Он поддерживает больше форматов файлов, интерфейсов для структур данных. Доступ к расширенным функциям также значительно проще в DirectX, зато OpenGL является действительно кроссплатформенной библиотекой. Доступ к расширенным функциям видеоускорителя в OpenGL осуществляется через так называемые расширения, что значительно усложняет написание кода. Хотя вру. Не усложняет, а увеличивает количество телодвижений. В минус API OpenGL версий ниже 2.0 идет также отсутствие возможности использования текстур размера, не кратного степени 2. Для любителей «хочу все и сразу» есть такие извращения как SDL (Simple DirectMedia Layer, www.libsdl.org) – кроссплатформенная тулза, позволяющая писать мультимедийные приложения. «Простой доступ к мультимедийным возможностям» обернется для нас необходимостью досконально изучить не только API самого SDL, но и OpenGL и всего остального, поскольку когда-нибудь обязательно захочется разобраться во всем изнутри ;). В такие моменты ты должен держать под рукой книжечку по C++ и OpenGL\DirectX. Выход из ситуации, когда хочется высокого качества картинки, но лениво разбираться в тонкостях низкоуровневых библиотек – сторонние 3D-рендеры. Их очень много и они все очень разные, но, как показывает практика, в большинстве случаев написать собственный движок для демки намного проще и перспективнее, чем тратить время на изучение устройства чужого кода. Так что настоятельно рекомендую тебе писать все свое.

Таким образом, можно выделить три типа рендера – когда код демки не знает, чем его будут отрисовывать и общается только через прослойку графического движка; когда графического движка нет как такового, но есть набор структур данных и мелкие куски кода для работы с ним; и когда весь код прорисовки на уровне API находится прямо в коде демки. Первый способ наиболее правильный с точки зрения программного подхода. Необходима new feature? – добавь означенную фичу в сорцы рендера. Второй способ, когда вызовы API намешаны в коде демки со всем остальным, позволяет значительно ускорить процесс разработки, но требует несколько большей квалификации программиста. Третий способ пригоден только для того, чтобы показать, что он существует и не должен использоваться - сложность разработки, огромный размер исходного кода, – и это только начало внушительного списка его «бонусов».

Графический тулкит любого демомейкера должен включать в себя как минимум документацию и примеры. В дальнейшем ты добавишь в этот список свои наработки, снипетсы и все остальное. Настоящей OpenGL-Меккой стал сайт www.nehe.gamedev.net. Простые и понятные уроки и статьи (с подробным построчным (!) описанием всего чего только можно) радуют уже не первое поколение кодеров, а каждый урок от NeHe можно рассматривать как отдельную мини-демку. Более того, примеры NeHe портированы на большое количество языков программирования. В интернете существует также и русская версия уроков NeHe - http://pmg.org.ru/nehe. Еще рекомендую очень хороший ресурс с мясистым именем хоста - http://ultimategameprogramming.com - сайт содержит действительно много примеров по OpenGL и DirectX. Примеры с UGP более продвинуты, чем на NeHe – есть HDR, различные Shadows-технологии, шейдеры, лайтмапы, загрузка различных файловых форматов, да и культура кода у примеров намного выше. DirectX-разработчикам рекомендуется держать у себя на диске соответствующий SDK, но если в графике ты - начинающий, то разобраться примерах 8-го или 9-го SDK поначалу будет очень сложно.

ГДЕ НАУЧАТ ПРОГРАММИРОВАТЬ ГРАФИКУ?

www.gamedev.ru – общаемся на тему графики на русском языке

www.gamedev.net – то же самое, на английском

www.msdn.microsoft.com - доки по базовому OpenGL

www.openGL.com - более подробные доки с различными примерами

www.delphi3d.net – все для дельфина, плавающего в море графики :)

www.sourceforge.net - не особо удобный проект «GLScene», тоже для любителей Delphi

www.nehe.gamedev.net - на твоем месте, я выкачал бы его весь телепортом. Особенно конкурсные работы

www.ultimategameprogramming.com - его тоже сливать полностью

http://www.sulaco.co.za – еще один нефиговый проект для дельфинов

www.humus.ca - нереально крутые графические примеры с исходными текстами

ПРИМЕРЫ РЕНДЕРОВ

СОФТВАР

MATRIX – THE FULCRUM – ПОТРЯСАЮЩИЙ СОФТВАРНЫЙ РЕНДЕР ОБРАЗЦА КОНЦА 90-Х. ЧУВСТВУЕТСЯ, ЧТО ВОЗМОЖНОСТИ ДЕТАЛИЗАЦИИ ИЗОБРАЖЕНИЯ ДИКТОВАЛИСЬ ЛИШЬ СУЩЕСТВУЮЩИМИ 166MHZ ПНЯМИ. ДИНАМИЧЕСКОЕ ОСВЕЩЕНИЕ, ТЕНИ, ОБЪЕМНЫЙ СВЕТ, АНИМАЦИЯ МОДЕЛЕЙ – И ВСЕ ЭТО СЧИТАЕТСЯ ТОЛЬКО НА ПРОЦЕССОРЕ!

РЭЙТРЕЙСЕР

FAN - STILL SUCKING NATURE – ГОД ВЫПУСКА 2003, НО ДАЖЕ СЕЙЧАС ЭТО НЕЧТО! В ИНФОРМАЦИИ ПО ПРОЕКТУ СОЗДАТЕЛИ УТВЕРЖДАЮТ, ЧТО ПЫТАЛИСЬ СДЕЛАТЬ ИМЕННО ФОТОРЕАЛИСТИЧНУЮ КАРТИНКУ В РЕАЛЬНОМ ВРЕМЕНИ.

ХАРДВАР

RGBA – PARADISE, ПРОСТО КРАСИВАЯ НЕБОЛЬШАЯ ИНТРА С ПОЧТИ ЖИВОЙ ТРАВОЙ И НАСТОЯЩИМИ НОСОРОГАМИ! ВСЕГО ЛИШЬ 56 КБ!

[музыка.]

Дема без музыки это... полный бред! Сейчас мы рассмотрим, как хранить музыку, чем ее играть и вообще, зачем это все надо.

Технологически музыка в демках бывает MIDI, модульная, синтезированная или потоковая. MIDI-формат - он и в Африке MIDI. В демках он используется в чистом виде крайне редко. Учитывая, что есть много юолее эффективных способов, советую забыть про него вообще. Не стоит, конечно, тут опускать MIDI до уровня грязи, это всего лишь формат файла и его можно проиграть через очень навороченный синтезатор, получив таким образом потрясный саунд. Но для демомейкинга он не подходит :). Исторически первым типом музыки в демках были музыкальные модули. Модуль - это файл, который хранит внутри себя образцы звуков инструментов (сэмплы) и ноты, которые необходимо сыграть этими инструментами. Модули создавались в специальных программах – треккерах. Треккер представляет собой программу, в которой можно редактировать модули в виде вертикальных дорожек с нотами (паттернов) и осуществлять управление сэмпламии и эффектами.

Классический модульный формат это MOD: монофонические сэмплы по 8 бит и возможность воспроизвести максимум 4 звука одновременно. Современные модульные форматы позволяют практически забыть о таких рудиментарных ограничениях параметров сэмплов и количества воспроизводимых одновременно каналов. Модульная музыка позволяет получить высокое качество звучания (даже выше чем mp3-style форматах). Смотрим и внимательно слушаем качество саундрека в демках с модульной музыкой: Haujobb – disclone и «наш» ответ буржуям: T-Rex – broadband. Наиболее распространены у демомейкеров следующие форматы модульной музыки: IT – Impulse Tracker v2.14, XM – FastTracker 2. Обе программы еще DOS’овских времен, хотя есть и win+linux клоны для IT – Schism tracker, для XM – Fast Tracker 3. Типичный размер музыкального модуля 200-2000 Кб.

Тем временем мощности компьютеров росли (и растут) постоянно. Кто-то сказал: «А почему бы и нет?» и сделал синтезатор для ПК. Синтезатор генерирует огибающие по некоторым законам и применяет к ним различные фильтры, дэлэи и эффекты.

В демке тебе будет необходимо хранить код самого синтезатора (плеера) и набор параметров к нему. Это хозяйство занимает очень мало места, что нам, безусловно, на руку. Синтезатор позволяет получить исключительно высокое качество звука, но требует значительных вычислительных ресурсов (фразу после запятой в 21 веке принято опускать, да и никто не отменял prerendering). Для тех, кто не верит в качество синтезаторов, - качаем и слушаем демки: Farbrausch – fr-34, AOS – offworld (между прочим, работа-победитель демопати CC-2006 в Питере, hi to Preston & UNC!). Подробное описание работы музыкального синтезатора явно выходит за рамки этой статьи, да и рассказывать об этом должны люди, которые сами писали синтезаторы, так что ищем все в интернете. Ну и завершают разнообразие форматов музыки в демках потоковые форматы: mp3, ogg, wma. Что именно выбрать – решать исключительно тебе. В абсолютном большинстве современных демок используется потоковый формат музыки. Так быстрее, удобнее и никто не украдет сэмплов из наших модулей :). Ударить по звуковым рецепторам помогут саундтреки из демок: mfx – deiteies, kewlers – a significant deformation near the cranium.

В воспроизведении саундтрека нет ничего сложного. Конечно, самые смелые и опытные программеры пишут все сами, но нет ничего зазорного в использовании качественных сторонних инструментов. Наиболее распространены библиотеки Bass (кстати, эту библиотеку я когда-то описывал на страницах Кодинга - прим. Лозовского) от Ian Luck и fMod от Firelight multimedia. Обе абсолютно бесплатны для некоммерческих приложений и предлагают в целом одинаковый набор функций. В этих библиотеках есть врапперы под все основные языки программирования и платформы. Используя эти библиотеки, ты легко проиграешь свои модули или mp3’шки даже не задумываясь о том, какой звуковой адаптер у тебя стоит. Дополнительно bass поддерживает компрессированные с помощью технологии mpeg музыкальные модули MO3, а fmod мне нравится по причине простоты синхронизации. Кроме того, есть версия MiniFMod, которая используется для проигрывания модулей в малоразмерных демках и интрах с синтезированными сэмплами. А вот с «чистыми» синтезаторами сложнее. В разделе demotools на www.pouet.net есть public-синтезаторы, но они все очень разные и перед реальным использованием придется их досконально изучать.

Преимущества и недостатки звуковых форматов

МОДУЛЬ

(+) ЗАНИМАЕТ МАЛО МЕСТА. НЕ ТРЕБУЕТ ВЫСОКИХ ВЫЧИСЛИТЕЛЬНЫХ МОЩНОСТЕЙ

(-) ПОДХОДИТ ТОЛЬКО ДЛЯ ЧИСТОЙ МУЗЫКИ

ПОТОК

(+) ЛЮБОЕ СОДЕРЖАНИЕ, ХОТЬ 10-МИНУТНАЯ ЗАПИСЬ ЧИХАЮЩЕЙ БОЛЬНОЙ ОБЕЗЬЯНЫ. НЕ ТРЕБОВАТЕЛЕН К ВЫЧИСЛИТЕЛЬНЫМ РЕСУРСАМ И ПАМЯТИ

(-) ВЫСОКОЕ КАЧЕСТВО – БОЛЬШОЙ РАЗМЕР ФАЙЛА

СИНТЕЗАТОР

(+) ИСКЛЮЧИТЕЛЬНОЕ КАЧЕСТВО ЗВУКА, ЕСЛИ РУКИ НЕ КРИВЫЕ

(-) СЛОЖНОСТЬ РЕАЛИЗАЦИИ И ЗНАЧИТЕЛЬНО БОЛЕЕ ВЫСОКИЕ СИСТЕМНЫЕ ТРЕБОВАНИЯ

[как все это вместе работает?]

Сейчас я попробую рассказать о том, как работает generic-демка на функциональном уровне. По ходу объяснения у меня будет появляться желание писать сразу куски кода, но я переборю себя и попробую объяснить взаимодействие различных элементов демки на уровень выше, а конкретные примеры реализаций ты подсмотришь сам из примеров NeHe. Для начала – посмотри на картинку «Схема реализации».

Все начинается с инициализации графической подсистемы. Можно сначала загрузить данные, но как ты тогда нарисуешь красивый progressbar? Поэтому будем последовательны. Хорошим тоном является предоставление пользователю возможности до запуска демки выбрать хотя бы разрешение экрана. Как вариант можно сделать отдельный конфигуратор (отдельная программа), а демка будет уже запускаться по активным настройкам. Если ты пишешь 64К или просто ленив, как сытая анаконда, то скомпилируй несколько .exe с различными настройками. Например, demo_fullscreen.exe и demo_window.exe. Однако что-то мы отошли от сути.

При инициализации обязательно смотри на коды возврата ошибок. Лучше определить возможности системы пользователя заранее, чем заставлять его ждать процесса загрузки и первого «вываливания» по ошибке. Для OpenGL самая ответственная часть – это выбор pixelformat. Также подводный камень можно найти при установке полноэкранного видеорежима – не стоит прыгать в видеорежим с custom framerate. Переключайся на любой доступный режим с данным разрешением. Проще говоря – не надо 640x480@100, надо 640x480@default.

Следующий шаг – загрузка данных. Данные можно хранить в отдельных файлах, в больших single-file паках, в .exe-ресурсах или даже в сегменте кода. Как именно – решать тебе. Если хранить внутри .exe, то не надо думать насчет упаковки – всегда есть UPX или ASPack. Хорошим решением является хранение данных в популярных архивных форматах ZIP, RAR. В таком случае тебе понадобится соответствующая библиотека декомрессии. Как пример можно привести unique – unRar library (http://www.unrarlib.org). Должен сразу предупредить тебя, что делать временные файлы при распаковке и загрузке демки - это страшное зло. Хотя, если ты культурно получишь системный temporary file, то... нет, все равно зло. Наша демка должна распаковывать все сразу в память, так, чтобы ее можно было безболезненно запускать даже с компакт-диска.

Следующий элемент - чаще всего, самый сложный для новичков. Перед тем как начинать писать свою демку, я настоятельно рекомендую тебе попробовать написать тетрис (через это должен пройти каждый программист :) – прим. Лозовского). Да-да, именно обыкновенный тетрис. Очень много схожих элементов, да и опыта программирования это добавит. Я серьезно! Отмазки в стиле «я работаю только с базами данных, зачем мне этот тетрис?» плохо скрывают то, что человек на самом деле даже не представляет, как это делается. Позволю себе и тут ввернуть несколько полезных советов.

В начале каждого нового кадра мы должны узнать текущее время от начала проигрывания музыки. Если ты используешь fMod, то он может отдать нам текущее время в проигрываемом файле, для других случаев надо использовать gettickcount или QueryPerfomanceTimer с учетом стартового тика. Точность Gettickcount плавает от системы к системе в злом диапазоне до 10 м, что представляет собой максимум 100FPS, а RTDS не поддерживается на процессорах ниже iP3, да и на ноутбучных мобильных камешках частенько отмачивает еще те приколы.

Далее мы находим ту сцену, которая должна быть видна в конкретный момент времени и рисуем ее. Обрати внимание, что наиболее удобно вызывать сцену в ее локальном времени. Например, время на начало кадра - 13.5 секунды, а сцена должна идти с 10-й секунды по 15-ю. Итого: мы передаем этой сцене значение времени в интервале от 0 до 1, - для данного примера это будет (13.5-10)/(15-10)=0,7. Использование нормализированного локального времени очень удобно. Дальше – больше! (в прямом смысле). Если делать плавные переходы между сценами или «месиво» из нескольких сцен, то необходим дополнительный менеджер сцен или виртуальная сцена, которая ничего не будет делать, кроме как вызывать из себя прорисовку других сцен и смешивать результат, а в самом конце этого элемента можно сделать итоговый постпроцессинг, например, модный нынче glow\bloom. Далее - быстренько смотрим, нажал ли мерзкий юзер клавишу Еsc, и не закончилась ли еще музыка. Если нет – повторяем весь цикл отрисовки кадра.

А для того, чтобы оставить хорошее впечатление от просмотра и при этом не оставить «хвостов» в памяти – аккуратно убираем за собой, хотя если «бросить» девайсы, контексты и текстуры в D3D или OpenGL – то ничего страшного не случится. Но будем культурнее :). Хотя бы чуть-чуть.

[сonclusion или несколько слов вдогонку уходящему поезду.]

Так уж получилось, что наше описание внутренностей демки вышло достаточно сумбурным, в стиле «галопом-по-Европам». Но не боги горшки обжигают, да и демки, пусть даже самые крутые, делают самые обыкновенные талантливые люди. Даже если ты не программист и не представляешь в деталях how does it work – ничего страшного: есть различные демосистемы, где от тебя будет требоваться только креатив и клики мышкой в нужных местах. Главное – это желание творить. А статья, в которой я самым подробным образом разберу программирование демки, ждет тебя в этом же номере. Кстати, менее чем полгода отделяет нас от ближайших российских демопати: DiHalt в Нижем и ChaosConstructions в Питере...

ГДЕ ПОКАЗАТЬ СЕБЯ И ПОСМОТРЕТЬ НА ДРУГИХ?

WWW.CC6.ORG.RU – КРУПНЕЙШЕЕ ОТЕЧЕСТВЕННОЕ ДЕМОПАТИ! ЕЖЕГОДНО ПРОХОДИТ В ПИТЕРЕ - НЕ ЛЕНИМСЯ, ДЕЛАЕМ И ПРИСЫЛАЕМ СЮДА РАБОТЫ.

WWW.POUET.NET – КРУПНЕЙШИЙ РЕСУРС С ДЕМКАМИ В СЕТИ. СКРИНШОТЫ, РЕЙТИНГИ, ОПИСАНИЯ, СИСТЕМА ПОИСКА: САМЫЕ СВЕЖИЕ И САМЫЕ ДРЕВНИЕ РАБОТЫ НАХОДЯТСЯ ТУТ.

WWW.DEMOSCENE.RU – РУССКОЯЗЫЧНЫЙ РЕСУРС, БЕРЕЖНО ХРАНЯЩИЙ КОЛЛЕКЦИЮ ЛУЧШИХ ДЕМОСЦЕНИЧЕСКИХ РАБОТ.

HTTP://WWW.HUGI.SCENE.ORG – ЭЛЕКТРОННЫЙ ЖУРНАЛ HUGI. НА ЕГО СТРАНИЦАХ ЧАСТЕНЬКО ВСТРЕЧАЮТСЯ СТАТЬИ ПО ПРОГРАММИРОВАНИЮ И ВООБЩЕ ВСЕМУ, ЧТО СВЯЗАНО С СОЗДАНИЕМ ДЕМОК. ЕСТЬ ДАЖЕ РУССКИЕ ВЕРСИИ.

ВЕСЬ СТАФФ И ДЕМКИ К ЭТОЙ СТАТЬЕ ЖДУТ ТЕБЯ НА НАШЕМ КОМПАКТ-ДИСКЕ