четверг, 25 сентября 2014 г.

Гибкость D

image
D - молодой язык программирования с многолетней историей. Не смотря на то, что язык с таким названием появился очень давно, то, что сейчас называется D2 или просто D, появилось недавно и слабо напоминает предшественника. Рассказывать про все прелести синтаксиса, компилируемости, сборщика мусора и всего остального нет смысла, про это уже много написано. Рассказывать о том, что в языке есть, пользы мало, настоящий интерес в том, что делать с тем, чего нет? Программисту всегда хочется большего, чем язык может дать, поэтому гибкость языка - вот основной инструмент разработчика.
Для демонстрации гибкости и возможностей расширения в статье приведены несколько  реализованных на D конструкций, которые можно встретить в других языках.

понедельник, 1 сентября 2014 г.

Как не хватает деструкторов или зачем счётчик ссылок в AS3/Java/#ANY_GC_LANG#

Начиная ещё с java разработчики языков использющих сборщик мусора катрегорически отказываются реализовывать деструкторы или какие-нибудь другие инструменты для реализации RAII. Тем временем сборщик мусора решает проблему управления только одним ресурсом - памятью, выделенной в куче. Остальные ресурсы, такие как дескрипторы файлов, сокетов, сетевых портов и кучи других нужных вещей остаются безконтрольными. Вся ответственность за такие ресурсы лежит на программисте и компилятор не может ничем помочь. Мне, например, только что пришлось изобретать счётчик ссылок для совместного использования текстуры в видеопамяти. Пока ей пользовался один объект всё было просто - он знал, когда надо текстуру создать, когда удалить. Когда же захотелось пооптимизировать и пользоваться одной текстурой из нескольких графических объектов, то тупой копипаст дал неприятную ошибку. Достаточно, чтобы текстура стала не нужна только одному и она удаляется, и наплевать, что она нужна ещё в куче мест. Вечная жизнь меня тоже не устраивает, так как память на мобильниках не резиновая, а объекты появляются и пропадают часто. Вот так в 2014 году приходится решать концептуальную проблему, решённую в C++ году в 90-м если не раньше.

понедельник, 9 декабря 2013 г.

Android SDL2 crash on lock

В процессе написания игры под андроид с использованием SDL2 всплыла следующая ошибка. Периодически игра не хотела запускатсья или восстанавливаться, показывая чёреный экран. Ошибка воспроизводится при использовании дефолтного манифеста. Если во время игры нажать кнопку блокировки, то у SDL activity вызовется onDestroy(), что приведёт к завершению всего приложения и остановке потока нативного кода. Вот только вместо обычного события завершения
SDL_QUIT
вам придёт
SDL_APP_TERMINATING
Лично я до встречи с этой проблемой о таком событии вообще ничего не слышал и в документации не встречал. Поэтому корректно это событие не обрабатывалось, окно и рендер не удалялись, OpenGL контекст не закрывался и при разблокировке приложение не могло запуститься вновь.
Выхода два: обрабатывать событие как завершение приложения или вообще не закрываться при блокировке. Первый вариант не удачен, потому что это ломает парадигму использования андроидом. После разблокировки приложение должно продолжить работу. Поэтому нам надо чтобы onDestroy у активити вообще не вызывался. По этому поводу идём на stackoverflow и добавляем в манифест:
android:configChanges="orientation|keyboardHidden|screenSize"
Всё, теперь приложение будет продолжать работу, не обращая внимания на блокировку экрана.

Для англоязычных коллег / For English speaking programmers

My android SDL2 game crashed sometimes and showed black screen. If user press lock button onDestroy() method called and instead of
SDL_QUIT
event
SDL_APP_TERMINATING
event was sent to native code. I didn't know about this event because there is no any notes in documentation about it. So this event wasn't processed and renderer wasn't destroyed on application quit. You can process this event and exit correctly or add
android:configChanges="orientation|keyboardHidden|screenSize" 
 to android manifest to prevent onDestroy() method call. This solution was found at stackoverflow.

суббота, 12 октября 2013 г.

Пост ненависти


    Программисты! Люди! Перестаньте рисовать интерфейсы руками! Джависты, вас это касается в первую очередь. Сегодня поставил IntelliJ IDEA и получил прилив дикой ненависти. Какого чёрта, я могу определить программу, написанную на java c одного взляда? Почему менюшки и кнопки не системные, а какие-то свои "похожие". Это типа swing так работает? Это же ужасно. Ладно бы тема, но вот что я получил при попытке изминить размер окна: 


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


     А потом оно само ресайзится до своего минимального размера. 

понедельник, 20 мая 2013 г.

Игра Magnetic Bullets



Недавно небольшой командой мы написали простой flash физический пазл. Узнать о нём и конечно поиграть можно под катом.

понедельник, 18 февраля 2013 г.

Быстрое округление вместо медленного floor()

    Заметка для начинающих пользователей math.h в высокопроизводительных вычислениях. Судя по гуглу проблема известная, но не смотря на то, что я себя новичком в этих вопросах не считаю, о таких неприятностях не догадывался.
    Речь пойдёт о floor. Вообще говоря, описанные проблемы производительности свойственны многим функциям, но я напоролся именно  на floor. Если коротко, то floor работает медленно. Настолько медленно, что в моём сеточном методе моделирования жидкости floor оказался в первых строках профайлера. Дело в том, что floor делает множество проверок на ситуации типа NaN, inf и может изменять глобальную переменную errno для сообщения о ошибке. Всё это занимает бОльшую часть времени работы функции. Во многих задачах всё это совершенно не нужно, а нужна только  скорость. Под катом пара вариантов решения проблемы: собственный fastFloor и настроки компилятора.

воскресенье, 11 декабря 2011 г.

Запрет на создание не константных объектов


В процессе обдумывания одной безумной идеи, про которую я пока никому не расскажу, появилась интересная задачка. Необходимо запретить пользователю класса создавать не константные объекты.  Зачем? Надо. Ради спортивного интереса.
Решений тут есть несколько. Я опишу один из ненормальных, но теоретически интересных.