Saturday, December 25, 2010

Обрадовать PageSpeed

Ну очень короткий пост или улучшить результаты в PageSpeed ну хоть немного.

  • Включить кеширование. Если ваш случай Apache, добавляем подобную комбинацию для медиаконтента:
    Header set Cache-Control "max-age=3153600, public"
    Сжимать выдаваемый контент:
    SetOutputFilter DEFLATE
    Эти строчки желательно использовать только внутри FilesMatch, IfModule - так как сжимать картинки бесполезно, а кешировать до бесконечности html нельзя - на корень вход с параметрами в url не поставишь.
  • Объединить несколько css/js файлов в один через вызов скрипта с параметром список объединяемых скриптов/стилей. Желательно при объединении оставлять метки что откуда взято - чтобы не искать иголку в стоге сена.
  • Упаковать результаты вывода этого скрипта (желательно не полностью, а каждый файл с пометкой минимизированная версия чего представлена). Для css - мне понравилось использовать cssmin, для js - google closure compiler. Оба инструмента позволяют минимизировать на лету. Первый локально, второй можно через API удаленно. Во втором случае лучше давать исходный код, а не каким-то образом минимизированную версию.

Tuesday, December 21, 2010

Магия глубины

На прошлых выходных мне случайно попалась ссылка на интересный сайтик, который долго искал - на нем предлагаются драйвера для Windows для поддержки стереоскопичного 3d. Когда то лет 5 назад у уже видел ссылку на подобную функциональность, она включалась редактором реестра для Nvidia карт, но они ее почему-то удалили. Теперь опять в дровах она появилась, но опять для Nvidia и для топовых карт, это не является достаточным основанием, как по мне менять свои компьютер с ATI видеокартой. Вот теперь эту функциональность можно посмотреть на любой видео карте. Правда некоторые игры имеют возможность самостоятельно создавать картинку с искажениями цветов нужные для анаглифных очков, но хотелось везде и сейчас.

И вот на какие мысли это меня натолкуно:

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

Это в принципе равнозначно тому, что у обоих кадров подобны буферы глубины кроме близко расположенных объектов. И если генерировать сначала буфер глубины для далеких объектов, там где разница в отображении для разных глаз меньше пикселя, то загружая эти данные в буфер глубины мы резко сокращаем количество расчетов цвета и для точек, так как все дальние точки уже учтены на этом буфере. Или можно брать кадр с расстоянием до точек для одного глаза и убирая все точки ближе определенного минимума- мы получим исходные данные для второго глаза. Правда можно еще учитывая данные о расстоянии немного сдвигать изображения для каждого глаза - но это получается какая-то косоглазая глубина.

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

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

Может так и делают и я что-то упустил?

Saturday, December 4, 2010

Применение смартфонов с точскрином

Так как они не могут пока конкурировать с обычными мобильными телефонами по времени жизни без зарядки. Обычные мобильные телефоны живут где-то ближе к неделе(или это у меня они так долго выдерживали) с точскрином с нормальными характеристиками и внешним видом живут где-то 2 дня максимум.

Я подумал их же можно использовать вместо мышки - такой высоко технологичной и дорогой. Они все имеют какое-то подобие usb порта и теоретически можно создать приложение которое будет эмулировать протокол мышки для компьютера и экран можно использовать как подобие точпада с возможностью отображение области под указателем мышки и дополнительной информации - например управление через поворот относительно сторон света и 3d управление через акселерометры и gps.

Ядро 2.36.1 + Ubuntu

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