?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Entries by tag: release

Рефакторинг регулярных выражений
nyaload
_winnie
Рискую быть обвинённым в капитанстве, но всё-таки. Всё-таки я часто вижу нечитабельные регулярные выражения, причем не потому, что они регулярные, а потому что автор - макака.

Копипаст в регулярных выражениях - тоже можно рефакторить и сводить к многократному использованию уже определённой абстракции.

Вот есть у нас регулярка для последовательности пробелов \s+. И есть регулярка для числа, ([-+]?[\d]+). Нам надо извлекать числа из строк вроде "+123 -123 111:222:333". Легко сочинить монстра "([-+]?[\d]+)\s+([-+]?[\d]+)\s+([-+]?[\d]+):([-+]?[\d]+):([-+]?[\d]+)". Сочинить легко, прочитать и исправить сложно. А нужно для читаемости писать код так, как он в голове, а не транслировать его в копипаст. Можно такое регулярное выражение записать вот так:

"7 7 7:7:7".replace('7', r'([-+]?[\d]+)').replace(' ', r'\s+')


Тогда проще понять что имелось ввиду, исправить регулярное выражение. Как структуру первого уровня, например заменить "7 7 7:7:7" на "7:7:7:7". Так и второго, напр. матчить не только целые числа, но и дробные 123.456.

Winnie C++ Colorizer
nyaload
_winnie
Обновил Winnie C++ Colorizer. Генерирует лаконичный html код, делая самый часто встречающийся цвет дефолтным, так же заменяет "#000000" на "black", "#0000ff" на "blue" и тп. Так же перехал со старого dobrokot.nm.ru с рекламой на новый dobrokot.ru. К сожалению, забыл пароль от ftp, и не могу поставить редирект.

Брать здесь: DobroKot.ru/WinnieColorizer.

Для тех кто не в курсе - это расцветка кода С++, для того что бы постить в ЖЖ. Автор заявляет, что может покрасить любой самый извращённый C/C++, включая мутантов с Obfuscated Contest. И выдаст более короткий html чем любой другой колорайзер :) Проблему с русскими буквами ещё буду решать, что бы выдавать UTF-8 в stdout и UCS-2 в clipboard.

Пример работы под катом.
Read more...Collapse )

Больше хаоса! Коэффициент пидорастичности файла.
nyaload
_winnie
Определение: коэффициент пидорастичности текстуры (или любого другого файла):
размер текстуры в байтах, делённый на степень сжатия в zip.

напр. если файл в 800 байт сжимается до 400, то его коэффициент равен 800/(400/800) == 1600

Скрипт для нахождения самых пидорских текстур (напр. одноцветного голубого неба 2048x2048 в RGBA формате):

import sys, os for f in sys.argv[1:]: data = open(f, 'rb').read() zdata = len(data.encode('zip')) if len(data): ratio = zdata / float(len(data)) else: ratio = 1.0 print '%s: %s %s %s %s' % (f, len(data) / ratio, int(ratio*100), len(data), zdata)


Скрипт проверяет файлы переданные в командной строке, для запуска на всех dds-файлах я использую под cygwin следующую команду:
find -iname '*.dds' | xargs -P 4 python gay_coeff.py | sort -k 2 -n > dds_zip.txt
cygwin используется что бы encode('zip') работал на всех ядрах процессора, в один поток легко переписать на чистый питон.

Ещё отлично ищутся сверх-тесселированные кубические домики.

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

update: исходники тоже так можно проверять ;-)

Перевод по горячей клавише в windows.
nyaload
_winnie
У Яндекса есть онлайновый словарь http://slovari.yandex.ru/, но перейти туда и вставить слово - не так удобно как хочется.

Захотелось написать мини-скрипт, который это дело автоматизирует.

Можно на горячую клавишу назначить запуск выполняемого файла.
Этот файл может взять скопированный текст из буфера обмена, и открыть браузер.

Приступаем:

1)
Сначала создаем файл translate_word.js, в него копируем следующий код:
Read more...Collapse )


2)
Создаём ярлык на рабочем столе, который ведёт на созданный translate_word.js

3) Назначим горячую клавишу. Правой кнопкой мыши кликаем на ярлык, на вкладке "Ярлык" в поле "Быстрый вызов" вводим горячие клавиши. Напр. Ctrl+Alt+C.

Теперь если надо перевести слово - можно его выделить (даблкликом), нажать Ctrl+C и Ctrl+Alt+C.

Та-да ! Будущее за онлайновым софтом!

DOT (овалы со стрелками)
nyaload
_winnie
Иногда при копании в текстовых файлах, в которых хранится дерево зависимостей или граф, хочется получить наглядное представление этого файла. Это могут быть зависимости между данными или промежуточное состояние программы при отладке сложного алгоритма на графе/дереве.
Есть простой инструмент, DOT language, который по текстовому файлу сгенерирует рисунок.
Например, по описанию

digraph graphname {
  a -> b -> c;
  b -> d;
}


будет построен рисунок:

Read more...Collapse )

Графические файлы DDS. Что лучше, DXT1, DXT3, DXT5 и тп.
nyaload
_winnie
DDS файлы - картинки, в которых данные хранятся так же, как в видеопамяти (включая мипмапы). Это позволяет их быстро загружать в игре. В DDS могут храниться объёмные текстуры, кубо-мапы и прочие необычные (для графических файлов) вещи.

2D слои в DDS-файле могут храниться в RGBA формате, а могут быть сжаты в форматы DXT1, DXT3, DXT5.

Это сжатие с потерями, как Jpeg. Оно было специально разработано для того, что бы видеокарта могла "расжимать" гигабайт текстур за секунду, отображая на экране сжатую текстуру сразу из видеопамяти, без промежуточного конвертирования.

DXT1 - для RGB картинок c однобитной альфой, четыре бита на пиксел (сжатие в 8 раз по сравнению с RGBX).
DXT3 и DXT5 - для картинок с альфа-каналом, типично DXT5 лучше. 8 бит на пиксел, сжатие в четыре раза.


Подробней про метод сжатия, на уровне битов:


изображение делится на блоки 4x4. Для каждого блока хранится два 16-битных цвета. При распаковке из двух цветов x,y генерится четыре последовательных цвета, палитра [x, ⅔x + ⅓y, ⅓x + ⅔y, y]. После 2*16 бит цветов хранится 4*4 двухбитых индексов в эту палитру. Порядок двух цветов (цвет_0 > цвет_1 ?) так же содержит один бит информации. Если цвет_0 > цвет_1, то в палитре одно из значений используется как нулевая альфа, и остальные 3 цвета [x, ½x + ½y, y] - палитра из непрозрачных цветов. Всего получается 64 бита на блок 4x4 пиксела.
В DXT3 и DXT5 rgb-канал хранится точно так же как в DXT1. Альфа в DXT3 хранится просто как округлённое с 8 битов до 4 битов на пиксел, без сжатия. В DXT5 для альфы используется метод сжатия, похожий на метод для RGB в DXT1. Два значения альфы на блок 4x4. Если цвет_0 > цвет_1, создаётся 6 промежуточных значений альфы в палитре и ещё отдельно два особых значения 0 и 1 для альфы. Если цвет_0 <= цвет_1, то из двух крайних значений альфы создаётся 8 промежуточных. После двух 8-битных граничных значений альфы идёт 16 3-битных индексов. DXT5 обычно гораздо точней сохраняет альфу и рекомендуется вместо DXT3.

Артефакты после сжатия малозаметны, чаще всего их можно увидеть в блоках, где сходится 3 разных оттенка (3 оттенка в 2-х на один блок не помещаются).

DXT2 раскодируется так же как DXT3, DXT4 так же как DXT5, только программа должна интерпретировать RGB как уже умноженный на альфу. В них хранится флажок "premultiplied alpha", который может быть интересен универсальной смотрелке картинок, но не игровому движку.

Это сжатие с потерями, паковщик должен выбрать два идеальных цвета для квадрата 4x4, поэтому разные инструменты могут конвертировать с разным соотношением время работы/качество результата. NVidia хвастается, что её nvcompress лучший, не знаю насколько справедливо. На глаз вроде результат лучше, чем у TEXCONV из D3D SDK.

При сжатии DXT в zip имеет смысл разделить индексы и палитру, хранить приращения. Тогда сожмётся чуть лучше. Увы сам не мерял, только напел. Если вы пробовали - напишите, интересно.

Можно чуть-чуть "подвигать" ползунок качество/сжатие таким образом: перед DXT-сжатием использовать текстуру которая в 2 раза больше, если такая есть. Например, уменьшить то, что нарисовал художник не с 4096x4096 до 128x128x, а до 256x256.

Итого:

Eсли картинка без альфы или достаточно однобитной альфы, используйте DXT1. С плавной альфой - DXT5. На "мультяшных" картинках с мелкими деталями будут артефакты, на реалистичных текстурах с шумом и градиентом компрессия незаметна.

Иллюстрация (масштаб 400%):
Read more...Collapse )

ширина PDF на мобилках
nyaload
_winnie
Известно[см. опровержение в комментах], что pdf неудобно читать на маленьких экранах, так как ни одна программа не умеет переформатировать текст в pdf под новую ширину экрана.

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

Попробовал, получилось. Накатал proof of concept. Картинки под катом.
Оригинал, линии разреза, и результат.

Read more...Collapse )

Попадание точки в многоугольник. Количество заныриваний не равно количеству выныриваний.
nyaload
_winnie
Есть точка O, есть многоугольник A[n] на плоскости. Надо выяснить, попадает ли точка в многоугольник.

Основа алгоритма описывается очень просто: давайте возмём бесконечный горизонтальный луч из точки направо. Если луч пересекает границу четное число раз (в том числе 0 раз) , то точка вне многоугольника. Если нечетное число раз - то внутри.



Затем программист пытается обработать хитрые случаи: луч проходит через вершину многоугольника, сторона многоугольника совпадает с лучом. В коде возникают какие-то if, какие-то EPSILON..., молитвы о том, что редкие случаи когда две точки на расстоянии EPSILON но луч между ними - не существуют, насильно изгонясь из сознания Read more...Collapse )

Смотри ещё: • Угол между двумя векторами
Смотри ещё: • Пересечение двух отрезков

Угол между двумя векторами:
nyaload
_winnie
Угол между векторами: atan2( length(cross(a, b)), dot(a,b) ). atan2 - из стандартной мат-библиотеки языка. cross - векторное произведение, dot - скалярное.
В двухмерном случае length(cross(a,b)) заменяется на axby - bxay, и угол считается проще, atan2(axby - bxay, axbx + ayby). Угол даже со знаком получается (против/по часовой стрелке).

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

Очень часто угол вообще излишен, достаточно только косинуса угла ( dot(a, b) ), а угол считают зря. Напр. выражение для сравнения угла с константой:
angle(a, b) < 45°
можно записать как
cos(angle(a, b)) > cos(45°)
dot(a, b)/(length(a)*length(b)) > cos(45°)
dot(a, b)2 > 0.5*length2(a)*length2(b).
0.5 здесь взялся как cos2(45°). И ещё надо не забыть условие dot(a, b) > 0. length2 - это sqrt(x2+y2+z2)2, то есть (x2+y2+z2), без извлечения корня.

В результат код без делений, без квадратных корней, без тригонометрических функций, что может ускорить его в десятки раз. Если вектора единичные (заранее отнормировали), то вообще замечательно. Можно не ломать голову, как корректно возвести длину в квадрат.

PS. Если в коде +10% понятности значимей, чем ускорение в 20 раз, лучше писать по-человечески, как мыслишь. Только всё равно в функции angle замените аркосинусы на atan2. И проще, и безопасней.

Смотри ещё: • Пересечение двух отрезков
Смотри ещё: • Проверка точки внутри многоугольника

iphone и JS.
nyaload
_winnie
Айфон - необычно открытая для разработки на JavaScript платформа. На потребительском айфоне есть девелоперская консоль для отладки (для айфона это нонсенс!). На прошивке 2.1 и выше можно по кнопке '+' поставить JS приложение как нативное полноэкранное, в общий список программ, если добавить <meta name="apple-mobile-web-app-capable" content="yes" />. Есть сафари-специфичные расширения (вращение картинок напр). Сам JS довольно шустрый. Есть ощущение, что кто-то из инженеров в apple отбился от рук, и лавочку могут прикрыть. Это ж кто угодно может писать программы для айфона!

Сейчас ради фана делаю тетрис, отладил на PC и на айфоне. Владелец HTC-андроида сообщил, что тетрис зависает, но в руках пока нет такого телефона, что бы взять на пару дней домой и отладить :(

Самое сложное - сделать для классически кнопочной игры управление с тач-скрина. С грехом пополам справился, так что бы был контроль над фигуркой одним пальцем (мышкой/стилусом).

Для большей динамики игры очки выдаются только за роняние фигурки вниз :)