ironpeter

Прощайте, скалистые горы

Sun, 05 Jul 2009 17:11:02 GMT

Из-за общей бурности жизни решил распрощаться со старой работой. Работалось в "Нивал Онлайн" долго и плодотворно, спасибо всем.

О решении уйти я вроде пока не жалею - перспективы открываются разные, заманчивые.

Если есть желание меня нанять ( очень желательная Москва ), то пишите на IronSPeter 'at' gmail.com

Вот собственно и все. До новых встреч.

Фрактальный оркестр.

Mon, 04 Jun 2007 06:26:32 GMT

--Архитектура - это застывшая музыка ( не помню кто, кажется, Гете ).
--Хороший код - фрактальный код ( наш aruslan ).

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

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

Итак, коротенько про SPU, эти "синергетические процессорные устройства". Имеют эти устройства локальную память в 256K, все операции производятся над ней. Можно инициировать DMA - запрос. Попросить скопировать из основной памяти кусок, или залить в нее. С каждым DMA запросом можно ассоциировать тег и следить за выполнением запроса. На лету может быть несколько запросов. Имеется 128 регистров ширины 128 бит. Имеются четные и нечетные команды. Четные команды - это булевая, целочисленная и плавучая арифметика. Нечетные команды - загрузка, выгрузка и замечательная команда перемешивания двух регистров - shuffle. За такт может быть выполнена одна четная, одна нечетная команда.
Правые и левые NOPы прилагаются, кстати - для просветленных.

Команда shuffle на самом деле является центральным местом всей архитектуры. А делает она очень простую вещь - по двум регистрам ( суммарно 32 байта ) составляет регистр ( 16 байт ), составленный из перемешанных в произвольном порядке произвольных байтов исходных регистров. Я повторяю - произвольном порядке. Как только есть произвольные перестановки байт - в коде появляется постоянные игры с SOA и AOS подходом. Байты перекидиваются туда-сюда, как мячики дрессированными тюленями в цирке.

Вполне себе рабочая задача - есть массив vec_float4, которые символизируют собой вершины сетки. Есть второй массив - просто массив байт, каждые три байта - индекс треугольника. Надо умножить вершины на матрицу преобразования, для каждого треугольника определить ориентацию, сложить прореженные вершины и индексы последовательно в другие массивы. Такой софтверный back face cull.

Чтобы работать с треугольниками, надо превратить индексы в что-то посущественнее байта. Скажем, превратить голые последовательные 48 байт в 16 треугольников ( содержимое регистра: 3 int индекса, четвертый элемент 0 ). Примерно таким образом, извиняюсь за интимные детали:


#define C8_0       0x80, 0x80, 0x80, 0x00
#define C8_1       0x80, 0x80, 0x80, 0x01
#define C8_2       0x80, 0x80, 0x80, 0x02
#define C8_3       0x80, 0x80, 0x80, 0x03
#define C8_4       0x80, 0x80, 0x80, 0x04
#define C8_5       0x80, 0x80, 0x80, 0x05
#define C8_6       0x80, 0x80, 0x80, 0x06
#define C8_7       0x80, 0x80, 0x80, 0x07
#define C8_8       0x80, 0x80, 0x80, 0x08
#define C8_9       0x80, 0x80, 0x80, 0x09
#define C8_A       0x80, 0x80, 0x80, 0x0A
#define C8_B       0x80, 0x80, 0x80, 0x0B
#define C8_C       0x80, 0x80, 0x80, 0x0C
#define C8_D       0x80, 0x80, 0x80, 0x0D
#define C8_E       0x80, 0x80, 0x80, 0x0E
#define C8_F       0x80, 0x80, 0x80, 0x0F

#define N8_0       0x80, 0x80, 0x80, 0x10
#define N8_1       0x80, 0x80, 0x80, 0x11
#define N8_2       0x80, 0x80, 0x80, 0x12
#define N8_3       0x80, 0x80, 0x80, 0x13
#define N8_4       0x80, 0x80, 0x80, 0x14
#define N8_5       0x80, 0x80, 0x80, 0x15
#define N8_6       0x80, 0x80, 0x80, 0x16
#define N8_7       0x80, 0x80, 0x80, 0x17
#define N8_8       0x80, 0x80, 0x80, 0x18
#define N8_9       0x80, 0x80, 0x80, 0x19
#define N8_A       0x80, 0x80, 0x80, 0x1A
#define N8_B       0x80, 0x80, 0x80, 0x1B
#define N8_C       0x80, 0x80, 0x80, 0x1C
#define N8_D       0x80, 0x80, 0x80, 0x1D
#define N8_E       0x80, 0x80, 0x80, 0x1E
#define N8_F       0x80, 0x80, 0x80, 0x1F

#define E4  0x80, 0x80, 0x80, 0x80

tw0_0 = (qword)spu_shuffle( t1, t1, SWZ{ C8_0, C8_1, C8_2, E4 } );
tw1_0 = (qword)spu_shuffle( t1, t1, SWZ{ C8_3, C8_4, C8_5, E4 } );
tw2_0 = (qword)spu_shuffle( t1, t1, SWZ{ C8_6, C8_7, C8_8, E4 } );
tw3_0 = (qword)spu_shuffle( t1, t1, SWZ{ C8_9, C8_A, C8_B, E4 } );
        
tw0_1 = (qword)spu_shuffle( t1, t1, SWZ{ C8_C, C8_D, C8_E, E4 } );
tw1_1 = (qword)spu_shuffle( t1, t2, SWZ{ C8_F, N8_0, N8_1, E4 } );
tw2_1 = (qword)spu_shuffle( t2, t2, SWZ{ C8_2, C8_3, C8_4, E4 } );
tw3_1 = (qword)spu_shuffle( t2, t2, SWZ{ C8_5, C8_6, C8_7, E4 } );
        
tw0_2 = (qword)spu_shuffle( t2, t2, SWZ{ C8_8, C8_9, C8_A, E4 } );
tw1_2 = (qword)spu_shuffle( t2, t2, SWZ{ C8_B, C8_C, C8_D, E4 } );
tw2_2 = (qword)spu_shuffle( t2, t3, SWZ{ C8_E, C8_F, N8_0, E4 } );
tw3_2 = (qword)spu_shuffle( t3, t3, SWZ{ C8_1, C8_2, C8_3, E4 } );
        
tw0_3 = (qword)spu_shuffle( t3, t3, SWZ{ C8_4, C8_5, C8_6, E4 } );
tw1_3 = (qword)spu_shuffle( t3, t3, SWZ{ C8_7, C8_8, C8_9, E4 } );
tw2_3 = (qword)spu_shuffle( t3, t3, SWZ{ C8_A, C8_B, C8_C, E4 } );
tw3_3 = (qword)spu_shuffle( t3, t3, SWZ{ C8_D, C8_E, C8_F, E4 } );

Магическое число 16 тут возникает вполне естественно, треугольников именно 16, потому что 48 это наименьшее общее кратное 16 и 3.
Для каждого из треугольников надо прочитать 3 вершины, определить ориентацию. Математика тут очень простая и работает почти вся со скалярными операциями. Неминуемо логика кода повелевает обрабатывать треугольники четверками. И проводить вычисления вот в таком стиле:


static vec_float4 inline  Cross(
    const vec_float4 &ax,
    const vec_float4 &bx,
    const vec_float4 &cx,
    const vec_float4 &ay,
    const vec_float4 &by,
    const vec_float4 &cy )
{
    vec_float4 abx = spu_sub( ax, bx );
    vec_float4 aby = spu_sub( ay, by );
    vec_float4 acx = spu_sub( ax, cx );
    vec_float4 acy = spu_sub( ay, cy );
    return spu_msub( abx, acy, spu_mul( aby, acx ) );
}

Замечаете страшное? Я замечаю. Латентность команд от двух до шести тактов, эти вычисления банально провисают, они слишком зависимы. Неминуемо надо выполнять несколько таких функций Cross параллельно.
Желательно не меньше четыре. Я наивный и верю компилятору, что 4 последовательных вызова функции Cross с независимыми параметрами довольно удачно разведутся по латентностям. Японцы наверняка ( и примкнувший к ним Боря ) фыркнут на мое "Я наивный и верю компилятору". У них все правильно, на ассемблере. С четными и нечетными командами рядом. И несколькими столбиками паралелльных вычислений.

Помните мега-тред на gamedev.ru про параллельное программирование? См. http://www.gamedev.ru/code/forum/?id=19939&page=2. Вот идеология параллельного программирования в действии:


//переменные для четверки треугольников
#define VARS( X )\
        vec_float4 a0##X, a1##X, a2##X, a3##X;\
        vec_float4 b0##X, b1##X, b2##X, b3##X;\
        vec_float4 c0##X, c1##X, c2##X, c3##X;\
        vec_float4 ax##X, bx##X, cx##X;\
        vec_float4 ay##X, by##X, cy##X;\
        vec_float4 c##X;

//Загрузка 3 вершин для каждого треугольника
#define PREP( X )\
    Prepare( tw0##X, tw1##X, tw2##X, tw3##X, v, a0##X, a1##X, a2##X, a3##X, b0##X, b1##X, b2##X, b3##X, c0##X, c1##X, c2##X, c3##X );

//формирование SOA векторов
#define XY( S, X )\
  ConvertXY( S##0##X, S##1##X, S##2##X, S##3##X, S##x##X, S##y##X );

//вычисление ориентации для 4 треугольников сразу.
#define CRS( X )\
  c##X = Cross( ax##X, bx##X, cx##X, ay##X, by##X, cy##X );

//сброс треугольников с нужной ориентацией в буфер
#define DMP( X )\
  Dump( tw0##X, tw1##X, tw2##X, tw3##X, c##X, t );

        VARS( _0 )  VARS( _1 )  VARS( _2 )  VARS( _3 );
        PREP( _0 )  PREP( _1 )  PREP( _1 )  PREP( _3 );
        XY( a, _0 ) XY( a, _1 ) XY( a, _2 ) XY( a, _3 );
        XY( b, _0 ) XY( b, _1 ) XY( b, _2 ) XY( b, _3 );
        XY( c, _0 ) XY( c, _1 ) XY( c, _2 ) XY( c, _3 );        
        CRS( _0 )   CRS( _1 )   CRS( _2 )   CRS( _3 );
        DMP( _0 )   DMP( _1 )   DMP( _2 )   DMP( _3 );

А вот переход от параллельного программирования к диагональному, самое сердце кода:



        VARS( _0 );
        PREP( _0 )  VARS( _1 );
        XY( a, _0 ) PREP( _1 )  VARS( _2 );
        XY( b, _0 ) XY( a, _1 ) PREP( _2 )  VARS( _3 );
        XY( c, _0 ) XY( b, _1 ) XY( a, _2 ) PREP( _3 );
        CRS( _0 )   XY( c, _1 ) XY( b, _2 ) XY( a, _3 );
        DMP( _0 )   CRS( _1 )   XY( c, _2 ) XY( b, _3 );
        /*      */  DMP( _1 )   CRS( _2 )   XY( c, _3 );
        /*      */              DMP( _2 )   CRS( _3 );
        /*      */                          DMP( _3 );

Столбики являются слабо зависимыми друг от друга, так что они могут быть смещены "по высоте" произвольно. Но такой порядок понравился компилятору сильнее всего.
Наверное потому, что в функции DMP происходит инкрементация буфера для записи треугольников ( тех которые с правильной ориентацией ). Эти вызовы DMP ( X ) зависимы друг от друга. И компилятор не смог провести глобальную оптимизацию кода, лишь чуть пошевелив порядок команд. Кроме того, в разнородных функциях встречаются разнородные четные и нечетные команды, которые компилятор смог эффективно спарить. Наличие четных и нечетных задач сыграло тогда, когда мы стали работать с масштабами кода в сотни команд - сотни тактов.

Следующий уровень детализации фрактала - это цикл, тело кторого приведено выше. Цикл, каждая итерация которого обрабатывает по 16 треугольников. При характерных размерах батча геометрии в 256 треугольников у нас будет порядка 16 итераций. Число 256 тоже не взято с потолка. Оно гармонично и прекрасно. Если у нас 256 треугольников, то DMA запросы будут выкачивать порядка килобайта данных. Этот тот размер DMA пакета, начиная с которого скорость трансфера выходит на плато.

Следующий уровень фрактала виден достаточно отчетливо. На финальном коде вычисления занимают на 256 треугольниках примерно 1.6e-6 секунды. DMA трансферы ( входящие и исходящие ) занимают меньше, порядка 1.0e-6, но число того же порядка. Надо завести две копии рабочих данных - в одну стриммим DMA, во второй считаем, код заиграет новыми красками на модельках по несколько тысяч треугольников. Смотрите, какая прекрасная аналогия с четными и нечетными командами.

Следующий уровень фрактала - понятие "задача" для spu. Код в SPU можно заливать DMA трансфером, но кажется более разумным на запущенном spe потоке выполнять много однотипных работ. Много моделек по много кластеров каждая. Естественно, у меня в тестах этого уровня абстракции нету. А вот в реальной игре - будет, да еще как будет.

Посмотрите на всю структуру кода-фрактала. Снизу свою волю диктует SIMD архитектура ( масштаб одного такта ), спаривание четных и нечетных команд ( масштаб пары операций ), латентность команды ( масштаб 2-6 операций ), чуть выше - циклы и условные переходы ( масштаб 20 тактов простоя на условном переходе ), посередине обосновались DMA - трансферы с характерными размерами 1 килобайт, сверху - уровень однотипных задач для "spu".

Низкоуровневый код весь пронизан духом SOA-AOS преобразования. Вершины, скажем, до DMA трансфера хранятся в виде SOA, на матрицу умножаются в таком же виде, потом сохраняются в AOS виде для индесного доступа, потом в коде обработки треугольников их x y компоненты снова ложатся лежа в регистры по четыре штуки. Куда там cuda c ее фиксированными SIMD линейками ( наверняка они и не линейки вовсе на самом низком уровне ).

Итоговая скорость - чуть меньше 200 миллионов треугольников ( половина приняты, половина отброшены ) в секунду на одном SPU. Одном из 6 доступных. Задача простая, но, скажем, наличие скелетной анимации не сильно бы понизило скорость.

Пишешь такой код и проникаешься ненавистью к графическому конвееру в общем и придуманной за тебя функции DIP в частности. Не так надо, не так...

Гайдзинам с любовью. Сони.

Fri, 04 May 2007 08:27:15 GMT

Купил на днях чудо-приставку PS3. Приставка просто так не включается, нужен монитор с поддержкой HDCP. На агрегат с поддержкой 1080p любви к Сони у меня не хватило, приобрел "простенький" 22 дюймовый монитор с поддержкой 720p.

Встроенная Game OS в русской транскрипции забавна. "Отформатировать утилиту" - "Format Utility". Заставка могильного цвета - говорят, что ее цвет зависит от месяца. Хочу зелененькую. Или желтенькую. Или синенькую - по желанию, а не в зависимости от фазы луны. Тормозит. Впрочем, эта самая Game OS была мне плоско-параллельна. Только для того, чтобы установить linux bootloader.

Дистрибутив YDL установился как легкий ветерок. Как обычно, совершил ужасную ошибку - выбрал русский язык в качестве системного. Каждый раз, когда ставлю новый дистрибутив, зачем-то делаю так. Раскаиваюсь, конечно, но поздно. В этот раз почти все шрифты отображались. Где-то половина, остальные - квадратиками. Это безусловный прогресс по сравнению с предыдущими наблюдениями.

Шаловливые ручки сразу потянулись к libspe. Пример почти сразу откомпилировался и заработал. За вычетом грустных нубовских ошибок. Ну там пробелы в makefile вместо tabs. Ну там некратный 16 размер DMA пакета для посылки на SPU - bus error. Ну там функция clock() не работала, выдавала константный 0 - в ответ я заюзал функцию spu_read(write)_decrementer ( пример найден на блоге японского товарища на японском языке ) и получил счастье.

Хотелось peak, то есть - сияющих высот. Естественно, на стандартной задаче - умножении матриц. Пик тут простой - simd float4 fmad на SPU за такт ( 8 flops ). На одном SPU должно получиться 24 гигафлопа. Параллельно с multiply-add может запускаться load-store.

Сишный вариант не зажог, до гигафлопа не дотянул. Я не растерялся, взял интринсики.

vec_float4 *a = &pd.a;
vec_float4 *b = &pd.b;

for( i = 0; i < 256; i += 4 )
{
r0 += a[i] * b[i] +
a[i + 1] * b[i + 1] +
a[i + 2] * b[i + 2] +
a[i + 3] * b[i + 3];
}

Посчитал в уме, что код будет давать 12 гигафлоп, потому что темп загрузки-выгрузки двойной по сравнению с математикой. Откомпилировал (-O3), запустил: 3.2 гигафлопа. Смотрю листинг:

http://rafb.net/p/BQMhrV71.html

Вижу страшное. Обратите внимание на блок fma в конце. Зависимая цепочка - команды встали "друг над другом". Вместо одного такта - 6 каждая. Установка скобочек ( + ) + ( + ) в коде помогла чуть. И по мелочевке - левые и правые команды не захотели спариться. "Я тогда цежу сквозь зубы, но уже конечно грубо..." Написал

for( i = 0; i < 256; i += 4 )
{
r0 += a[i] * b[i];
r1 += a[i + 1] * b[i + 1];
r2 += a[i + 2] * b[i + 2];
r3 += a[i + 3] * b[i + 3];
}

Стало маргинально лучше, но команды все равно не спаривались.

Почесал нос. Вспомнил, как консольные люди говорили мне: "прежде всего, макроассемблер с удобной подсветкой синтаксиса захочешь ты"... Макроассемблер с удобной подсветкой синтаксиса нужен мне, да.

Засыпал, думал, что удобного языка для написания под SPU не придумали еще. Хочется писать симпатичный код вроде

foreach( object in sceneObjects | IsIn( object->GetBoundingBox(), cameraFrustrum ) )object->Draw();

Хочется счастья - в функции не задумываться о том, что происходит на нижних уровнях. Хочется, чтобы этот самый foreach генерировал серию DMA запросов на код виртуальных функций и на данные. Параллельно обрабатывал.

Функция становится объектом неминуемо. Контекст работы функции - тоже объект. Получается какой-то функциональный язык с императивным подъязыком. Сразу хочется GC и компактификации в пределах SPU local storage.

Если мир Haskell и мир макроассемблера встретится - будет счастье на SPU. "Покамест лес Бирнамский не двинулся на Дунсинанский холм, мне страх неведом."

Денарий Гордиана III

Thu, 26 Apr 2007 07:44:24 GMT

Рим, примерно 250 год нашей эры. Прошло немногим больше двухсот лет с момента казни Иисуса Христа. Сменяющие друг друга императоры печатают монету для оплаты легионов.
Первоначально серебряный денарий теперь отливается из сплава меди и серебра. Потом он станет медным, а после бронзовым и выйдет из обихода. Но пока - 4 грамма, половина серебра.

Годовое жалование легионера - 300 денариев. Исходя из современных 15000 долларов годового денежного довольствия рядового американской армии можно примерно вывести современный денежный эквивалент этой монетки - 50 долларов.

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

Практическая сторона вопроса состоит в том, что за почти две тысячи лет денарий не потерял, но и не приобрел покупательной способности. И монетка стоит примерно те же 50 долларов на аукционе.

Риски программиста

Wed, 28 Mar 2007 06:45:53 GMT

Лежал в постели, пытался заснуть. Похоже, температурил. Внезапно в памяти всплыла фраза из TDD Пятых Героев: "А риски многопользовательской разработки будут сняты внедрением системы чекина-чекаута для SQL базы данных". Неожиданно картинка моего прихода в Нивал всплыла с необыкновенной яркостью. Почти как сон Кольриджа:

В стране Ксанад благословенной
Дворец построил Кубла Хан,
Где Альф бежит, поток священный,
Сквозь мглу пещер гигантских, пенный,
Впадает в сонный океан.

Рассказываю. Есть SQL база, в ней дохрена табличек. Каждому игровому типу соответствует своя табличка. Массивам-членам класса тоже соответствует своя табличка и чтобы этот массив получить, надо сказать SELECT BY PARENT_ID. Над этим висит xsd схема, управляет структурой базы. Из схемы генерится C++ код для классов. Схема же используется в редакторе, который показывает такой симпатичный property view прямо из базы данных.

Шоколадно? Да, только игра не умеет читать SQL базу напрямую. А читает она бинарный дамп. Который генерится из базы такой мощной сериализацией всего. Ну, скажем, 30 минут. На 10 процентах ассетов в игре.

Шоколадно? Да, только предполагается, что человек по жизни отконнекчен от материнской базы данных. У него есть опорная база, которая представляет собой срез материнской базы данных. И рабочая база данных. Когда человек хочет залить свои изменения, волшебным образом считается diff между опорной базой данных и рабочей. И применяется к материнской базе данных. Ух, как круто! Представляете, как считать diff в условиях того, что

a) схема базы постоянно меняется.
b) объекты имеют интовые идентификаторы, которые генерируются децентрализованно. И постоянно конфликтуют.

Сюда надо добавить такие мелочи вроде концептуального отличия std::vector от неупорядоченной коллекции, которой представлены массивы в SQL базе.

Сюда добавить то, что бинарные файлы хранятся таки не как блобы, а как файлики на диске. И их тоже надо синхронизировать.

Зачем такое надо? Говорили, что надо аутсорсерам. Да вот только заводить игровые ассеты аутсорсеры не будут никогда,
выложат готовые майские сцены и текстуры на ftp - и апгемахт. А абстракция для карты как файлика на диске перебивает абстракцию 100+ записей в 100+ табличках огромной базы данных, hardwired by keys.

Стоит ли говорить, что когда rate чекинов в эту базу данных повышался до 10 в день, то все переставало работать? Центральная база раздалбывалась в хлам, а у клиентов ( которые ждали очереди на заливку своего diff часами ) тупо горело рабочее время.

Лежал я в постели и вспоминал такое. Думалось, что Large Scale Design - искусство. И что для программиста необходимо чувство a'la музыкальный слух. Чтобы стукнуть камертоном по концепции - и слышать. Отзовется она нежным звонким звуком или станет надтреснуто дребезжать.

Еще я ненавижу общие концепции. Когда вроде умные люди спрашивают "а подумай, как расширить свой код, мы его может заюзаем" - я плююсь.

Наш человек на Олимпе.

Fri, 15 Dec 2006 09:30:14 GMT

Вот, голосование идет.

http://community.livejournal.com/rykov_premia/9040.html

Голосуйте за Руслана, он осознал, что код - это всего лишь застывшая музыка. Не более, но и не менее. Музыку надо уметь слушать, это сложно.

И дело не в пунктах стандарта С++, дело в ясном созерцании и абсолютном музыкальном слухе.

Пусть на Олимпе будет он.

Корпоративная вечеринка и судьбы русской интеллигенции

Thu, 14 Dec 2006 12:54:36 GMT

Вчера была устроена вечеринка по случаю десятилетия компании Нивал. Устроена в длинном как сосика подвале, замаскированном под ночной клуб. В подвале было очень некомфортно. По мозгам била музыка, людей набилось как сельдей в бочке, жратвы - кукиш. Голые девочки ( и полуголые мальчики в рваной джинсе - на любителя ) радовали взгляд, но не настолько, чтобы оставаться на празднике.

Шел из клуба, весь рефлексировал ( как и положено русскому интеллигенту в пятом поколении ). Ах, как плохо устроили вечеринку! Смаковал, как буду повествовать в своем ЖЖ об отвратительной корпоративной вечеринке. Как расскажу всему миру про непотребство.

В метро - инвалид без рук, он ходит между по вагонам, побирается. Вышел на перрон, попросил меня набрать ему номер на сотовом и приложить ему к уху ( рук нету, без них с телефоном не управишься ). Я минут пять понабирал номера, потыкал по клавишам.

Дошло, насколько мелочно мое возмущение и насколько жизнь прекрасна.

Вот так вот.

Гламурные программисты

Mon, 11 Dec 2006 10:06:48 GMT

Обсуждали программиста X, я присутствовал и слушал. Говорили, что программист X чрезвычайно гламурен. Распиарен - это раз, вхож в разные программистские тусовки - это два, ко всем своим достоинствам пишет на Джаве - это три, все его хотят и хедхантят - это четыре.

Смотрел на себя, оценивал гламурность. С ужасом ощупывал костюм и сорочку, купленные накануне в гламурном магазине "Эстет". Параллельно думал страшные мысли, что не пойду со всеми есть еду из пластиковых коробочек, а, обратно, пойду пижонить в кафешку-ресторан "Фантоцци". Думал разное, можно ли считать #ff гламурной тусовкой.

Однако, я пока не пишу на Джаве! Я не совсем потерян и гламурен, черт побери!

Выйти из тени.

Fri, 27 Oct 2006 12:22:18 GMT

Нынче я работаю в Нивал Онлайн.

http://www.dtf.ru/news/read.php?id=42716

Вот сижу и вижу, как эти 20 миллионов по справедливости делят между программистами, дизайнерами и художниками... Хочу уже свою долю.

Радует, что обещают дать писать тек. Надо будет взять исходники старого корпоративного движка и предать их очистительному пламени. Обнаружил, что эти идиотские исходники ассоциируются с конкретными людьми. Надо себя бороть и не отождествлять. Что очень сложно.

Пиджак +5 shadow damage

Tue, 03 Oct 2006 07:22:46 GMT

Играл в ВОВ, ходил в DeadMines. Нарулил себе синюю рубашку и синюю палку http://www.thottbot.com/?i=4815. Палка сама с красным концом - такой кристалл на тонких ножках в навершии. Абсолютно неэргономичная конструкция, непонятно, как ей можно тыкать врага - каменюка должен сразу выпасть. Однако тыкать можно, и врагу больно.

Думал по дороге на работу о разных игровых условностях. Взял в руки палку - и опа! Стал круче. Интеллект поднялся и дух воспрял. И выносливости наросло ( на целых пять условных единиц ). Думалось мне, что в жизни такого не бывает.

Однако, пришел на работу, сижу, тыкаю пальцами в клавиши. Тут надо сказать, что хожу я на работу в костюме, а все остальные программисты кто в чем. Подходит новый в Нивале менеджер, просит чтобы я "проставил у своих людей опоздания". Я объяснил, что проставлять опоздания не входит в мои профессиональные обязанности.

Так что хорошая одежда рулит в обоих мирах. Пиджак +5 shadow damage.

Про любовь

Wed, 20 Sep 2006 15:44:42 GMT

Дело было в Вестфолле, в минутах полета на грифоне от людской твердыни.

Его звали BETEPOK, он был орком-шаманом 60 уровня; в наплечниках его доспеха бились живые молнии. Он был элитой Орды. Ее звали... не помню как, да и не важно это. Она была человеком; люди - силы Альянса, Альянс враждебен Орде.

Она была босая и в длинных одеждах. Он ставил на землю четыре тотема ( тотем земли, тотем огня, тотем воды и тотем воздуха ) по вершинам квадрата и садился на землю в центре. А она танцевала для него.

Пришли двое. Один был быстр, как красная молния. Второй соткался прямо из тени и атаковал орка со спины. Оба были 60 уровня. Все произошло быстро, и ее смех звучал как колокольчик.

"Нубы! Нажрались химии и вдвоем одного одолеть не смогли! Он вас сквозь натурпротекты убил!"

Потом началась заваруха и стальной кулак Альянса таки раздавил врага. Одинокого орка-шамана 60 уровня.

Она плакала над его трупом, над погасшими наплечниками.

А я, ворлок 19 уровня, думал про то, что игра - это почти жизнь.

Серебряная пуля для кабана

Fri, 01 Sep 2006 12:06:03 GMT

Присутствовал на собеседовании, задавал простые вопросы.

В голове созрела мега-задача, которой можно свалить кабана.

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

Интересно, кто думает, что знает решение?

Последний день лета

Thu, 31 Aug 2006 09:25:03 GMT

Затем, что дни для нас —
ничто. Всего лишь
ничто. Их не приколешь,
и пищей глаз
не сделаешь: они
на фоне белом,
не обладая телом,
незримы.

прекрасное в программировании

Mon, 03 Jul 2006 07:30:24 GMT

Прекрасно, когда функции называются маленькими_буквами_с_подчеркиваниями, ясно и внятно, например: calc_distance_or_return_if_greater_than_treshold.

Прекрасно как бы ненароком бросить взгляд на ассемблерный листинг от Intel C Compiler и краем глаза увидеть россыпь parallel scalar SSE команд.

Прекрасны даже строки std::vector в коде. Мимолетное чувство радости охватывает тебя в тот момент, когда наводишь указатель мыши на них. Ах, как приятно нажать в этот момент на backspace!

Прекрасны юнит-тесты, которые пройдены модулем.

Но прекраснее всего commit в SVN на машине с RAID0 массивом. Клик мыши, треск дисков на мгновения - и тишина.

Об общем и частном

Mon, 26 Jun 2006 17:43:48 GMT

Вот ехал в метро и думал про http://boris-batkin.livejournal.com/8847.html?nc=8 . Реакция на отрывок "...то таки поправить в другом..." забавна. Забавна тем, что из всего русско-программистского ЖЖ откликнулись два моих товарища по работе и откликнулись на пункт минимального интереса.

В свое время разговаривал с другим товарищем по работе, пили чай. Я рассказывал про то, как присутствовал на собеседовании. Посетовал, что собеседуемый не смог написать на asm на бумажке критическую секцию своими руками и как-то не особо зажег на той же бумажке скиннингом на HLSL. Товарищ по работе прослушал, а потом сказал: "Это еще что, я вот собеседовал и собеседуемый не смог назвать ни одного Способа Организации Сцены". Последние три слова были явно именованы с большой буквы. Я подавился чаем - срочно стал соображать, что за Способ Организации Сцены, именованный с Больших Букв. Спросил, ибо я нахальный и не стесняюсь повышать свои знания. Оказалось, что правильный ответ "octree" и еще что-то, что именно, я забыл. Нет, не то чтобы я не знал это слово, но было оно на краю сознания. У меня сразу возникли ассоциации: "Маргинальное Ускорение Функции FrustrumCull(...)" и "Большие Проблемы С MoveUnit( const CVec3 &vPos )". Мелькнули и исчезли на краю сознания. Второй Способ Организации Сцены у меня вызвал еще меньше ассоциаций, его я даже не запомнил. Продолжали пить чай.

Думал я так шибко, что проехал Китай-Город, пришлось сделать RollBack на одну остановку.

Шопен, прелюдия 24

Sun, 25 Jun 2006 10:09:46 GMT

Слушал http://classic.chubrik.ru/Chopin/Prel_Argerich.html , 24 прелюдию. Создалось ощущение, что исполнитель адски мажет. В конце первой фразы, когда шестнадцатой играет си-бемоль перед ударной ля.

Скачал "сорцы" http://www.sheetmusicarchive.net/compositions_b/pre28_24.pdf Нет, сука, все правильно. И как у Рубинштейна получалось не акцентировать эту самую си-бемоль, которая ни к селу ни к городу?

После перерыва в год сел за фортепиано, решил сыграть сам. Получил адское разочарование. Со слуха кажется, что вещь простая. Левая рука тихонько переливает шестнадцатые. Правая ведет мелодию, простую, как "Мурка". А на практике - хуя. Левой надо в адском темпе с пятого на первый палец летать через полторы октавы. И не акцентировать, мягко. А правая взрывается шопеновскими проигрышами по всей клавиатуре up down. Я в таком темпе не могу.

Сколько же надо тренировать пальцы, чтобы играть эту, несложную с первого взгляда вещь? Или вот просто так, нахаляву кому-то дается? От Бога? Как Паганини, который якобы по причине особой болезни суставов пальцев мог феерически играть? Или надо всего лишь по 6 часов играть гаммы? Каждый день, 20 лет. В духе тренировок восточных монахов.

Думаю, что от Бога.

Послеобеденное расслабленное

Thu, 08 Jun 2006 11:54:41 GMT

Рядом с Нивалом есть торговый комплекс "Пятая Авеню" ( оказывается, что Авеню - это она ). Поскольку нам либерализовали услуги питания, то пошел кушать туды.

Итальянская кафешка "Фантоцци". Кафешку от ресторана отличить легко, кафешка женского рода, ресторан - мужского. В кафешке официантки, в ресторане - официанты. Так вот, в "Фантоцци" большинство персонала - девушки, но есть и пара официантов, так что есть стремление от к.

Взял премилую "Груду цыпленка по-милански" - куриное филе с кэрри, ломтиками сладкого перца и ананаса. Продукт крайне рулит за счет грамотного подбора специй. Белого вина в розлив не было, пришлось взять ром, 40 грамм. Ром ординарный, грубоватый. Закончилось все кофе. Сверху пенка, пенка посыпана корицей - вкусно. Чизкейк с ванильным соусом и клубничными разводами по тарелке. Клубничные разводы пахли синтетикой, это минус. Общая оценка 4+.

Вот, работать хочется.

rev 1.1: Грудка цыпленка, а не груда.

Модный тренд.

Wed, 07 Jun 2006 09:11:02 GMT

С прекрасно-художественной точки зрения речь пойдет про ZBrush, который привносит в 3D моделирование классические скульптурные техники. Создаем крупную форму, общую топологию, рисуем поверх кисточкой. Мнем, вытягиваем по-разному, красим. Разные кисточки - разная фактура.

С точки зрения реализации - сначала делается экстремально lo-poly моделька. Делается ей subdivision, получается почти регулярная сетка, по которой совсем легко рисовать кисточкой. Храним смещения.

Вот посмотрим, что можно делать с такой моделькой. Во-первых, результирующая модель имеет очень простую топологию, нет проблемы строить уровни детализации. Во-вторых, нет проблемы прикручивать адаптивные алгоритмы тесселяции в стиле ROAM, ибо модель состоит из кусков с регулярной топологией. Считать разные уровни детализации, морфить между ними - не проблема. Опять же сжимается информация на раз - сетка состоит из регулярных кусков, а сжимать 2D массивы лихо надрочились. В том числе и тупо, см. DXTN алгоритмы сжатия текстур. Легкие данные - легкий стримминг, общность подхода: от ландшафта, крупных объектов вроде скал, пещер, утесов до монстров. Вот додумаются в ZBrush ( или аналоге ) ландшафт моделить - совсем круто будет. Как обычно, все упирается в конвенциональные средства редактирования.

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

Спускаясь к железу - все становится просто отвратительно. Плавающая тесселяция, которая есть на XENOS и которой нигде больше нету и не будет; могучие SPU, которые могут считать на лету все что хошь, хошь тесселяцию; PC с перспективами странного интерфейса DX10. Прямо жить хочется. Мне кажется, что тема будет модной.

И, как обычно, ничего нового. Вспомните, когда были сказаны слова "npatches" и "vertex displacement".

Депрессивное постаттестационное.

Wed, 31 May 2006 08:38:00 GMT

Прошла аттестация. Аттестовали, зарплату подняли, назвали нужным. Конечно, пожурили так отечески. Что не дело знать шейдеры ps 3.0, несолидно это. Лучше бы изучил корпоративную систему UI. Она страх какая сложная, сама мыслит, а внутре у ней неонка.

Настроение депрессивное - специально ходил по Нивалу, смотрел, кто зажигает. Никто не зажигает. Далее - совершенно абстрактно.

Мега-дизайнер с супер-идеей игры. Менеджер говорит: "Издателям не нужны новые жанры и новые игры, давайте купим Ай-Пи. И будем делать игру про э... Человека-Паука, это очень крутой Ай-Пи. Давайте, дизайните пропозал, через неделю дедлайн."

Программист хочет писать low level, ему говорят: "Мы не фигней занимаемся, а делаем игру про Человека-Паука! Посему будем делать игру про человека-паука на Движке За Миллион, а ты скрипты попишешь."

Лид-программист перекладывает бумажки, спокойный, как Будда. Ему наплевать на технологии, процессы, производимый продукт про Человека-Паука, он перекладывает бумажки. Формализованный подход. Все задачи про Человека-Паука должны быть разбиты на подзаздачи ( не больше 2 и не меньше 1 дня ) и положены в формалин.

На ff возникло отличное новое слово: "Слабак". Не просто мудак. А слабак. Который не верит, что может что-то сделать. И никто не верит в то, что он может что-то сделать. Сидит, делает заформализованные задачи. Рожденный ползать. Состояние души. Есть чужая Ай-Пи, есть миддлварь, еще можно совсем сузиться, уволить программистов и поаутсорсить арт. Зачем жечь, убеждать что могу, потом напряжением всех сил делать - нафиг оно?

И совсем с другой стороны - посмотрим на постсоветское, на вечное. На Сталкера. Эх, слева бесы, справа бесы.

Агейская железка

Mon, 15 May 2006 15:23:48 GMT

Получил от начальства агейскую железку в черной коробке, внутри уложенной розовым поролоном. Выглядит загадочно. Сама железка в компьютер воткнулась, примеры запускаются и работают. По первым впечатлениям - бутылочное горлышко пополам в OpenGL рендеринге в стиле glutSolidCube, пополам в физике.

Ясное дело, что начальство не само железку скрафтило - спасибо Ageia за их агрессивный менеджмент и любовь к девелоперам.

Есть еще API. Собственные размышления на тему std::vector, vec3, quat, ray, plane прилагаются, имеется специальный класс для колеса. Все как в лучших домах Лондона. Имеются виртуальные функции - и не просто из пустых понтов, а настоящий ООП, все наследуется и инкапуслируется со страшной силой. По умолчанию объект имеет отрицательную массу, и остается верить документации, что данная масса будет вычислена автоматически.

Вот вспоминаю OpenGL, разные glVertex3vf(). И нету никаких собственных векторов, и нету труевого ООП. Однако, пальцы сами летают и программу пишут. А тут - хуя. Зачем такой API, когда пишешь, а в кончиках пальцев нет удовольствия?

Разное.

Wed, 10 May 2006 07:19:35 GMT

После завершения героических битв начальство отпустило всех в отпуск. С 1 по 10 мая.

В связи с чем спал 10 дней. Лицо болит от подушки, да.

Из запоминающихся событий - решил реализовать в себе потенцию цветовода, купил вот такой дендр:

Обсуждения

http://flo.com.ua/forum/viewtopic.php?p=18975&sid=07d70a4f9eb4a56761cd2a3533637bb1

К дендру купил фотоаппарат Canon A620. Из всех фичей больше всего удивило, что при портретной или ландшафтной съемке фотик автоматически переворачивает картинку на 90'. Вот ведь сука, как узнает!

Посмотрел х.ф. "Охота на пиранью". Много смеялся. Битва Главного Героя с Мужиком В Каске порадовала. Ну, это нормально.

А логин на ЖЖ у меня только с работы. Чем надеюсь избежать ЖЖ - аддикции.

Пятые герои

Thu, 20 Apr 2006 11:58:19 GMT

А вот вышли на золото. Начальство написало на форуме, значит информация открыта.

http://forums.ag.ru/?board=heroes&action=display&s=0&num=1116344234&start=175

Ну что можно сказать? Полтора года моей жизни промелькнули как легкий сон. Было разное, много героических битв. Но, черт побери, Heroes 5 gone gold! Есть повод откупорить шампанскую бутылку.

Чье кун-фу самое сильное

Tue, 18 Apr 2006 08:04:18 GMT

Семен http://sim0nsays.livejournal.com тут давече писал про стиль программирования, когда код пишется как бы сам.

Между сборками Heroes 5 Gold Master закачал я последний билд http://sourceforge.net/projects/collada-dom/ Проект интересный, архинужный, почему полезный и зачем нужный - объяснять не буду. Взял я значит последний билд, выбрал там пример по загрузке анимации, запустил.

GPF. Смотрим на код.

http://www.everfall.com/paste/id.php?bd1m51dmolfz

Батюшки, так Name это переменная класса, char *. Как-то нездорово ее в cout совать. Комментируем ошибку, смотрим что дальше.

http://www.everfall.com/paste/id.php?wjenglhhz289

Еще один GPF. Угадайте, почему? Если не угадали, то посмотрите на определение(я) LdaeElement

Правим, находим еще один GPF, он дуален первому. Скрестили пальцы, натравили файлик на колладовский dae файл с анимацией. Опять не работает.

http://www.everfall.com/paste/id.php?8bwbnrzvfqy5

nElements случился нулем. i>= nElements всегда true.

Спросил важного человека, чье имя слишком известно, чтобы здесь упоминать, возмутился: "Неужели эти ****** из Сони не хотят предоставить удобные и безбажные тулзы?" Получил ответ: "А зачем?". "Ну как, чтобы удобнее писать, чтобы снизить ценз вхождения в программирование под PS3..." "Гм, а зачем?"

В этот момент я испытали просветление. Тапком по голове, да.

Дао программирования, пп 7.1-7.2

Thu, 06 Apr 2006 14:16:47 GMT

Всю неделю решалось, пойдут ли программисты Нивала на КРИ в пятницу. Пойдут или не пойдут, пойдут или не пойдут. Наверное, снаружи любопытно смотреть на коловращение писем, указаний и инструкций, но когда ты там, внутри коловращения, весь в боевой раскраске - то вовсе не любопытно. Вот будьте умнее - дождитесь, когда проблема разрешится сама, постойте в сторонке ( согласно Дао ). Не надо кастовать на себя Adrenalin Rush и бросаться в кучу-малу.

Вроде решилось, вроде программисты Нивала пойдут на КРИ в пятницу. Будет круглый стол, будут встречи, будет все. До встречи на КРИ.

Опять будет похмелье, чччччерт!

Школа имен

Fri, 31 Mar 2006 18:52:48 GMT

Была такая китайская школа философии, минцзя. Как обычно, исследовали связь предметов и имен. Про отца-основателя ( одного из отцов ) современные ему древние китайцы говорили:

"Хуэй Ши был очень разносторонен и имел пять повозок книг. Его учение было противоречивым и путаным, а его слова не попадали в цель".

В переводе на русский язык случилось трагическое наебалово, замечательное древнекитайское имя испортили. Вовсе ни разу ни Хуэй его звали, а Хуй.

Эта преамбула должна подготовить вас к маленькому креативу про сферические гармоники.

Про сабж подробно рассказано допустим вот тут: http://lnfm1.sai.msu.su/grav/russian/lecture/tfe/node5.html

Из обстоятельного рассказа мы узнаем, что:

"Свойство ортогональности сферических функций делает их незаменимыми для аналитического представления физического поля, рельефа или других величин, заданных в виде карты на сферической поверхности".

Не-за-ме-ни-мы-ми. Окончив математический факультет и вооружившися необходимыми знаниями о незаменимости, можно легко получить грант MicroSoft и присунуть эти замечательные сферические гармоники в DirectX SDK, дабы в аналитическом виде хранить зависимость освещения в точке от направления на источник света. А потом пошло и поехало - только ленивый программист трехмерной графики не выучит три буквы SHM, ибо козырно и модно.

Какие есть полиномы на сфере степени не выше 1? Тождественная единица, функция x, функция y, функция z. Вот возьмем мы точку на поверхности, есть две полусферы, верхняя и нижняя. Возьмем функцию, которая единица на верхней и минус единица на нижней полусфере. И возьмем разложение этой замечательной функции по нашей системе ( 1, x, y, z ). Что получится? Правильно, первый коэффициент нуль, остальные соответствуют x, y, z компонентам нормали к поверхности. Как считать значение проинтерполированной функции? Конечно, dot с нормалью.

Каждый программист трехмерной графики, который реализовывал диффузное освещение как dot( light, normal ), может смело писать в своем резюме, что он реализовывал освещение с помощью факторизации BRDF функции по сферическим гармоникам первой степени. Такая запись повысит его оклад как минимум на 100-200$ месячно в условиях современного рынка труда в Москве.

Итак, у нас есть объект, весь сложный из себя. Будем помещать источник света в разные точки на сфере огромного радиуса и смотреть, как освещается объект. Со всевозможными подповерхностными и обычными отражениями - преломлениями. И будем в каждой точке раскладывать освещенность по нашей волшебной системе ( 1, x, y, z ), как параметр от положения источника света на сфере. Можно вычесть прямое освещение, которое легко считается отдельно. Идея тривиальная? Да. Этой тривиальной идее есть нетривиальное имя. Даже несколько. Ambient Occlusion Map. Или Bent Normal Lighting. Существенно разные имена.

Кто-то выдумал, что можно хранить в свободном четвертом канале текстуры нормалей угол раствора конуса, который хорошо описывает локальное поведение поверхности. Bump Self Shadowing. Описанное выше яйцо, вид сбоку.

Едем дальше. Спрашивается, почему не раскладывать что-либо по полиномам второй степени на сфере? Вот они:

x, y, z
x * y, y * z, z * x
x * x, y * y, z * z

Единицу я не пишу, так как она есть суть x * x + y * y + z * z

Приятный такой базис, значение в нем считается на раз-два-три. Раскладывать по нему неутомительно и требует знаний в объемах первого курса ВУЗа. Взяли, посчитали, зашили в трех текстурах. Или сохранили повершинно.

Наслаждаемся, пользуемся. Вот только будет немодно, ибо не сферические гармоники. Скажешь: "Использую полиномы второй степени на сфере." Переспросят: "Сферические гармоники?" Ответишь: "Какие такие гармоники? Не знаю никаких гармоник!" Взор вопрошающего потухнет, ибо нынче только ламеры в 3D графике не знают, что такое сферические гармоники.

Едем дальше. Допустим, наш источник света не просто летает по сфере, а эдак свободно плавает в пространстве вокруг нашей освещаемой модельки.

Есть замечательные базисные функции ( 1, x, y, z ) на сфере. А еще есть R - расстояние до источника света. Ну и отличные функции, которые убывают на бесконечности. Скажем, exp( -R ), R * exp( -R ), R^2 * exp( -R ), R^3 * exp( -R ). Из них можно сварганить 16 коэффициентов, которые задают освещенность в зависимости от положения источника света. Наверняка, этому скоро придумают какое-то название. Или уже придумали и огребли по случаю грант от MicroSoft. "Light Decomposition using Bessel Functions", или что-то в таком духе.

минцзы.