везде писать lineto(scalex*x + deletax, scaley*y + deletay)
А зачем вообще так писать? Зачем вообще использовать голые lineto, без оберток для иерархий виджетов? Код жестов работает так, как я описал выше. После чего готовые параметры смещения, поворота(?) и масштабирования меняются у корневого узла. Дальше зависит от того, что конкретно у нас за окружение. Если это UI в котором поворот невозможен, позиции дочерних элементов обновляются простой арифметикой от родительских на стадии обновления Layout. Если что-то более навороченное или встроенное в игру, то тоже же самое делается уже матрицами. Но ни человек который пишет жесты, ни человек который дергает примитивы и анимации ничего из этого не видит.
отдельно так же продумывать кейсы с переводом экранных координат в ценовые
А как использование матриц от этого освобождает? У нас фактически есть две разные системы координат, необходимость перевода неизбежна. И в обоих случаях он скрыт за вызовом функций.
Выяснил, что за пол-года на работе я узнал больше, чем они за 4 года учёбы... Такие дела...
Не удивительно. Один месяц работы это уже 160 часов работы с реальным кодом на реальных задачах, с опытными менторами и т.д. и т.п.. Это и количественно и качественно превосходит учебные часы программирования за семестр ВУЗа.
Уножение на матрицу - перевод из одной системы в другую.
Спасибо, кеп. Еще раз, всю математику в нашем движке писал я. А на стороне скриптов были видны только готовые setPosition, setScale, setRotation, и setParent/setChild для иерархии узлов.
То что ваш скриптер не пересчитывал матрицу из жестов - просто значит что это делал кто то другой в команде, или что это было уже зашито в библиотеку.
Никто не пересчитывал матрицу из жестов, потому что код жестов ее не требует. Ниже я привел описание того, как работают жесты, а выше пример кода, который делает масштабирование стабильным к изображению.
По жестам - задача сводится к следующему - вы взяли пальцем точку и потянули. По сути вам нужно определить какая матрица нужна что бы умножив вектор на нее получить другой вектор
Зачем? Я взял одну точку, потянул, а код посмотрел на сколько пикселей сдвинулась координата и ровно на столько же сдвинул объект на экране. Так работает panning. Проверяя область нажатия и скорость точки мы можем делать swipe.
Возьмем пример сложнее. Пользователь использует тачскрин и создает пару нажатий, соответственно мы получаем две точки. По среднешкольной программе используем теорему Пифагора, чтобы понять как изменяется расстояние между точками относительно позиции в начале жеста, и если оно достаточно отличается от порога - делаем scale. За центр масштабирования возьмем геометрическое среднее двух точек, а дальше как в участке кода что я скинул выше. Если этот центр движется по экрану, можем делать альтернативное panning действие, например скроллинг. По среднешкольной же программе мы можем определить и изменение угла отрезка образованного точками по отношению к экрану, и таким образом сделать жест поворот.
Не бог весть что, но есть сомнения что понимания как работают матрицы и вектора знает любой слушатель курсов/птушник.
Линейная алгебра это один из самый лайтовых математических предметов после школьной программы, у нас векторы вообще дали в рамках подготовки к вступительным экзаменам в техникум после 9-го класса, хотя они там были вообще не нужны. Но что важнее, фактически мы наблюдаем что на движке Unity каждый день появляются сотни проектов от школьников (буквально) и любителей, в которых активно применяются и матричные трансформации, и кватернионы, и что-то я сомневаюсь что они во всем этом разбираются. Для них прокинуты готовые функции создающие примитивы трансформаций с человекочитаемым названием, им не нужно знать как это работает под капотом чтобы решать практические задачи.
Вам же известны такие понятия как экранные координаты, мировые координаты, как происходит переход между ними?
Они известны мне, как писавшему на С++ наш двухмерный игровой движок. Скриптер который делал анимации, жесты, и т.д. даже слова такого как матрица не знал. И это кстати был единственный раз за 15 лет моей жизни с программированием, когда мне нужно было написать умножение матриц в реальной задаче.
А все манипуляции с графиком - это исключительно изменение системы экранных координат - надо пересчитать матрицу.
Не нужны никакие матрицы чтобы график по экрану ворочать, потому что у него из трансформаций только смещений и масштабирование.
вы умножаете вектор мышки на обратную матрицу и получаете из координат мышки дату и цену в одну операцию.
Можете пожалуйста показать ссылой на гитхаб хоть один пример, где в UI без поворота уножают вектор мышки на обратную матрицу? Я такого никогда еще не видел.
В упор не понимаю зачем нужны аж матрицы для жестов. В прошлом был опыт написания игр-квестов для мобильных платформ, где были все жесты которые только можно себе представить, и ни один из них никто не делал матрицами.
Вы обратили внимание, что если на кластерном графике сделать масштабирование колесиком, то приближается именно то место, на котором курсор?
Это мифы из кинофильмов. Не бывает "простой иньекции" и не засыпают за секунды от тряпочки с хлороформом, там анастезиолог заморачиваться должен, и удачи что-то вколоть или затруднить дыхание не разбудив пациента.
Я знаю одного человека, который себе в квартиру на стену повесил дешевый аппарат для измерения силы удара, и бьет в него каждый день. Иногда головой (я не шучу).
Как-то раз в 2021м помог со старым ноутбуком, снес три лишних браузера и поставил дату в винде на актуальную. После перезагрузки слетел пароль на скайпе и я предложил владелице (бабулька) ввести его сейчас, чего она с нескольких попыток сделать не смогла. Потом мне несколько дней звонили и обвиняли что я собирался взломать их сверхценный скайп, пока в черный список не добавил.
Для отжиманий лучший вариант это упор на возвышенностях (опорах, блинах, брусьях и т.д.), что позволяет опуститься ниже и растянуть грудные сильнее. А руки лучше ставить так, чтобы было удобно и ничего не болело.
Смотрю каналы: Mike Israetel, Milo Wolf, Dr. Pak, Menno Henselmans. Ну и еще ряд более научно-популярных, но ссылающихся на исследования - Jeff Nippard, Jeremy Ethier, House of Hypertrophy, Flow High Performance, и т.д.
Точно нет. В положении лежа когда бицепс растянут руки почти параллельны полу, сила тяжести противоположна направлению движения, напряжение максимально. В положении стоя когда бицепс растянут руки просто висят, сила тяжести перпендикулярна направлению движения, напряжение в этот момент минимально.
То есть если человек приседает со штангой и что-то пошло не так, то бросить штангу не всегда удастся. А на тренажёре можно бросить упражнение практически в любой момент.
Смотря какой тренажер и смотря какое упражнение, кстати. Например в жиме лежа со штангой если вдруг закончились силы можно попробовать наклонить штангу в сторону. При аналогичной проблеме с жимом на тренажере Смита если никого нет рядом можно и окочуриться, есть реальные примеры. А можно и просто получить штангой по шее, примеры тоже есть. Или знаменитые ноги кузнечика на тренажере для жима ногами.
Эмм, нет. Undefined Behavior это конкретный термин из конкретных языков программирования, который специальным образом обрабатывается компиляторами, для чего он собственно и введен. Компилятор C/C++ исходит из того, что в программе не может быть Undefined Behavior, что позволяет ему для оптимизации игнорировать все инварианты в которых он возникает. Если бы == для FP был Undefined Behavior, компилятор мог бы просто удалить весь код который зависит от вычислений в которых он встречается под предлогом "так быстрее". При этом последствия для программ полагающихся на код с UB могут быть какими угодно, в шутку говоря хоть динозавр из монитора вылезет.
Оператор == для чисел с плавающей точкой и defined, и specified. Загвоздка лишь в точности самого полученного значения с плавающей запятой. У FP неассоциативные операторы, накопление погрешностей, и невозможность точного представления конкретных чисел.
А зачем вообще так писать? Зачем вообще использовать голые lineto, без оберток для иерархий виджетов? Код жестов работает так, как я описал выше. После чего готовые параметры смещения, поворота(?) и масштабирования меняются у корневого узла. Дальше зависит от того, что конкретно у нас за окружение. Если это UI в котором поворот невозможен, позиции дочерних элементов обновляются простой арифметикой от родительских на стадии обновления Layout. Если что-то более навороченное или встроенное в игру, то тоже же самое делается уже матрицами. Но ни человек который пишет жесты, ни человек который дергает примитивы и анимации ничего из этого не видит.
А как использование матриц от этого освобождает? У нас фактически есть две разные системы координат, необходимость перевода неизбежна. И в обоих случаях он скрыт за вызовом функций.
Не удивительно. Один месяц работы это уже 160 часов работы с реальным кодом на реальных задачах, с опытными менторами и т.д. и т.п.. Это и количественно и качественно превосходит учебные часы программирования за семестр ВУЗа.
Спасибо, кеп. Еще раз, всю математику в нашем движке писал я. А на стороне скриптов были видны только готовые setPosition, setScale, setRotation, и setParent/setChild для иерархии узлов.
Никто не пересчитывал матрицу из жестов, потому что код жестов ее не требует. Ниже я привел описание того, как работают жесты, а выше пример кода, который делает масштабирование стабильным к изображению.
Зачем? Я взял одну точку, потянул, а код посмотрел на сколько пикселей сдвинулась координата и ровно на столько же сдвинул объект на экране. Так работает panning. Проверяя область нажатия и скорость точки мы можем делать swipe.
Возьмем пример сложнее. Пользователь использует тачскрин и создает пару нажатий, соответственно мы получаем две точки. По среднешкольной программе используем теорему Пифагора, чтобы понять как изменяется расстояние между точками относительно позиции в начале жеста, и если оно достаточно отличается от порога - делаем scale. За центр масштабирования возьмем геометрическое среднее двух точек, а дальше как в участке кода что я скинул выше. Если этот центр движется по экрану, можем делать альтернативное panning действие, например скроллинг. По среднешкольной же программе мы можем определить и изменение угла отрезка образованного точками по отношению к экрану, и таким образом сделать жест поворот.
Линейная алгебра это один из самый лайтовых математических предметов после школьной программы, у нас векторы вообще дали в рамках подготовки к вступительным экзаменам в техникум после 9-го класса, хотя они там были вообще не нужны. Но что важнее, фактически мы наблюдаем что на движке Unity каждый день появляются сотни проектов от школьников (буквально) и любителей, в которых активно применяются и матричные трансформации, и кватернионы, и что-то я сомневаюсь что они во всем этом разбираются. Для них прокинуты готовые функции создающие примитивы трансформаций с человекочитаемым названием, им не нужно знать как это работает под капотом чтобы решать практические задачи.
Они известны мне, как писавшему на С++ наш двухмерный игровой движок. Скриптер который делал анимации, жесты, и т.д. даже слова такого как матрица не знал. И это кстати был единственный раз за 15 лет моей жизни с программированием, когда мне нужно было написать умножение матриц в реальной задаче.
Не нужны никакие матрицы чтобы график по экрану ворочать, потому что у него из трансформаций только смещений и масштабирование.
Можете пожалуйста показать ссылой на гитхаб хоть один пример, где в UI без поворота уножают вектор мышки на обратную матрицу? Я такого никогда еще не видел.
Парой арифметических операций? График вроде не нужно вращать.
Не знаю точно как сделано в продукте выше, но что насчет дергать функции примитивов в tween'ах с easyng'ом?
В упор не понимаю зачем нужны аж матрицы для жестов. В прошлом был опыт написания игр-квестов для мобильных платформ, где были все жесты которые только можно себе представить, и ни один из них никто не делал матрицами.
Это мифы из кинофильмов. Не бывает "простой иньекции" и не засыпают за секунды от тряпочки с хлороформом, там анастезиолог заморачиваться должен, и удачи что-то вколоть или затруднить дыхание не разбудив пациента.
Я знаю одного человека, который себе в квартиру на стену повесил дешевый аппарат для измерения силы удара, и бьет в него каждый день. Иногда головой (я не шучу).
Врачебная тайна.
Как-то раз в 2021м помог со старым ноутбуком, снес три лишних браузера и поставил дату в винде на актуальную. После перезагрузки слетел пароль на скайпе и я предложил владелице (бабулька) ввести его сейчас, чего она с нескольких попыток сделать не смогла. Потом мне несколько дней звонили и обвиняли что я собирался взломать их сверхценный скайп, пока в черный список не добавил.
Для отжиманий лучший вариант это упор на возвышенностях (опорах, блинах, брусьях и т.д.), что позволяет опуститься ниже и растянуть грудные сильнее. А руки лучше ставить так, чтобы было удобно и ничего не болело.
Перетрен случается от хронического недостатка восстановления, а не от отказов.
Смотрю каналы: Mike Israetel, Milo Wolf, Dr. Pak, Menno Henselmans. Ну и еще ряд более научно-популярных, но ссылающихся на исследования - Jeff Nippard, Jeremy Ethier, House of Hypertrophy, Flow High Performance, и т.д.
Точно нет. В положении лежа когда бицепс растянут руки почти параллельны полу, сила тяжести противоположна направлению движения, напряжение максимально. В положении стоя когда бицепс растянут руки просто висят, сила тяжести перпендикулярна направлению движения, напряжение в этот момент минимально.
Это кстати другое видео.
Смотря какой тренажер и смотря какое упражнение, кстати. Например в жиме лежа со штангой если вдруг закончились силы можно попробовать наклонить штангу в сторону. При аналогичной проблеме с жимом на тренажере Смита если никого нет рядом можно и окочуриться, есть реальные примеры. А можно и просто получить штангой по шее, примеры тоже есть. Или знаменитые ноги кузнечика на тренажере для жима ногами.
ИМХО дело не в простоте производства, а банально в том что у круглого люка заметно меньше площадь, а значит и объем требуемого материала.
Эмм, нет. Undefined Behavior это конкретный термин из конкретных языков программирования, который специальным образом обрабатывается компиляторами, для чего он собственно и введен. Компилятор C/C++ исходит из того, что в программе не может быть Undefined Behavior, что позволяет ему для оптимизации игнорировать все инварианты в которых он возникает. Если бы == для FP был Undefined Behavior, компилятор мог бы просто удалить весь код который зависит от вычислений в которых он встречается под предлогом "так быстрее". При этом последствия для программ полагающихся на код с UB могут быть какими угодно, в шутку говоря хоть динозавр из монитора вылезет.
Оператор == для чисел с плавающей точкой и defined, и specified. Загвоздка лишь в точности самого полученного значения с плавающей запятой. У FP неассоциативные операторы, накопление погрешностей, и невозможность точного представления конкретных чисел.
Первое можно еще чуть упростить. Сначала уберем дублирование floor.
А теперь воспользуемся неявным приведением булеана к числу.
Второй пример нужно починить:
Но для отрицательных чисел оба способа работать не будут.