Комментарии 23
А вы специально не использовали gesture recognizers в пользу touchesBegan/Moved/etc? И семафор вроде можно было бы заменить dispatch_group, как мне кажется.
тут по-моему __block лишний, потому что dispatch_semaphore_t это всё равно указатель
можно ведь использовать уведомления UIApplicationDidEnterBackgroundNotification и
UIApplicationDidBecomeActiveNotification из NSNotificationCenter?
__block dispatch_semaphore_t block_sema = _inflightSemaphore;
тут по-моему __block лишний, потому что dispatch_semaphore_t это всё равно указатель
Для этого я пробросил вызовы applicationDidEnterBackground и applicationWillEnterForeground из AppDelegate в RenderViewContoller.
можно ведь использовать уведомления UIApplicationDidEnterBackgroundNotification и
UIApplicationDidBecomeActiveNotification из NSNotificationCenter?
Спасибо за отклик! Да, специально не использовал жесты, для управления камерой это оказалось даже проще. Да, заменить можно, но в данном конкретном случае использование недвоичного семафора мне показалось более уместным. dispatch_group я бы скорей использовал в ситуации, когда надо синхронизировать разнородные таски.
Несмотря на то, что dispatch_semaphore_t — указатель, работаем мы с ним как с объектом (я к тому, что указатель это его внутренняя организация). __block здесь носит информационный характер и говорит о том, что объект будет изменяться внутри блока.
Можно использовать и нотификации, более того, так и было в одной из демок Apple)) Так как контроллер у нас всегда один, я решил, что перегружать код контроллера подпиской/отпиской в центре нотификаций — лишнее
Несмотря на то, что dispatch_semaphore_t — указатель, работаем мы с ним как с объектом (я к тому, что указатель это его внутренняя организация). __block здесь носит информационный характер и говорит о том, что объект будет изменяться внутри блока.
Можно использовать и нотификации, более того, так и было в одной из демок Apple)) Так как контроллер у нас всегда один, я решил, что перегружать код контроллера подпиской/отпиской в центре нотификаций — лишнее
объект будет изменяться внутри блока
мне это кажется каким-то вольным трактованием назначения __block. без этого модификатора у вас получается как будто бы const void *block_sema, но это ведь не мешает менять что-то разыменовывая указатель или вызывать методы объекта
Ваше право считать так) В том, что __block в данном случае можно убрать без последствий, я с вами согласен.
Я просто хотел указать на то, что вы вроде как хотели пометить переменную так, чтобы было ясно, что ей управляют внутри блока – а получилось так, что сторонний разработчик настораживается и ищет место, где изменяется само значение этой переменной. Такого нет. Почему тогда __block? Не понятно. Вдруг это сделано специально, но я не могу понять почему? Надо разбираться. Выясняется, что __block использован просто как маркер, который в «авторском» смысле понимает только автор. На мой взгляд, тут больше подойдет комментарий, а еще лучше – вообще ничего не надо. Название у переменной и так соответствует её использованию.
Спасибо, за конструктивное замечание, убедили) Это обучающий материал, поэтому мнение обучаемых особенно ценно. В следующей серии, если она будет, обязательно исправлю это.
Ещё я бы _currentUniformBufferIndex передавал аргументом в encodeRenderCommands:commend:startIndex:endIndex и использовал NSInteger вместо int
Вообще с этими семафорами всё как-то сложно выглядит, ну прям вообще. Я бы использовал concurrent NSOperationQueue и более человечные addOperations:waitUntilFinished: – так оно как-то человечнее выглядит и можно распараллеливать на сколько угодно частей, назначать зависимости, если вдруг такое нужно. Мне кажется, можно половину синхронизаций попросту убрать, отрефакторив взаимодействие между компонентами. Я вообще тут просто мимо проходил, графикой не интересуюсь, но может быть попробую сделать на свой лад и покажу.
Вообще с этими семафорами всё как-то сложно выглядит, ну прям вообще. Я бы использовал concurrent NSOperationQueue и более человечные addOperations:waitUntilFinished: – так оно как-то человечнее выглядит и можно распараллеливать на сколько угодно частей, назначать зависимости, если вдруг такое нужно. Мне кажется, можно половину синхронизаций попросту убрать, отрефакторив взаимодействие между компонентами. Я вообще тут просто мимо проходил, графикой не интересуюсь, но может быть попробую сделать на свой лад и покажу.
и зум со скроллом кривые :) я сначала подумал, что у скролла специально такая «инерция» сделана, но с зумом сразу всё стало понятно. проблема в том, как вы считаете новую позицию камеры
currentDistance += delta * ZOOM_SPEED;
это неправильно, надо так же как и расстояние, запоминать стартовую дистанцию и прибавлять дельту именно к ней
currentDistance += delta * ZOOM_SPEED;
это неправильно, надо так же как и расстояние, запоминать стартовую дистанцию и прибавлять дельту именно к ней
Ок, жду с нетерпением вашего форка :)
по-моему, должно быть что-то типа такого, там тоже есть свои баги, но я не разобрался в деталях как там currentDistance работает
т.е. когда я начал жест на расстоянии x, раздвинул до 2x – должно увеличиться условно в 2 раза. и если я не отпуская пальцев начну зумить до 1.5x – то масштаб сразу должен начать убавляться, а не продолжать увеличиваться в сторону 3x
и у сколла такая же кривая «инерция»
void ArcballCamera::updateZooming(const float d)
{
if (isZooming) {
const float delta = lastDistance - d;
currentDistance = delta * 0.1f;
}
}
т.е. когда я начал жест на расстоянии x, раздвинул до 2x – должно увеличиться условно в 2 раза. и если я не отпуская пальцев начну зумить до 1.5x – то масштаб сразу должен начать убавляться, а не продолжать увеличиваться в сторону 3x
и у сколла такая же кривая «инерция»
Для Metal инженеры Apple придумали собственный язык шейдеров, который не особо сильно отличается от HLSL, GLSL и Cg.Почему? Фатальный недостаток?
Нет никакого недостатка, я бы даже назвал эту схожесть языков достоинством) Правда я не уверен, что правильно понял ваши вопросы
Если серьёзно, в этом и заключается вопрос: если языки настолько схожи, в чём была потребность изобретать новый язык, а не использовать имеющийся? И в чём достоинство наличия нескольких схожих языков, которые решают одну и ту же задачу?
О мотивации Apple я могу только догадываться, как вы понимаете. Думаю немаловажным фактором было наличие «собственного» языка, это в духе компании. Для себя я не нашел в этом языке фич, которых бы мне сильно не хватало в других языках. Да, в Metal Shading Language есть перегрузка функций и шаблоны, удобно, но не более того. Была попытка сблизить программы GPGPU и шейдеры синтаксически, удобно, но не революция.
Если уж говорить о моем сугубо личном мнении, языку шейдеров давно нужна стандартизация, один язык, который бы использовался везде.
Если уж говорить о моем сугубо личном мнении, языку шейдеров давно нужна стандартизация, один язык, который бы использовался везде.
В мире, где вся разработка максимально облегчается, Эппл решила пойти по принципу — пишите тонны кода для вывода кубика.
Да еще и с совершенно своим подходом. Преимущество перед OpenGL-то есть?
Да еще и с совершенно своим подходом. Преимущество перед OpenGL-то есть?
Те преимущества, что мне показались значимыми, я обозначил во «Вступлении». Из них я бы особенно выделил хорошую поддержку многопоточности. Мне доводилось реализовывать многопоточный рендеринг на Direct3D 11 API при помощи deferred-контекста, так что сравнивать есть с чем) Вопрос, что будет с Metal, когда выйдет Direct3D 12, в котором обещают схожую гибкость, но пока его нет, работаем с тем, что имеем.
Сразу наткнулся на
error: can't exec 'metal' (No such file or directory)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основы программирования графики на Apple Metal: Начало