вобщем есть такая штука, зовется PPJoy (freeware). позволяет установить в систему виртуальный джойстик с тучей осей и кнопок, который видится самой системой как самый обычный джой. подключать к этому виртуальному джойстику можно много девайсов (типа джоев от приставок, радиопередатчиков), но самая прикольная штука - это объединение нескольких устройств в одно. то есть можно, например, из 2-х джоев сделать один (оси взять с одного, кнопки с другого), движения мыши совместить с 2-3 осями, эмулировать оси или кнопки нажатиями кнопок клавы или их сочетаний... вобщем много чего.

меня же заинтересовала возможность програмно управлять виртуальным джоем, технически это выглядит так:

полное описание работы (небольшое) - http://hhrhhr.narod2.ru/ppjoj_ioctl_description/

в мануале прилается пример использования написанный на С, я его немного подсократил - http://hhrhhr.narod2.ru/ppjoy_ioctl_example/

вобщем, встала проблема с переносом этого функционала в HiAsm, по сути нужно адаптировать 3 ф-ии, открытие, посылка пакета данных, закрытие. вместо printf в случае ошибок посылать просто коды. вижу вариант создания в виде Inline Code на дельфи с двумя точка типа Open/Close и несколькими точками для приема входных значений осей/кнопок.
но самолично я на такое до сих пор не способен, поэтому прошу содействия. помимо личной благодарности могу просовокупить малую толику чего-нибудь более материального ;)

HikeR, если он виден в системе как обычный джойстик, то почему бы не воспользоваться стандартным элементом для работы с ним?

стандартный элемент только получает значения, а здесь наоборот, мы откуда-то берем эти значения и посылаем их на джойстик.

да, элемент GamePort может отобразить только 4 оси, а если у нас 8-ми осный джой? тогда можно заюзать PPJoy, создать 2 виртуальных джойстика и разбить 8 осей реального джоя на 2 (4+4) виртуальных. тогда в HiAsm-е можно будет работать с 2-мя устройствами ;)

ну в таком случае переносить нужно только константы и структуры - ф-ции все есть в windows.pas

Может сделать универсальный компонент: DeviceIOCtl?
В примере стандартное обращение к устройству: открыть устройство, послать запрос.
А данные для запроса/ответа можно сохранять в MemoryStream.
Для удобства, можно ещё добавить опциональное автоматическое позиционирование в DataToFile при записи/чтении (плюс соответствующее свойство для позиции). Будет как-бы обращение к какой либо переменной внутри записи. Ну или добавить всё-таки возможность чтения/записи MT-данных в соответствии с заданным форматом, например формат "BWDS20" может означать кортеж из байта,слова,двойного слова и фиксированной строки из 20 байт.

я правильно понял, что компонент для работы с com-портом работает по тому же принципу? открывает/читает/пишет/закрывает файл с названием \.Com1, здесь же надо сделать все тоже самое с "файлом" \.PPJoyIOCTL1

если такой компонент (DeviceIOCtl) будет возможен, то на его основе можно будет работать таким образом со всеми устройствами, знай только меняй свойство "имя файла"?

Ну, ещё нужно знать "управляющий код" (номер функции) и в каком виде подавать/считывать параметры этой функции. Это обычно зависит от самого девайса.
Но в принципе - да. Хотя это и небезопасно. Так что, может и не стоит делать такой универсальный компонент.

Редактировалось 3 раз(а), последний 2025-01-21 12:57:19

tsdima, а начать нужно с малого: с компонента для USB пытался nesco уговорить - пока не поддаётся

Откуда ты взял, что USB компонент можно сделать универсальным Для каждого чипа интерфейса USB пишут свой драйвер, и свой протокол обмена с этим драйвером

nesco, не надо универсального, разработать свой, HiAsm-овский протокол не очень сложный, с упором на максимальную скорость обмена, кто хочет делать железо - прошьёт этот протокол в нём (в железе), зато потенциальных возможностей у HiAsm прибавится

Леонид, нет, но как ты себе это представляешь Но нельзя сделать реальное RealTime ПО не в ядре системы. Обязательно нужен драйвер, который и будет работать внутри ядра, ты предлашаешь мне его написать под виртуальное сфероконное железо

А что это за зверь такой, кстати

господа, вы вот тут javascript:req_cache(" forum_serv.php?q=5&t=51172&s=240 "); практически слово в слово уже об этом говорили, правда это было полгода назад ;)
поэтому видимо придется перейти от "ни строчки кода" к этим самым строчкам самостоятельно.

HikeR, вода камень точит
nesco, если бы я себе это представлял, не обращался к более представляющим товарищам. Зато у меня есть железяки, Ke-USB24A, внешняя звуковая карта - аж 2 шт, которые подключаются к USB порту и я вижу, что это можно, и для HiAsm это нужно!

Леонид, видимо, ты не до конца меня понял. Поясню более точно -- существует стандартизированный протокол USB, это когда система посылает запросы на получение определенных данных и устройство отрабатывает эти запросы, выдавая необходимую информацию системе (это видно, когда вставляешь новое устройство), и внутренний протокол устройства для обмена с драйвером, где драйвер ведет уже обмен с ситемой по стандартному протоколу и с устройством по внутреннему, это, как бы, интерфесный мост между устройством и системой, но может вести обмен и по интерфейсу "устройство пользовательское ПО", по предоставленному драйвером протоколу (если разработчик любезно предоставил точки входа и протокол обмена с драйвером или уточнил, что он стандартизированный). Так вот, самое большое, что мы можем сделать в HiAsm-e, так это произвести обмен с драйвером устройства (опять таки, если есть точки входа с описанием протокола обмена с драйвером). Но каждое устройство имеет свой внутренний протокол, вот почему драйвер от одного устройства совершенно может не подходить к другому, те, нет универсального драйвера для всех устройств, самое большое, для какой-то группы, и я совершенно уверен, что драйвер от Ke-USB24A никаим боком не подойдет к USB звуковухе, и -- наоборот.
Да, кстати, написание драйвера штука, далеко, не простая, особенно, в плане оптимизации обмена.

Так вот, если есть некий драйвер устройства, и разработчики предоставили точки входа в этот драйвер и протокол обмена, то написать компонент для HiAsm-a, вполне реально (пример у нас есть для Ke-USB24A). Но, для разработчика компонента, желательно, иметь это самое устройство.

Вот, как-то так