Search the Community
Showing results for tags 'c++'.
Found 3 results
-
Всем привет! С 2013 года начал деятельность по производству своего домашнего кокпита: На данный момент дело идет к завершению создания всех систем. Теперь задумался над вопросом создания визуальной модели для FSX и Prepar 3D. На самом деле дело продвинуто уже далеко, но здесь начну с самого начала. Конкурировать ни с кем не собираюсь, делаю ее с огромным удовольствием не только для себя, но и для тех, кто любит эту машину. Получается у меня два тесно взаимосвязанных проекта. В одну ветку все пихать не хочу, решил создать эту тему, где и покажу что и как... Сделал важный опрос для меня, на что ставить упор. Вот мой кокпит: http://avia.mylas.ru/ Он не закончен еще. После завершения текущего проекта продолжу работу над кокпитом... А вот реальные отзывы посетителей: https://vk.com/club70945295
-
Ну-с... с сакраментального В.: "что делать если грузятся два экземпляра одного прибора и дерутся между собой, вызывая ошибки в работе панели? И что делать если логика прибора не стартует, пока прибор не будет показан на экране" О.: Отвязать логику (работы прибора/системы) от представления (от того, что в симе называется gauge). Как это сделать? Сначала экскурс в основы. Многие начинающие прибористы воспроизводят шаблон, предложенный разработчиками сима в SDK. т.е. GAUGE_TABLE_BEGIN() GAUGE_TABLE_ENTRY(&gaugehdr_attitude) GAUGE_TABLE_ENTRY(&gaugehdr_control_surfaces) GAUGE_TABLE_ENTRY(&gaugehdr_fuel) GAUGE_TABLE_ENTRY(&gaugehdr_fuel_selector) GAUGE_TABLE_ENTRY(&gaugehdr_temperature) GAUGE_TABLE_ENTRY(&gaugehdr_whiskey) GAUGE_TABLE_ENTRY(&gaugehdr_flightmap) GAUGE_TABLE_END() и не задумываются, что стоит за этими мудрыми словами, до тех пор пока... пока не начинают делать что-то более сложное, и не сталкиваются с проблемами наподобие вышеописанной. Собственно, данный шаблон предназначен для сокрытия программной машинерии, которая обеспечивает загрузку и отображение приборов симом. Пытаясь остатся в пределах использования этого шаблона, начинаются навороты со статическими переменными, отслеживанием многократной загрузки и тд и тп, что не способствует устойчивости модели вообще. Решение же лежит в другом, и решение это более изящно - а именно - развязывание непосредственно представления (gauges) от логики модели той или иной системы ВС. Но для этого - необходимо прекратить использовать вышеприведеннный шаблон, и начать использовать ту самую внутреннюю машинерию приборного модуля. Так что же скрывает вышеприведенный шаблон? А вот что //GAUGE_TABLE_BEGIN() extern GAUGEHDR gauge_header; void FSAPI module_init(void){} //вот оно!!! void FSAPI module_deinit(void){} //и это!!!! BOOL WINAPI DllMain (HINSTANCE hDLL, DWORD dwReason, LPVOID lpReserved) { return TRUE; } GAUGESIMPORT ImportTable = { { 0x0000000F, (PPANELS)NULL }, { 0x00000000, NULL } }; /* This is the module's export table. */ GAUGESLINKAGE Linkage = { 0x00000013, module_init, module_deinit, 0, 0, FS9LINK_VERSION, { //GAUGE_TABLE_ENTRY(&gaugehdr_attitude) (&gaugehdr_attitude), //GAUGE_TABLE_END() 0 }}; Итак, что мы тут видим? А видим, что шаблон скрывает определение трех функций и двух структур. Первую структуру (ImportTable) оставляем без изменений, она обеспечивает доступ к функциям сима наподобие lookup_var(). Вторая структура содержит заголовок приборного модуля, в котором указывается магическое число 0x13 (19 в десятичной системе), обозначающую для сима то, что это приборный модуль, два адреса функций, определенных ранее (module_init, module_deinit), два магических числа, нам не интересных, номер версии сима, для которой предназначен данный приборный модуль, ну а дальше идет список адресов заголовков описаний непосредственно представлений приборов (gauges), завершающееся еще одним магическим числом - 0, поскольку именно его сим ожидает увидить при загрузке списка представлений из приборного модуля, в конце означенного списка представлений. Более детально нас интересуют именно определенные шаблоном функции. DllMain оставим в стороне, она в приборных модулях дополняется своим кодом в очень редких случаях. Более подробно интересуют две другие функции - module_init и module_deinit. Что они делают? В шаблоне по умолчанию они не делают ничего! Но! функция module_init вызывается один раз при загрузке приборного модуля, и module_deinit вызывается один раз при выгрузке модуля симом. При этом совершенно не важно, был ли отображен прибор на экране, или не был. Т.е. эти две функции выполняются всегда. Вот сюда-то нам и надо поместить инициализацию логики наших систем, загрузку всех требуемых ресурсов, а так же запуск цикла расчетов обновлений логики (в тч и асинхронное, если ваши знания позволяют это реализовать). В представлении же мы оставляем только отображение конкретных значений и прием управляющих воздействий от пользователя (мышеклики). При этом одинаковых представлений может быть любое множество, в каких угодно местах (на 2Д панели, в ВК или на внешнем компьютере). Конкретные способы реализации самой модели я сейчас рассматривать не буду. Итак, что же надо сделать? конкретно - прекратить использовать шаблон, предложенный SDK, и использовать ту внутреннюю машинерию, которую скрывает этот шаблон. Выполнив это, вы способны внедрить в функции, вызываемые симом при загрузке приборного модуля (не отдельного прибора, события откладываемого до непосредственного отображения прибора, а всего модуля!) и при выгрузке, необходимый вам код инициализации и запуска логики, независимой от представления.
