Не понимаю, зачем и 4-5 и 6-7. При желании можно преобразовывать в векторе или "процедурно" или таблицей, если нужно побыстрее. Вместо этого точно полезнее добавить младшие части смещений.
Не понимаю, зачем и 4-5 и 6-7. При желании можно преобразовывать в векторе или "процедурно" или таблицей, если нужно побыстрее. Вместо этого точно полезнее добавить младшие части смещений.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ну "понесло" меня на разнообразие представления одних и тех-же данных...Сообщение от ivagor
Думал ещё выделить регистры для эмуляции формата джойскиков. Типа при смещении мыши со скоростью больше некоего значения (для защиты от дребезга) - выставлять в регистрах соответствующие джойстикам биты направлений и кнопок.
Но пока продолжаю считать, что джойстик из мыши - совсем не юзабельная фигня.
Свободные регистры есть, могу и эти (отрезанные от смещения) 3 бита воткнуть в отдельные регистры.
Только что туда будут передавать в эмуляторах (если эмуляция контроллера появится) ?
При эмуляции ведь этих "отрезанных бит" не будет.
На самом деле, разнообразные варианты представления манипуляций с мышью, вталкиваю к контроллер, для предоставления возможности как можно проще адаптировать уже имеющиеся программы, под применение мыши.
Поскольку при адаптации готовых (старых) программ, каждый байт "на вес золота", то прочитать данные из порта, которые подойдут для интеграции в данную программу, значительно удобнее, чем ещё и преобразовывать их, после получения, пытаясь подогнать под условия задачи.
Будешь дразнить, я в этот контроллер ещё и USB-клавиатуру воткну... хотя пока не собирался
Во вложении первого сообщения добавил адаптированный под контроллер вариант "arkanoid".
- - - Добавлено - - -
Я тут где-то пургу нёс про представление смещения в PS/2-мышах...
Откудава я взял, что там только положительные значения, а флаг направления отдельно - я не имею представления
В PS/2-мышах, смещение также как в usb-мышах, 8бит целое со знаком (-128 ... +127), и ещё (не понятно для чего) отдельно флаг "отрицательного значения".
Последний раз редактировалось KTSerg; 18.08.2024 в 12:50.
К адаптации старых программ под мышь отношусь умеренно скептически. Что имеет смысл адаптировать - (нормальные) графические редакторы (наверно Draw и хватит) и подходящие игры, типа Minesweeper, Ветка, карточные и игры на доске (шахматы, шашки, реверси и т.п.).
Если правильно сделать эмуляцию, то там будет примерно то же самое, что и в железном контроллере.
Я сейчас глянул на тему чуть более внимательно, чем раньше, потому что у меня заработала USB-клавиатура и я потихоньку морально готовлюсь к тому, чтобы может быть подключить и мышь. Но пока по-моему сыровато. Интересно ставить эксперименты, они должны что-то показать, но в конце труха должна отпасть и должен остаться один ясный и понятный способ. Проблему адаптации старых программ я понимаю, но разделяю здоровый скепсис ivagor-a, поэтому не хочется делать калеку ради того, чтобы адаптировать две-три старые программы.
Предлагаю смещения передавать в таком виде:
* X смещение со знаком / 8
* X смещение со знаком % 8
* Y смещение со знаком / 8
* Y смещение со знаком % 8
Это даст перемещения с удобной для Вектора скоростью и точность для тех случаев, где она может быть понадобится.
Про абсолютные координаты я уже не раз высказывался, но вижу, что эта идея не умрет просто так от моего напряженного взора. В конце концов мне не жалко.
Объясни, почему в эмуляции должны возникнуть какие-то проблемы с младшими битами?
Больше игр нет
Если этот вопрос ко мне, то разве я говорил, что при эмуляции могут возникнуть какие-то проблемы с младшими битами скорости перемещения мыши?
Я говорил о том, что для эмуляторов Вектора они не пригодятся, а с реальным контроллером, при их использовании курсор мыши становится слишком чувствительным к перемещениям самой мыши, и носится по экрану как угорелый, не возможно точно позиционировать. Вот и пришлось "замедлять" до "комфортной" скорости, отбрасывая 3 младших бита скорости.
Эти 3 младшие бита "скорости" - это 3 младших бита чувствительности сенсора мыши.
Обычная мышь имеет чувствительность 1200 пикселей на 2.5см (дюйм) смещения.
Обычный экран РС (при разрешении 1280х1024) курсор мыши пробегает за 2.5 см смещения мыши по коврику, это если в настройках не снижена чувствительность мыши. Обычно мышь нужно сместить примерно на 5 см.
У реального Вектора экран 256х256, при обычной чувствительности сенсора, курсор будет пробегать от края до края за 0.53см смещения мыши по коврику.
Вопрос: Это очень удобно?
Я в реальном контроллере, отбросил 3 младшие бита "скорости", т.е. чувствительности сенсора, и получил чувствительность 150 пикселей на 2.5см смещения мыши по коврику.
Т.е. экран Вектора 256 пикселей курсор будет проходить за чуть меньше 5см смещения мыши (300 пикселей за 2 дюйма смещения).
Эта скорость очень сильно отличается от скорости смещения мыши по экрану РС ?
Нет, я конечно понимаю, что сейчас только я пользуюсь старым монитором с разрешением 1280х1024, а почти у всех остальных мониторы с разрешением 3840 x 2160 и всем пользователям эмулятора Вектора понадобится точно позиционировать каждую 1/64 площади каждого пикселя на экране Вектора, для этого им нужны будут эти 3 отброшенные бита скорости.
И я повторюсь, мне не жалко.
Последний раз редактировалось KTSerg; 19.08.2024 в 10:23.
Я неточно выразился. Но ты сказал, что:
Исправляю вопрос -- почему не будет отрезанных бит при эмуляции? Потому что координаты курсора в сообщениях винды привязаны к пикселям? Тут тоже есть много деталей. Как ты точно подметил, сейчас мало кто может позволить себе запустить эмулятор с увеличением 1х на современных мониторах, так что 1/4 пикселя будет не редкость. Кроме того, перемещения курсора можно получать через WM_INPUT и они будут в нативном разрешении мыши, ну или по крайней мере в каком-то минимально пережеванном. Это может быть нужно не для супбиксельного позиционирования курсора, а для плавного движения какого-нибудь предмета в игре, например.
Больше игр нет
Мне кажется, что для плавного движения лучше сделать регулируемую скорость перемещения мыши, т.е. просто нужен некий внутренний регистр в контроллере, куда можно занести коэффициент деления, чтобы можно было программно (или аппаратно, переключателем) настроить комфортную скорость. И тогда "X смещение со знаком % 8" и "Y смещение со знаком % 8" могут пригодиться ровно никогда и их можно будет просто отбросить.
А вот как это всё встроить в эмулятор... Ну, например, в винде есть параметр "скорость курсора мыши", можно попробовать его изменять в моменты, когда курсор находится над окном эмулятора. Как вариант, делать полный захват курсора окном эмулятора, как это делается в некоторых программах удалённого доступа.
Потому что смысла нет.
Спасибо. Рассмешил, развеселил, сделал день....... Кроме того, перемещения курсора можно получать через WM_INPUT и они будут в нативном разрешении мыши, ну или по крайней мере в каком-то минимально пережеванном. Это может быть нужно не для супбиксельного позиционирования курсора, а для плавного движения какого-нибудь предмета в игре, например.
Я себе так живо представил картинку....
Сидит "Курсор" почти по центру экрана Вектора, в координатах 127,127.
А тут "Программа" получает от "Контроллера" сообщение, что "Мышь" сместилась на (11-битное число со знаком) 1023 пикселя в сторону, и нужно туда "Курсор" отправить... срочно!!!
Кто знает, что ответит "Программа" "Контроллеру", в ответ на приказ отправить "Курсор" на такое расстояние?
- - - Добавлено - - -
Не нужны эмулятору ни какие скорости.
Конечно, я уже писал, что я вообще не разбираюсь в эмуляции.
Но с моей ламерской точки зрения, решение вопроса, это несколько переменных и минимум вычислений.
1. Позиция "курсора" РС всегда привязана к пикселям на экране Вектора, шаг/пиксельклок/коэффициент - как хотите это назовите.
2. При запросе данных из регистра смещения, эмулятор фиксирует текущую координату "курсора" (по запрошенной оси) и вычисляет разницу с координатой, которая была зафиксирована во время предыдущего запроса. Разница и есть смещение "курсора" по оси за промежуток времени между запросами.
Фиксация координаты и вычисления делаются отдельно для регистров смещения по X и Y.
3. После предоставления значения смещения, текущие координата сохраняется как "предыдущая" и ждём следующего запроса из этого регистра.
Это правда справедливо для перемещения мыши в пределах экрана эмуляции. Как адаптировать "смещение" мыши ЗА пределами экрана эмуляции - нужно думать.
И "скорость" смещения в эмуляторе ВСЕГДА будет зависеть от настроек чувствительности мыши в операционке РС. Хочешь 50 dpi выстави, хочешь 5000 dpi.
Я ведь много раз говорил, что корректировка скорости мыши в контроллере, это проблема исключительно РЕАЛЬНОГО контроллера мыши.
И это первая и главная задача любого реального контроллера, подготовить внешние данные для принимающей стороны, чтобы она (принимающая сторона) этими данными не подавилась...
Нафига РЕАЛЬНОМУ Вектору скорости смещения мыши в 1023 пикселя, если РЕАЛЬНЫЙ экран Вектора всего 256 пикселей...
Последний раз редактировалось KTSerg; 19.08.2024 в 13:57.
Если минимум вычислений на Векторе, то да, согласен полностью. Но контроллер и эмуляторы могут вычислять сколько угодно...
А что там думать? Мышь за пределами экрана эмулятора -- координаты не меняются, завели указатель в экран -- начали обновлять...
Увы, но не всегда. Как пример могу привести "VMware Remote Console", там при захвате мышки удалённой машиной в пределах окна скорость перемещения зависит не от настроек хоста, а от настроек удалённой виртуальной машины. Значит такой фокус вполне возможен и в эмуляторе Вектора, если вдруг понадобится.
И с этим тоже согласен. Но мне кажется, иметь в контроллере такую настройку не помешает, чтобы можно было выставлять комфортную для себя скорость, для любой мышки.
Я тоже не понимаю, зачем это, но у других, видимо, есть идеи, где это можно использовать...
Я вот думаю, что при выходе курсора РС за экран эмулятора (в режиме окна), регистры координат меняться не будут, они ведь имеют ограничения значений, координаты будут указывать на кромку/край окна.
А вот в регистры смещения можно записывать некое значение, указывающую направление, в котором находится курсор. чем дальше от края окна, тем больше значение "смещения".
Для полноэкранного режима эмулятора этот вариант конечно не подходит, но наверное тоже как-то решаемо.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
