За фильтры спасибо. За КДПВ тоже :)
Как раз недавно кое-что из этого настраивал для себя.
Рекомендую так же ознакомиться и с другими фильтрами на той странице
Заинтриговали :) Но я не понял как именно можно посмотреть список фильтров. Страница https://ointeractive.net практически пустая, фильтров или ссылок на ней не вижу.
Данная задача мне напомнила гораздо более приближеную к реальности задачу по оценке количества уникальных объектов и алгоритм hyper log log (на хабре было, рекомендую). Там похожим образом проводиться оценка количества элементов по небольшому количеству агрерированной информации. Для алгоритма достаточно нескольких килобайт памяти для того, чтобы оценить количество уникальных объектов (например, deviceId) с погрешностью в несколько процентов.
Забавно, а я вижу разницу. И да, для меня настощие иконки чуть более приятны, чем поддельные.
Аналогия примерно следующая: если сделать американскую горку (или другой аттракцион) по форме границы иконки, то в поддельной иконке вы бы ехали прямо, а потом бы вас резко бросило бы в сторону. В настоящей же иконке граница начала поворота размыта и нет такого четкого стыка двух разных фигур. Нельзя четко определить где начался поворот.
И, кстати, серый прямоугольник за иконками на этих картинках тоже отличается. Его даже сильнее заметно, чем сами иконки. Не уверен, что это ему на пользу.
Дизайнеры эппл молодцы? Да. Захотел ли я айфон? Конечно же нет :)
Не только апдейты ради апдейтов. Они же еще свой софт обновляют вместе с прошивкой. Неотключаемый. С повышенными требованиями к железу и разрешениям. Сегодня все работает, а завтра предоставь галерее доступ к звонкам. Рекламу еще показывать за ваши же деньги. Назойливые неотключаемые уведомления иногда можно.
А версия андроида какой была такой и осталась. Вот и все секьюрити апдейты. Уж лучше вообще без них.
Мне что-то сразу не понравилось в рендеринге на MacBook 15, но не мог понять что. Теперь все стало на свои места. Всегда взгляд цеплялся при нецелочисленном масштабировании, но на макбуке из-за высокого разрешения не было понятно что именно не так.
Настроил сглаживание и масштабирование, картинка стала приятнее. Но все крупнее, на экран влазит чуть меньше. В целом так больше нравится, но надо еще поработать чтобы понять как лучше.
Я бы рекомендовал всем пользователям макбуков попробовать предложенные настройки, есть вероятность, что сделаете работу себе чуть комфортнее.
Такого вообще не помню. Обычно приложение из jar-файла просто устанавливалось и работало. Или скачивалось, устанавливалось и работало.
Реч шла о Sony Ericsson T230. На нем не было Java, была платформа Mophun.
Был у меня такой аппарат. Из-за слабой распространенности платформы на него найти софт было сложно. Не знал, что у платформы такие заморочки с цифровой подписью были уже тогда.
Помню, что в T230 было дико тормознутое меню, но игры бегали довольшо шустро. Интересно, почему так? Скорее всего, Mophun выполнялся нативно и работал быстро. Но как можно было меню телефона сделать таким медленным?
Интересно, у Вас совсем другие сценарии использования телефона и другой опыт.
Перечисленые программы нельзя назвать простыми с точки зрения управления памятью. Там постоянно надо что-то создавать и удалять и иногда что-то идет не так. Не знаю кто виноват, разработчики программ или все-таки прошивка телефона.
При написании простых игр, которыми я тогда занимался (аналоги арканоида, пакмена или примитивные гоночки) утечек достаточно легко было избежать на подавляющем большинстве телефонов.
Именно утечек памяти я почти не помню. Бывали на каких-то совсем странных телефонах.
Но, возможно, это из-за того, что мы код писали с минимальной аллокацией объектов и без циклических ссылок. Начался новый уровень — старый со всеми расурсами занулили, вызвали System.gc(), подгрузили новый уровень. До следующего уровня ничего не аллоцируем. Но это в идеале, иногда надо выводить количество очков или жизней, тогда строки надо создавать, но это обычно не много.
А еще утечки памяти мы мало ощущали из-за того, что одна из мастер-версий игры почти всегда была под Nokia Series 40. Это были самые порезаные игры, но очень важные т.к. платформа очень распространена. Процессор на этих нокиях был далеко не самый медленный, но по память была очень ограничена, не уверен что где-то было меньше, чем там. И если на каком-то другом аппарате где-то не хватало памяти, то всегда можно было что-то вырезать из игры.
Что еще про память вспомнил. На некоторых телефонах если запускать garbage collector руками каждый кадр, то падение производительности не ощущалось вообще, а если не вызывать, то было ощутимое замирание геймплея раз в несколько секунд. На других же телефонах запуск garbage collector'а каждый кадр опускало производительность до неприемлемого уровня. А если его не запускать, то не на всех телефонах это приводило к ощутимым замираниям в процессе игры. Узнать это заранее нельзя, надо тестировать каждый телефон отдельно и смотреть как лучше.
Я там ниже отписывался, напишу еще тут немного про Sony Ericsson.
Почти все из них, под которые доводилось писать были отличными аппаратами. Лучшими из всего, что было на J2ME. Не помню чтобы под них были баги. А еще в них было много оперативной памяти и они были невероятно быстрыми (относительно других J2ME аппаратов).
Они были настолько круты, что под них мы практически никогда не разрабатывали мастер-версий своих игр. Это такие первоначальные версии ПО, которые потом портировались на другие аппараты.
Почему так? Потому что если разработать игру под продвинутое железо, то ее потом не портировать на более слабые аппараты. А поскольку зоопарк девайсов был большой и нужен был максимальный охват аудитории, то смысла использовать все возможности крутых девайсов не было.
Например, когда вы создаете 'new ArrayList<String>()', то тип String в объект не записывается и узнать какого типа пришел List в рантайме нельзя.
Но если у вас, например, поле класса 'private List<String> strings' или параметр функции 'void func(List<String> strings)', то тип String в класс записывается, и его можно узнать через reflection.
Тот же hibernate вполне может связать классы Parent и Child:
public class Parent {
...
@OneToMany(...)
private List<Child> childs;
}
Не могу сказать, что отсутствие такого опыта это "к сожалению" :)
Просто разработка маленькой поделки или proof of concept, особенно на хорошем девайсе, разительно отличается от коммерческой разработки под полсотни разных девайсов.
Уверен, что современные разработчики под Android тоже могут много чего хорошего рассказать, но я практически уверен, что сегодня проблем гораздо меньше хотя бы потому, что в apk можно закинуть почти все, что нужно.
Как бывший разработчик игр под J2ME (2005-2008гг) могу рассказать обратную сторону.
Итак, compile once run everywhere — это не про J2ME. На практике приходилось делать отдельный билд почти под каждый телефон. И хорошо, если это Nokia. У них там в то время было все просто, Series 40 (128x128), Series 60 (176×208) и может немного более экзотического. Влез в 64кб jar и 215кб heap на S40 — молодец, дальше почти ни одного глюка. Sony Ericsson еще хорош. Берешь 3 почти одинаковых самсунга — у каждого свои глюки. И самсунг еще далеко не самый плохой вариант.
Итак, различия:
Экран. Телефоны имеют разные разрешения, под каждое надо отдельные картинки. Хотя бы splash screen (картинка на заставке). А еще некоторые телефоны не могли перейти в полноэкранный режим, для них не надо было рисовать soft-keys, что ломало layout. Да то же расположение кнопки назад (слева или справа) не давало делать универсальные приложения.
Нестандартные возможности. Возможность рисовать отраженные картинки не сразу была в стандартной поставке J2ME. Где-то ее не было вообще, а где-то было нестандартное API (привет Nokia). А возможность нужна, нам же а 64кб надо поместиться. Кто-то gif умеет и ему можно картинки получше пожать, а кому-то только png подавай.
Шрифты. 3 размера теоретически были везде, но по факту некоторые телефоны имели только один. Хуже другое, все шрифты были разные. Всегда где-то что-то не влазит. Иногда по ширине, иногда по высоте, иногда шрифт слишком мелкий. Надо все просмотреть, какие-то надписи укоротить, где-то перерисовать подложки под кнопки, где-то сделать скролл. Методы работы со шрифтами (например, ширину узнать) глючат на некоторых аппаратах. Выровнять шрифт по вертикали, например, на кнопке нельзя. Метод есть, но разные телефоны рисуют шрифт выше или ниже, надо подбирать для каждой серии телефонов отдельно.
Звук. Тут вообще беда. У все производителей все по разному. И форматы файлов и API. А если захотел звук и вибро одновременно, то у QA команды это отдельно дело.
Коды клавиш, насколько я помню, тоже отличались.
Тормоза. Некоторые телефоны сильно медленнее других. Под них надо переделывать физику игры или делать отрисовку экрана один раз на 2 игровых цикла. Почти нигде не стоило создавать объекты после начала уровня. И даже это не спасало от тормозов garbage collector'а на некоторых телефонах. Были заметные притормаживания, которые вообще никак не лечились.
Баги. Они повсюду. Они разные и не совместимые. Nokia (если влез по памяти) и Sony Ericsson отличные аппараты. У остальных все сильно хуже, вплоть до неверного выполнения стандартных методов. Добавляем невозможность дебага (почти на всех аппаратах) и заливку только через GPRS (на многих) и получаем крайне сомнительное удовольствие отладки. Телефон повис до того как ты успел что-то вывести на экран? Не повезло, попробуй сам угадать что поменять.
Так что нет, J2ME совершенно не такая крутая технология как нам бы того хотелось. Теоретически прикольно, а на практике та еще какаха. Но в то время другого не было. Symbian, возможно, и был неплох, но скорее всего благодаря ограниченому количеству производителей аппаратов.
Я тем телефоном уже год как не пользуюсь. Может что-то поменялось, может под разные модели телефонов разный набор программ. Это уже не принципиально, я свой выбор сделал.
Если коротко по пунктам, то:
Моего согласия на рекламу никто не спросил.
Чистильщик что-то делал в фоне, что-то куда-то передавал, периодически давал о себе знать и не отключался.
Уведомления об обновлениях, насколько я помню, смахнуть было нельзя.
Сбор статистики — это печалька нашего времени. Но китайцы это делают нагло, беспринципно и им нельзя даже плохой отзыв на маркете поставить — все вшито в систему и на маркете их программ нет.
И, просто интересно, какие разрешения на Вашем телефоне у стандартной галереи? GPS, телефон? Если разрешения отобрать, то приложение не запустится или это уже поправили?
Спасибо, но нет. Я на китайскую технику подключеную к интернету больше не поведусь.
Древний Redmi 3s поначалу даже нравился. Но с обновлениями он становился говнянее и говнянее.
Куча обновлений MIUI и ни одного обновления самого Android.
Выпиливание нужных функций (например, убрали возможность уменьшения экрана для работы одной рукой).
Обещают улучшеный контроль прав доступа, а по факту для их же приложений ничего отключить нельзя.
После обновления придется соглашаться с новыми правами доступа для стандартных приложений. Или давай права на все или не работает галерея.
Вшитое какое-то говно, чистильщик собирает статистику, назойливо предлагает что-то почистить и это не отключить.
Реклама в моем купленом устройстве — это вообще за гранью.
И еще, не обновлять тоже нельзя. Уведомление назойливое и его не убрать.
Very High на скриншотах не только выглядит иначе по цветам (мне не нравится). Там еще кусты пропали по пальмами. На остальных скриншотах они есть, даже в самом простом качестве.
P.S. в игру не играл, может там, конечно пришел NPC и скосил траву, на я сомневаюсь :)
Так ведь вопрос не в ROM картриджа. Половину адресов отдать в картридж это ок. Когда ROM память подешевела началось с мапперами, банками памяти и прочим. Тут-то как раз все понятно, решение правильное и логичное.
Вопрос в остальных 32кб адресного пространства. RAM памяти-то всего 2кб. Конечно, не 128 байт, как у Atari 2600, например. Но, как мне кажется, в 83 году можно было бы и побольше поставить. Специально сравнил со спектрумом, у него в 82 было 16-48кб.
А еще видеопамять. Там тоже интересная архитектура. 2кб RAM для тайлов + 256 байт под спрайты в приставке и 8кб адресуется ROM на картридже. И в целом ок, но у видеоподсистемы NES такая ахитектура, что ей по-хорошему нужно 4кб под тайлы. Без этого довольно сложно делать игры, в которых прокрутка экрана по двум осям. Вопрос был в том, имел ли смысл экономить эти 2кб?
Хотя все-же еть предположение почему могло иметь смысл экономить. Возможно, в то время не было доступных микросхем с большим объемом памяти. В этом случае надо было бы ставить больше микросхем, усложнять разводку и т.п. Но это только предположение, я не знаю как было на самом деле.
Спасибо, было интересно почитать как устроены старые компьютеры. В последнее время меня интересует эта тема. Минимализм и экономия порой впечатляют.
Архитектура NES впечатляет и удивляет одновременно: неужели в 83 году имело смысл так экономить память? Спектрум в 82 имел 16-48кб памяти и это была low-end машина.
Game Boy и Sega Master System по своему интересны: в видеопамять все не помещалось, пришлось порезать количество спрайтов/тайлов (в Game Boy) или размер карты тайлов (Sega Master System).
Видеоподсистема Atari 2600 вообще где-то за гранью разумного. Вроде бы и понимаешь, почему было так сделано, но все равно ощущение какой-то жести и садизма для разработчиков.
Кстати, для любителей поиграть на эмуляторе спектрума могу порекомендовать отличную для этого дела ретро-железку Nintendo DS. Она просто идеально подходит для эмуляции:
Экраны 256х192, как раз то, что надо
На верхнем экране игра, на нижнем клавиатура с резистивным тач скрином
Спасибо за статью, было интересно почитать про подход.
На картинке, где сравнивается методы аппроксимации функций гравитации, хотелось бы увидеть еще катринку с честно просчитаной гравитацией. Она вообще сильно отличается от интегральной со взвешенными координатами? У меня такое подозрение, что отличия должны быть, т.к. на картинке все-таки заметны концентрические окружности, которых скорее всего не должно быть на честно просчитаной картинке.
За фильтры спасибо. За КДПВ тоже :)
Как раз недавно кое-что из этого настраивал для себя.
Заинтриговали :) Но я не понял как именно можно посмотреть список фильтров. Страница https://ointeractive.net практически пустая, фильтров или ссылок на ней не вижу.
Данная задача мне напомнила гораздо более приближеную к реальности задачу по оценке количества уникальных объектов и алгоритм hyper log log (на хабре было, рекомендую). Там похожим образом проводиться оценка количества элементов по небольшому количеству агрерированной информации. Для алгоритма достаточно нескольких килобайт памяти для того, чтобы оценить количество уникальных объектов (например, deviceId) с погрешностью в несколько процентов.
Забавно, а я вижу разницу. И да, для меня настощие иконки чуть более приятны, чем поддельные.
Аналогия примерно следующая: если сделать американскую горку (или другой аттракцион) по форме границы иконки, то в поддельной иконке вы бы ехали прямо, а потом бы вас резко бросило бы в сторону. В настоящей же иконке граница начала поворота размыта и нет такого четкого стыка двух разных фигур. Нельзя четко определить где начался поворот.
И, кстати, серый прямоугольник за иконками на этих картинках тоже отличается. Его даже сильнее заметно, чем сами иконки. Не уверен, что это ему на пользу.
Дизайнеры эппл молодцы? Да. Захотел ли я айфон? Конечно же нет :)
Не только апдейты ради апдейтов. Они же еще свой софт обновляют вместе с прошивкой. Неотключаемый. С повышенными требованиями к железу и разрешениям. Сегодня все работает, а завтра предоставь галерее доступ к звонкам. Рекламу еще показывать за ваши же деньги. Назойливые неотключаемые уведомления иногда можно.
А версия андроида какой была такой и осталась. Вот и все секьюрити апдейты. Уж лучше вообще без них.
Лучше бы плавную прокрутку в таблицах сделали.
Мне что-то сразу не понравилось в рендеринге на MacBook 15, но не мог понять что. Теперь все стало на свои места. Всегда взгляд цеплялся при нецелочисленном масштабировании, но на макбуке из-за высокого разрешения не было понятно что именно не так.
Настроил сглаживание и масштабирование, картинка стала приятнее. Но все крупнее, на экран влазит чуть меньше. В целом так больше нравится, но надо еще поработать чтобы понять как лучше.
Я бы рекомендовал всем пользователям макбуков попробовать предложенные настройки, есть вероятность, что сделаете работу себе чуть комфортнее.
Реч шла о Sony Ericsson T230. На нем не было Java, была платформа Mophun.
Был у меня такой аппарат. Из-за слабой распространенности платформы на него найти софт было сложно. Не знал, что у платформы такие заморочки с цифровой подписью были уже тогда.
Помню, что в T230 было дико тормознутое меню, но игры бегали довольшо шустро. Интересно, почему так? Скорее всего, Mophun выполнялся нативно и работал быстро. Но как можно было меню телефона сделать таким медленным?
Интересно, у Вас совсем другие сценарии использования телефона и другой опыт.
Перечисленые программы нельзя назвать простыми с точки зрения управления памятью. Там постоянно надо что-то создавать и удалять и иногда что-то идет не так. Не знаю кто виноват, разработчики программ или все-таки прошивка телефона.
При написании простых игр, которыми я тогда занимался (аналоги арканоида, пакмена или примитивные гоночки) утечек достаточно легко было избежать на подавляющем большинстве телефонов.
Именно утечек памяти я почти не помню. Бывали на каких-то совсем странных телефонах.
Но, возможно, это из-за того, что мы код писали с минимальной аллокацией объектов и без циклических ссылок. Начался новый уровень — старый со всеми расурсами занулили, вызвали System.gc(), подгрузили новый уровень. До следующего уровня ничего не аллоцируем. Но это в идеале, иногда надо выводить количество очков или жизней, тогда строки надо создавать, но это обычно не много.
А еще утечки памяти мы мало ощущали из-за того, что одна из мастер-версий игры почти всегда была под Nokia Series 40. Это были самые порезаные игры, но очень важные т.к. платформа очень распространена. Процессор на этих нокиях был далеко не самый медленный, но по память была очень ограничена, не уверен что где-то было меньше, чем там. И если на каком-то другом аппарате где-то не хватало памяти, то всегда можно было что-то вырезать из игры.
Что еще про память вспомнил. На некоторых телефонах если запускать garbage collector руками каждый кадр, то падение производительности не ощущалось вообще, а если не вызывать, то было ощутимое замирание геймплея раз в несколько секунд. На других же телефонах запуск garbage collector'а каждый кадр опускало производительность до неприемлемого уровня. А если его не запускать, то не на всех телефонах это приводило к ощутимым замираниям в процессе игры. Узнать это заранее нельзя, надо тестировать каждый телефон отдельно и смотреть как лучше.
Я там ниже отписывался, напишу еще тут немного про Sony Ericsson.
Почти все из них, под которые доводилось писать были отличными аппаратами. Лучшими из всего, что было на J2ME. Не помню чтобы под них были баги. А еще в них было много оперативной памяти и они были невероятно быстрыми (относительно других J2ME аппаратов).
Они были настолько круты, что под них мы практически никогда не разрабатывали мастер-версий своих игр. Это такие первоначальные версии ПО, которые потом портировались на другие аппараты.
Почему так? Потому что если разработать игру под продвинутое железо, то ее потом не портировать на более слабые аппараты. А поскольку зоопарк девайсов был большой и нужен был максимальный охват аудитории, то смысла использовать все возможности крутых девайсов не было.
На самом деле это правда лишь от части.
Например, когда вы создаете 'new ArrayList<String>()', то тип String в объект не записывается и узнать какого типа пришел List в рантайме нельзя.
Но если у вас, например, поле класса 'private List<String> strings' или параметр функции 'void func(List<String> strings)', то тип String в класс записывается, и его можно узнать через reflection.
Тот же hibernate вполне может связать классы Parent и Child:
Не могу сказать, что отсутствие такого опыта это "к сожалению" :)
Просто разработка маленькой поделки или proof of concept, особенно на хорошем девайсе, разительно отличается от коммерческой разработки под полсотни разных девайсов.
Уверен, что современные разработчики под Android тоже могут много чего хорошего рассказать, но я практически уверен, что сегодня проблем гораздо меньше хотя бы потому, что в apk можно закинуть почти все, что нужно.
Как бывший разработчик игр под J2ME (2005-2008гг) могу рассказать обратную сторону.
Итак, compile once run everywhere — это не про J2ME. На практике приходилось делать отдельный билд почти под каждый телефон. И хорошо, если это Nokia. У них там в то время было все просто, Series 40 (128x128), Series 60 (176×208) и может немного более экзотического. Влез в 64кб jar и 215кб heap на S40 — молодец, дальше почти ни одного глюка. Sony Ericsson еще хорош. Берешь 3 почти одинаковых самсунга — у каждого свои глюки. И самсунг еще далеко не самый плохой вариант.
Итак, различия:
Так что нет, J2ME совершенно не такая крутая технология как нам бы того хотелось. Теоретически прикольно, а на практике та еще какаха. Но в то время другого не было. Symbian, возможно, и был неплох, но скорее всего благодаря ограниченому количеству производителей аппаратов.
Под mac есть что-то похожее?
Я тем телефоном уже год как не пользуюсь. Может что-то поменялось, может под разные модели телефонов разный набор программ. Это уже не принципиально, я свой выбор сделал.
Если коротко по пунктам, то:
Моего согласия на рекламу никто не спросил.
Чистильщик что-то делал в фоне, что-то куда-то передавал, периодически давал о себе знать и не отключался.
Уведомления об обновлениях, насколько я помню, смахнуть было нельзя.
Сбор статистики — это печалька нашего времени. Но китайцы это делают нагло, беспринципно и им нельзя даже плохой отзыв на маркете поставить — все вшито в систему и на маркете их программ нет.
И, просто интересно, какие разрешения на Вашем телефоне у стандартной галереи? GPS, телефон? Если разрешения отобрать, то приложение не запустится или это уже поправили?
Спасибо, но нет. Я на китайскую технику подключеную к интернету больше не поведусь.
Древний Redmi 3s поначалу даже нравился. Но с обновлениями он становился говнянее и говнянее.
Куча обновлений MIUI и ни одного обновления самого Android.
Выпиливание нужных функций (например, убрали возможность уменьшения экрана для работы одной рукой).
Обещают улучшеный контроль прав доступа, а по факту для их же приложений ничего отключить нельзя.
После обновления придется соглашаться с новыми правами доступа для стандартных приложений. Или давай права на все или не работает галерея.
Вшитое какое-то говно, чистильщик собирает статистику, назойливо предлагает что-то почистить и это не отключить.
Реклама в моем купленом устройстве — это вообще за гранью.
И еще, не обновлять тоже нельзя. Уведомление назойливое и его не убрать.
В общем, для меня xiaomi все :(
Very High на скриншотах не только выглядит иначе по цветам (мне не нравится). Там еще кусты пропали по пальмами. На остальных скриншотах они есть, даже в самом простом качестве.
P.S. в игру не играл, может там, конечно пришел NPC и скосил траву, на я сомневаюсь :)
Так ведь вопрос не в ROM картриджа. Половину адресов отдать в картридж это ок. Когда ROM память подешевела началось с мапперами, банками памяти и прочим. Тут-то как раз все понятно, решение правильное и логичное.
Вопрос в остальных 32кб адресного пространства. RAM памяти-то всего 2кб. Конечно, не 128 байт, как у Atari 2600, например. Но, как мне кажется, в 83 году можно было бы и побольше поставить. Специально сравнил со спектрумом, у него в 82 было 16-48кб.
А еще видеопамять. Там тоже интересная архитектура. 2кб RAM для тайлов + 256 байт под спрайты в приставке и 8кб адресуется ROM на картридже. И в целом ок, но у видеоподсистемы NES такая ахитектура, что ей по-хорошему нужно 4кб под тайлы. Без этого довольно сложно делать игры, в которых прокрутка экрана по двум осям. Вопрос был в том, имел ли смысл экономить эти 2кб?
Хотя все-же еть предположение почему могло иметь смысл экономить. Возможно, в то время не было доступных микросхем с большим объемом памяти. В этом случае надо было бы ставить больше микросхем, усложнять разводку и т.п. Но это только предположение, я не знаю как было на самом деле.
Спасибо, было интересно почитать как устроены старые компьютеры. В последнее время меня интересует эта тема. Минимализм и экономия порой впечатляют.
Кстати, для любителей поиграть на эмуляторе спектрума могу порекомендовать отличную для этого дела ретро-железку Nintendo DS. Она просто идеально подходит для эмуляции:
Спасибо за статью, было интересно почитать про подход.
На картинке, где сравнивается методы аппроксимации функций гравитации, хотелось бы увидеть еще катринку с честно просчитаной гравитацией. Она вообще сильно отличается от интегральной со взвешенными координатами? У меня такое подозрение, что отличия должны быть, т.к. на картинке все-таки заметны концентрические окружности, которых скорее всего не должно быть на честно просчитаной картинке.