Т.к. с недавних пор снова начал заниматься геймд^W фигней, решил привести в более вменяемый вид одну свою pascal'евскую библиотеку(да-да, Pascal). Но ввиду того, что новых проектов нет, взялся подкрутить старый. Если не сложно, может кто погонять/протестировать эту гамезу(двухмерная танковая аркада, 1.9Мб) ?. В архиве лежат бинарники для x86 и x86_64, включая сборку для альтернативной ОС. Для арчеводов есть PKGBUILD. Из зависимостей - OpenAL и libmodplug, ну и про наличие хардварного OpenGL не стоит забывать :)
ЗЫ: На всякий случай - описание управления и бонусов искать в меню Help.
Тему с багом касательно рендеринга ass-субтитров я поднял еще 21 февраля(хотя думаю сам баг существует дольше). В тот же день запостил в bugzill'у... в которую разработчики видимо даже не заглядывают. Спустя несколько дней баг исправили в той же libass, только в проекте Aegisub. Все делалось банальным присвоением font_scale_x единицы(есть там один параметр :)). Я даже об этом решил отписаться во все той-же багзилле, но реакции абсолютный ноль. Сегодня обновляясь из svn дождался таки исправления проблемы... которую исправили так же как и в Aegisub, то бишь абсолютно не разобравшись что к чему :) Просто упомянутый параметр висит в коде как нечто пришедшее из астрала, т.к. участвует в одной операции - умножение. Общий scale_x теперь умножается на единицу, смысла в этом? О_о
В общем к чему веду. Вам попадались подобные случаи скорого отклика разработчиков? :)
ЗЫ: Собственно после такого как-то «впадлы» становится сообщать об ошибках... вот так и живем, жалуясь на баги только в пределах ЛОРа :)
На комменты "ошибка" и т.д. не обращайте внимания, ровно как и на отсутствие обработки событий окромя прогона всех GetNextEvent. Документацию читал, суть понял, но хоть убей - экран пустой и ничего не рисуется :) Пробовал разобрать стандартный пример GLCarbonAGLFullScreen, но ёпт... забивать гвозди кувалдой, это кхм... Если бы интернет позволял установить XCode, я бы разобрал пример до мелких кусочков, а так... нечем компилить. Если лень смотреть мой недокод, может есть у кого простейший пример FullScreen приложения? Без разницы на каком языке.
Пускаю хакин^W MacOS X в QEMU, но порой он банально зависает, а т.к. перехватывает весь ввод на себя, то ни мышка, ни клава не реагируют, окромя системных комбинаций вроде Ctrl+Alt+Backspace. Есть идеи как убивать QEMU в момент зависания без перезагрузки иксов?
Полностью разобравшись что к чему, пришел к выводу, что таки font_scale_x остался излишеством в коде. Далее по коду в модуле ass_render.c видно единственное упоминание этого параметра:
Но в render_context.scale_x уже хранится правильное значение для рендера субтитров, соответственно font_scale_x только сбивает все. В общем собрал патч. Но т.к. увлекся занятием, решил кое-чего добавить. Довольно часто приходится смотреть широкоформатное видео, а т.к. монитор у меня с соотношением сторон 5/4(1280х1024), то охота сместить субтитры на черные полосы. Не всегда конечно, но когда субтитры довольно велики, или просто плохо контрастируют с видеорядом, это будет не лишним. В SMPlayer'е есть подобие нужного мне функционала, но там все делается обычным expand'ом, а с ним сбиваются координаты субтитров, для которых указан \pos. В самом mplayer'е есть -ass-top/bottom-marign, но для каждого видео вычислять нужные отступы - та еще морока :) Патч же добавляет опцию -ass-auto-margins, и при его использовании с -ass-use-margins, mplayer будет автоматически вычислять размер черных полос, которые следует добавить в соответствии с соотношением сторон вашего монитора. Что интересно - при -vo gl, черные полосы будут задействованы только в полноэкранном режиме(если конечно не использовать -vf-add ass). Правда пока так и не разобрался, почему эта неплохая особенность не действует в случаи с SMPlayer'ом... поэтому приходится в его настройках указывать «Сохранять субтитры на снимках экрана».
В общем, думаю кому-то будет полезно :)
ЗЫ: реакция разработчиков на баг пока не последовала... то ли суток мало, то ли выходные.
У mplayer'а отличная рендерилка сабов, но время от времени мне попадались сабы, где указанные PlayResX/PlayResY отличаются от размеров самого видеоряда. Как в итоге определил, это вызывало проблемы с позиционированием субтитров на экране(используя \pos в ass). До того как «прозрел», постоянно матерился сквозь зубы на фансаберов за коряво составленные сабы. И ничего не оставалось, как сидеть и переправлять координаты 8) Последней каплей стало «Nodame Cantbile», в котором количество «ляпов» просто зашкаливало... просмотрев сериал, и подправив координаты всеравно оставались огрехи и корявое позиционирование. Но вчера подвернулась машина с вендой, где была установлена рендерилка DirectVobSub... в общем, счастливы те, кто живет в неведении :) Начал ковыряться в исходниках mplayer'а, и чего только там не накуралесил с коррекцией аспекта, чтобы сабы созданные для 640x480 корректно ложились на видеоряд в 1280х720 или еще куда. В итоге оказалось все проще. В libass/ass_render.c в функции ass_start_frame есть строчки:
Попалась тут пачка DVD+R 8x с фееричным названием Kaktuz. Ради интереса запустил через вайн CDSpeed, и обнаружил что у диска изготовитель - Verbatim, и MID сходится - MCC 003(хотя последние вроде 004). Это типа китайская подделка, или все-же Verbatim что-то такое выпускает? Хотя насчет второго сомневаюсь, диски стоят 22грн., в то время как обычные Verbatim - 33грн... эх... хочу обратно, когда диски стоили почти вдвое дешевле :)
ЗЫ: в рубли/доллары переводить лень, цены назвал так - чисто для показа процентного соотношения.
Дома обитает кошка, которой всего полгода. За ней наблюдается весьма странное поведение. Некоторых гостей сильно избегает, и рычит О_о Не шипит, а именно рычит. Тоже происходит, если в подъезде что-то происходит - садится возле двери, слушает и в случаи сильного шороха начинает рычать. Хотя к домашним вполне адекватное и кошачье поведение. В детстве я иногда ездил в село, да и в городе играл с немалым количеством представителей кошачьих. Ни одного подобного случая не припомню. Максимум что - избегание человека, либо шипение с выпусканием когтей да клыков(хотя не, это только если собака рядом :)). А тут... еще немного, и загавкает как сторожевая собака :D
Есть у кого "петсы", и с какими оригинальными случаями/поведением? :)
вчера решил таки апдейтнуться(вернее добрался до казенного интернета и скачал :)), под апдейт попали помимо прочего ядро и дрова к видеокарте. Я все надеялся на рабочий VSync с композитом через XRender... зря правда, но больно обрадовался возросшей производительности в 2D, хотя возможно это заслуга glib2/gtk2, т.к. открытые дрова nouveau показали тот же результат после обновления этих библиотек, и в тестах Pixbuf стал замечать нагрузку на два ядра процессора. Правда может я и ошибаюсь, но факт - gtkperf стал показывать почти двукратное сокращение времени на выполнение тестов. После тестов запустил обычную поделку на OpenGL... в общем этот ужас лучше не описывать, скажу лишь что glxgears стал показывать 3fps, а это в сотню раз меньше, чем при работе Mesa в software режиме 8) И да, дрова с радостью сообщали о том, что direct rendering на месте и все расширения OpenGL тоже.
Вся фееричность глюка в том, что в моем xorg.conf была указана опция Coolbits. Вот как, скажите, можно одним только включением возможности разгона к чертям отключить 3D и перевести его в хз какой режим работы? :) Это можно, разве что, сравнивать с фееричными фиксами в дровах ATI(fglrx), по устранению зависаний в glxgears 8)
ЗЫ: пользуясь моментом, поматерюсь на ментейнеров пакетов в Arch, в который раз им впадлу указывать зависимость на определенные версии пакетов(когда-то так было с ghostscript и imagemagick), т.к. пришлось разбираться почему dmesg и те же дрова nvidia начали сыпать ошибками на ACPI, а все просто - на апдейт не был "подписан" acpid-1.0.8
В этом топике я жаловался на проблему с приводом, но видать немного преждевременно :) Решив во всем разобраться, начал перебирать разные прошивки для якобы сдохшего привода. Как выяснил, у него немного проблемы с чтением фиговых болванок - только прошивка SONY AW-G170(в OEM версии это все тот же Optiarc) версии 1.73 позволила прочитать болванку от Extreme(на всех остальных прошивках(включая новейшие официальные и родную) - ошибки чтения последних секторов). Т.к. дома есть второй комп, вытащил оттуда привод Lite-On SOHW-1673S, который отлично справился с чтением тех болваней, что запорол(вернее очень «качественно» записал) Optiarc. Как уже писал - PI Failures там зашкаливало. Правда из всего десятка дисков, у меня остался один, где было немного свободного места, и я решил дописать его LiteOn'ом... который записал информацию туда также хреново 8) Я не знаю попалась ли мне это пачка такая хорошая, но диски от SONY брать точно не буду(серия SONY DR21), хотя странно - Optiarc'овский привод ведь тоже от SONY О_о Чтоб убедиться, что привод не совсем накрылся, решил взглянуть на качество записи последних болваней от Verbatim - все ок, и за пределы нормы не вылазит(разве что график под конец немного стабильно средненький, но это сказываются упрощения в качестве конструкций относительно новых приводов).
Спасибо Gharik'у за фразу об NEC'ах и Verbatim'ах :)
Решил зайти в раздел флейма на gamedev.ru, обнаружил топик связанный с седьмой версией форточек. Убило сообщение 186:
а вот я борюсь с желанием «обратно в висту»... останавливает нечеловеческая скорость работы (помню именно по этому сидел в убунте дольше, там скорость инета в 2 раза (sic!) выше чем под вин, хотя скорее это фишка от провайдера)
Карма моя видать совсем фиговая, т.к. 2009 год начался с обнаружения
бедов на Hitachi Deskstar T7K250, за наработанных ~150 часов пока
ничего критического не случилось(кроме появления еще нескольких, когда
"гонял файлы", но потом все утряслось и интенсивная работа с файлами
никак не сказывается). Теперь вот привод начал барахлить... Были
единичные случаи когда порол болванки, но т.к. иногда попадались
болвани с дефектами, то не обращал на это особо внимание. Но вот
случаи участились - сегодня уже две болванки SONY DVD+R запорол О_о
Диски на 16 скорости уже "боюсь" писать, но запороть на 8... Есть ли
тут лоровцы, обладающим сим высе^W изделием от SONY и NEC, чего можете
сказать по поводу? :)
Пробовал кстати и обновлять firmware, но не помогло - на втором домашнем
компе запускал венду и в CDSpeed тесты качества записанных болванок
были удручающими.
Последние дрова версии 180.хх не пробовал, но во всех предыдущих XVideo(и вообще весь рендер) работает без вертикальной синхронизации, если включен композит через обычный XRender(вариант с compiz и OpenGL не катит, ибо медленней, даже на GeForce 7900GS, а все кроме теней, мне нафег не надо, да и тени там убогие :)). К тому же оба режима XVideo(Video Blitter и Video Texture) - ресайзят изображение очень фигово - заметна "зубчатость", избавлялся от неё используя вывод через -vo gl:lscale=5:cscale=5:filter-strength=0.6, но всеравно не то. Сегодня решил попробовать открытый драйвер nouveau. Во-первых, был удивлен тому, что 2D(в тесте gtkperf) работает так же быстро, как и "родной" драйвер, хотя используется EXA, на тормознутость которого сетуют штеуд-юзеры :) С композитом работает немного медленней, но зато XVideo с вертикальной синхронизацией(через Video Blitter). К тому же появился новый режим(adaptor в xvinfo) - "NV40 high quality adapter". Ресайз видео при котором, работает идеально. По стилю рендера субтитров(да, на них тоже отражается использование нового режима), это все напомнило то, что я видел у вин-юзеров О_о Тогда я думал, мол это вендовые плееры, используя DirectShow, накладывают какие-то фильтры, а тут все банально проще... Я начинаю понимать красноглазых, и чувствую следующая видеокарта будет от ATI и с открытым драйвером 8)
В результате функция lib_Init вызывается как cdecl-объявленная, и соответственно аргументы передаются неправильно - справа на лево, а нужно «слева на право». Можно ли как-то объявить lib_Init и указать что-то отличное от cdecl?
Сегодня обновился до версии 0.6.6, и был удивлен - прогрессбар перестал "прыгать" 8) Ранее открывая любой mkv-файл(за редким исключением для видео-потока отличного от h264), и кликая мышью по прогрессбару для перемотки - ползунок резко "смывался" левее/правее от указанного места. Может это я один такой везучий был, но несомненно рад тому факту, что глюк исчез :)
ЗЫ: хотя до этого апдейтнул mplayer, может там демюксер mkv пофиксили, а не в smplayer чего-то с интерфейсом.
Проблема состоит в том, что запуская бинарник из консоли, код вроде:
MyImage = image_load( "./data/image01.jpg" );
работает корректно, и файл загружается. Запуская по двойному клику, приходиться пользоваться абсолютным путем... Может я чего-то не понимаю в этой ОС? :)
Не раз встречал сообщения, мол вывод через XVideo быстрее такового за GL. Но на своей видеокарте наблюдаю обратную картину. Используя вывод через xv, видео с 1080p запинается в сложных сценах, в то время как с gl-выводом все идет нормально. К тому же, просмотр аниме сопровождается использованием субтитров, и если разрешение видео-ряда не велико, то субтитры при растягивании до 1280х1024 превращаются в сплошное мыло... Да, можно воспользоваться софтварным масштабированием всего видео-ряда, но нагрузка на процессор как-то не впечатляет :) К тому же, используя gl, на порядок лучше рисованная картинка воспринимается с доп. параметрами вроде:
lscale=5:cscale=5:filter-strength=0.6
Был бы у меня не GPRS, я бы для сравнения выложил две картинки, но тут и так закидают помидорами за "онимэ" :)
Теперь собственно о тестах производительности. Видеокарта - GeFroce 7900GS. Видео - 1080p, 1:29с., ~11.7Mbps. Декодировалось на одном ядре процессора Athlon X2 3800+(@2.4Ghz).
Бенчмарк с -vo xv
real 1m16.878s
user 1m11.735s
sys 0m0.657s
Бенчмарк с -vo gl:yuv=6:force-pbo
real 1m13.266s
user 1m11.519s
sys 0m1.383s
Сегодня(во всяком случаи у меня еще второе число :)) вышел Wine 1.1.12, в чейнджлоге указан "subpixel font rendering", может кто глянуть как оно и поделиться впечатлениями? :) У самого сейчас нет возможности обновиться...
Записывая свою первую болванку в этом году, меня ждало большое разочарование... Brasero матюгнулся и запорол диск, матерясь сквозь зубы я решил глянуть на лог, от которого тихо офигел - писалка не смогла прочитать фал О_о Подумав че за херня, попробовал скопить файл и... был окончательно повержен - скрип винта и загрузка IO на 100% говорили обо одном - винту п##дец :(
Нехотя прошелся fsck -c по /home(на котором и обнаружились траблы), вроде в блек-лист занеслось несколько бэдов. После быстренько сварганил программулину, что забивает винт файлами по 1Мб, и пытается их прочитать, все файлы что не читаются - оставляются, и можно с уверенностью сказать что файл записан поверх беда. Запустив программу, проблем вроде не возникло, значит бэды в блек-лист таки занеслись, но че-то легче от этого не становится, ведь винт всеравно сцуко может посыпацца, да и нужно проверить остальные разделы...
Может ли кто чем-то успокоить, или чего посоветовать(кроме как покупки нового винта)? :)
