All streams
Search
Write a publication
Pull to refresh
126
0
Send message


День 200-ый
Посетители столовой с ужасом находят, что, чтобы насыпать соли, они должны подойти к официанту, предьявить паспорт, получить специальный 8-значный одноразовый код к солонке. Для получения перца процедуру следует повторить.

А теперь представьте, что бы натворил ForhaxeD, если бы это была бы игра с открытым исходным кодом… Ведь речь в статье не о серверной статье (где безусловно всё надо проверять), а о клиентской.

Кстати, такие «недочёты» в клиентах могут специально существовать для привлечения создателей модов, что в свою очередь может сильно повысить популярность и среди игроков.
en.wikipedia.org/wiki/Non-English-based_programming_languages

По слову japanese очень много вариантов. Правда, ссылки уводят на японскую википедию, но a вы чего хотели? :)
<code>Продаётся

 место

  для 

 вашей

рекламы :)</code>
Комментарии на норвежском? Да шоб таким программистам пришлось такой код разбирать:
/**
* これはクラスのコメント
*/
public class FooClass implements Fooable {

/**
* オブジェクトのインスタンスを作成する
*/
public FooClass() {

}

...
}
Что-то у вас совсем не так с хинтингом. Вот так выглядит с freetype:

А вот для регулярного текста он действительно мало подходит из-за того, что он получился condensed.
Есть клиент Tribler, о нём на хабре ещё в 2008 писали. И хоть этот клиент и не убил трекеры, но по прежнему выпускает новые версии, что само по себе заслуживает поощрения (хотя сейчас Tribler нормально работает с трекерами, если их указать).
Авторские права на копию в высоком разрешении принадлежит музею.
А Питер Брейгель даже не догадывался! Никогда не поверю, что Ализар этого не видел: Bridgeman Art Library против Corel.
Плохая инфографика, чем не прекрасный повод размять шею?
Пока рано вроде. В статье ссылка на метапедию, она существует всегда и на ней всегда много страниц о планируемых проектах. А вот домен wikidata.org пока редиректит на википедию.

Не совсем в тему: было бы круто иметь википедию на каком-нибудь из языков представления знаний.
Блин, а ведь так ожидал увидеть под катом что-нибудь такое:
С помощью нехитрых манипуляций с localStorage можно убрать себе имя и приделать аватарку любого npc или моба :3
Эмм, и в каком месте там 3000 отсканированных изображений? Начал склеивать, в галерее только 22 общих страницы + «The foundation of the general theory of relativity commons» на 45 страниц…
but if you ever actually do this, then…

...WAT…
Проблема не столько в размере (вспомните твиттер с сообщениями в 140 символов и js на полмегабайта), сколько в самой технологии перевода. Emscripten не пытается выследить логическую структуру кода (циклы, ветвления, использование динамической памяти и т. д.), а берёт ассемблероподобное представление llvm и заменяет почти каждую инструкцию на соответствующий код в Javascript. Естественно, с эмуляцией стека, динамического выделения памяти и т. д.

Но проделанная работа определённо полезна как минимум для repl.it и обучалок вида tryhaskell.org и tryruby.org
Но неужели все понятно и нет вопросов?

Лично у меня мозг свернулся уже на второй статье D:
В принципе, если интересуют инструменты с открытым исходным кодом, такое можно запросто сделать в узловом редакторе Blender.

Боке на этом изображении не видно, но среди есть куча узлов на все случаи жизни. Блюр тут даже не пригодился из-за наличия defocus, а вот тона подкрутить или перспективу — с этим любую сцену можно превратить в игрушку :)

Маску тоже можно генерировать процедурно, просто мне лень было в соседнюю панель лезть. Но любой человек, работавший с композерами подтвердит, что Tilt-shift по предложенной модели делается в полпинка (тут не могу не вспомнить эту статью)
С этого и стоило начинать, что вы работаете на Фаствидео и описанный алгоритм реализован в программе Fastvideo Lab, которая распространяется в аппаратном комплексе. Вы же написали «Программное обеспечение для сжатия изображений на видеокарте, описанное в статье, является результатом предварительных исследований и пока не существует в виде законченного коммерческого продукта», хотя Fastvideo Lab обещает тот же Baseline JPG с тем же пиком в 3,4 ГБ/c, что и здесь в статье. Традиция «К сожалению, проверить эти данные нет возможности за исключением кодера IPP-7, который сам сообщает о времени кодирования, поэтому просто поверим написанному» продолжается.
Вот со страницы поиска:

1 результат: www.eecg.toronto.edu/~moshovos/CUDA08/arx/JPEG_report.pdf — расписано всё по шагам, местами ускорение *180

2 результат: www.fastvideo.ru/info/cuda/cuda-jpeg-encoder.htm — снова гигантские скорости в 2 ГБ/c на GTX 580. Не знаю, что они замеряли, но очень похоже на ваш результат.

5 результат: cuj2k.sourceforge.net/Benchmark.html — эти тестируют jpeg и jpeg2000 на 280GTX, не очень сравнивается с GTX 580.

Ну и так далее. Как это сравнить между собой? Скачать все варианты и протестировать на одном оборудовании и протестировать по одинаковым критериям. С чего и я начал: хороши не те программы, которые у кого-то быстро работают, а которые можно скачать и использовать самому.
Кстати, не обязательно double. Алгоритм DCT можно реализовать через целые числа, что как раз и делают многие кодировщики (cjpeg). Двойная польза: гарантировано побайтовое сходство изображений, закодированных на разных архитектурах и это невероятно важно для embedded без/с медленным fpu. Есть ещё и быстрый целочисленный DCT: менее точный, но тоже обеспечивает побайтовое сходство. На обычных x86 процессорах быстрее процентов на 5, чем обычный целочисленный алгоритм.

Впрочем, у меня есть подозрение, что double в промежуточных операциях не дают в итоге результат отличный от float. По крайней мере double dct не реализуют библиотеки с libjpeg-совместимым api (кандидат на замену — libjpeg-turbo, пользователи Gentoo знают). Если бы это хоть на йоту улучшало результат, такой double dct хотя бы предусмотрели в api). Но это только предположение.

Information

Rating
Does not participate
Registered
Activity