Продолжаю предыдущую тему.

Проблема с резкостью решилась слабым повышением контраста (ровно до уровня freetype). Думаю, за этим можно и работать. Ещё бы железо позволяло :D (при одиночном проходе нагрузка утроена, до дискретки так и не дошёл).

Часть greyscale простыни из шейдера выкинул - синусы и билинейное не очень то и сдались, комфорт важнее CRT-шной ламповости.

Заодно обоину сменил (тоже 4k). На предыдущей оказались аберрации прямо по всему изображению.

Если что, этот скрин в нормальном масштабе (субпиксельная раскладка - горизонтальное RGB).
Исправить радугу возможно если ваша субпиксельная раскладка поддерживается fontconfig/freetype (только линейный RGB и её повёрнутые варианты). Для BGR - на 180 градусов, верт. RGB - вправо на 90, верт. BGR - влево на 90. Для всего остального (двухмерные раскладки какого-нибудь pentile или просто перестановки типа GBR/GRB, если такие вообще бывают) - ничего не поделать (а вообще, у меня свербит как-нибудь запилить в шейдер и pentile и даже старый добрый CRT, у которого сетка регулярная, но кишит тригонометрией).

Ред.: старая ссылка в вики с шейдером сломалась, т.к. предыдущий заголовок мне показался не очень подходящий (после того, как выкинул ненужные greyscale фильтры).

https://github.com/yshui/picom/wiki/Shader-Shop#fullscreen-subpixel-antialiasing

>>> Просмотр (2732x1536, 1987 Kb)

Нет, это не сон.

Если что, на скриншоте — горизонтальный rgb. Если у вас другая субпиксельная раскладка — попробуйте повернуть на 90, 180 или 270 градусов.

На днях случайно заметил опцию в xrandr --scale. По сути, это делает виртуальный монитор с разрешением помноженным на физическое. И тут в голове завертелось.

Поставил свежий picom, у него как раз есть опция –window-shader-fg для экспериментального glx (в egl не завелось). Ставлю масштаб дисплея в 3x3. Этакий виртуальный HiDPI. К сожалению, билинейное работает максимум на 2x, начиная с 3x — скатывается в ближайшее. Впрочем, другого и не надо. Как я надеялся, ускорение не отваливается (прям как я мечтал — виртуальный HiDPI монитор, только тут — сразу из коробки).

Подсовываю Picom шейдер, который выполняет размытие — по сути, ту самую lcd фильтрацию, как у freetype. Хотя что-то не так. Если freetype lcdfilter=lcdlight (базовая коробка 3x, в теории — для субпиксельной больше не надо), то шрифты — чётче некуда, хотя с default тоже нормально. У меня — если с коробкой 3x3, то по чёткости недотягивает даже до default.
Или дотягивает? Непонятно.

Пока игрался, решил засунуть и другие фильтры:

• коробка 3x3 в сером (при технике kawase — даже смысла в делении на поосевые этапы нет, и так и так 4 пиксела на один);
• линейный шириной 5 и пара синусов (один с точечным сэмплированием на 5, другой — интегрированием, шириной 7).

Требуются OpenGL 3.3 + GLSL 3.3.

А ещё железо. Хорошее. Возможно игровое. У меня проц с Intel HD 3000, попробовал на нём glxgears. При нормальной работе без масштаба и в исходном размере 300x300 выдаёт 8000fps. После масшатаба (ещё без picom и вообще композитора) упал до 4000-5000, а как развернул… 15fps (steam чтоли поставить… дискретку ещё не запускал). Хотя тут ещё тротлинг из за перегрева. Если на холодном железе — 30fps может выдать, хотя со временем падает.

Picom — если без шейдера и размытия, то ещё нормально (тени почти не нагружают). С шейдером — смотря сколько окон в поле зрения. Вообще, он рассчитан на то, чтобы быть экранным, а не оконным. Там даже есть опция, чтобы пропускать 1/9 пикселей при одном проходе и 4/18 при двух. Сейчас — если её включить, то окна видны только если координаты кратны 3. В общем, вероятность видимости окна с этой опцией 1/9.

Ссылка на шейдер:
https://github.com/yshui/picom/wiki/Shader-Shop#fullscreen-antialiasing-subpixel-filtering-support

>>> Просмотр (1366x768, 264 Kb)

И так, единственным тестом который скачивается из России и работает бесплатно оказался этот. К тому же еще и с официальной поддержкой Linux. К сожалению только OpenGL. Качество графики FullHD Extreme.

>>> Просмотр (1920x1080, 3044 Kb)

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

Да дизайн похож на блендеровский, и не с проста, я ориентировался на бледеровский интерфейс, иконки тоже от туда взяты, со временем конечно придется их перерисовать. Так же позаимствовал панельку сверху тоже из идею нового UI для блендера. К сожалению толком своего ничего придумать не могу, а программа нужна, ну и интересно было ее поделать и реализовать интерфейс полностью на OpenGL.

Сейчас программа активно используется мною, для создани игры на Haxe, написал простой фреймворк для загрузки карт созданных в этом редакторе для него, в будущем будет еще и C++. Для меня программа оказалась очень даже полезной )

В будущем хочу сделать открытый доступ к программе, но не уверен что буду открывать исходники, т.к. скажу честно, боюсь критики )) И самое наверное элементарное здесь, что я не через makefile сделал, а через башскрипты, и один файл main.cpp инклудит все заголовочные файлы и исходный код! Я до этого много работал на дельфи, и пересел на C++ года 2 назад, и когда уже было очень многое написано, я только понял что я налажал, но уже поздно, а все переписывать не очень хочется.
Еще скриншоты:
http://habrastorage.org/files/7b3/c85/958/7b3c85958c004fafbd1200b9aab3abc7.png
http://habrastorage.org/files/f1b/c5e/62a/f1bc5e62a6ea4967abcb5940d0b9e6c5.png
http://habrastorage.org/files/1bf/504/3a4/1bf5043a42c444ba84f5b4c64614ba1f.png

А раньше он выглядел вот так:
http://habrastorage.org/files/667/d86/820/667d86820eb4476ab90bc2e3fd4895c2.png

Виде игры которую я делаю на Haxe, только приступил к работе:
http://www.youtube.com/watch?x-yt-ts=1421828030&x-yt-cl=84411374&v=CO...

>>> Просмотр (1920x1080, 238 Kb)

Пишу ненужно в ненужно под ненужно онтопик. Попалась както на хабропомойке статья про кубик Рубика на WebGL, решил написать сам под обычный OpenGL. ООП головного мозга заставило для такой простой вещи родить 25 классов, что меня малек раздражает.

inb4: Удалено. Причина: дефолт.

UPD: https://github.com/santa01/rubik

>>> Просмотр (1366x768, 425 Kb)

В общем, то, что вы видите — это, так сказать, проба пера. Грубая, почти «квадратная» модель MP5 с прицелом, огромный «плэйн» с размытой текстурой и то ли домик, то ли ангар с «экструдированной» дверью. Не Crysis, конечно, (в разработке еще много всяких вещей), но если выйдет хотя бы бета, да еще и с интересным сюжетом, может кому-нибудь понравится :)

>>> Просмотр (1024x600, 97 Kb)

Я уже долго достаю народ всякими дурацкими вопросами, как, например, этот. Вот решил показать, что в результате получилось.

Пока, конечно, функционал и 10% желаемого не набрал, но уже кое-что есть: редактирование fits-заголовков (пока без сохранения, но его несложно добавить); распознавание точек на гартманограмме (она слева вверху) - отождествление пятен, поиск двух маркеров и автоматическая нумерация всех пятен по радиусу и углу (сюда еще добавлять довольно много); вписывание гауссиан для более точного определения центра пятна, спектральной линии и т.п.; отождествление выбранных мышью участков; построение преобразования Хафа (хочу еще интерактивности добавить и автоматический поиск наиболее вероятных линий, еще нужно будет добавить другие виды математических операций); трехмерный просмотр изображений (еще надо добавить навигацию мышью и еще некоторые интересные штуки, плюс уйму математики).

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

Открытая гартманограмма имеет размер 3000х3000 пикселей. При всех этих открытых окнах приложение отжирало 182МБ оперативки.

Большое спасибо Reset'у, vertexua и остальным советчикам.

>>> Просмотр (1920x1080, 275 Kb)

Делаю первые шаги в создании интерфейса для управления одной железякой. Видео захватывается с веб-камеры, накапливается по 4 кадра, выполняется вейвлет-преобразование и преобразование Хоу (Hough transform).

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

В итоге должна получиться автоматическая фокусировка «микроскопа» и установка образца строго по направлению осей XY-подвижки (и это малая толика общего функционала будущей системы).

>>> Просмотр (1680x1050, 265 Kb)

Здравствуйте!

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

Просто, но всё-же на соурс-фордж выложил: https://sourceforge.net/projects/xmgravdots/

Если кто хочет попробывать: зависит от openmotif-библиотек (libXm.so.4), библиотеки X11 и OpenGL. Никуда в файловую систему не лезет, ибо это просто визуализация. Известные неполадки: на видеокартах intel i845 и ей подобных не будет работать 99.9% (как-то связано с функциями, которые используются для добавления openGL конекста в openmotif, ещё не разобрался).

По поводу скриншота: DE: xfce-4.6.1, wallpaper когда-то давно взят у Sylvia: http://www.linux.org.ru/gallery/screenshots/4722653

>>> Просмотр (1280x1024, 648 Kb)