Строить простой мост между objc и lua? - PullRequest
16 голосов
/ 12 декабря 2011

Я интегрировал Lua с моим кодом ObjC (игра для iphone).Настройка была довольно простой, но теперь у меня есть небольшая проблема с мостовым соединением.Я гуглил по результатам и т. Д. ... и, кажется, нет ничего, что могло бы работать без изменений.Я имею в виду, что я проверил мост luaobjc (он кажется довольно старым и не продолженным), я слышал о LuaCocoa, но, похоже, он не работает на iphone, и воск слишком густой.

Мои потребности довольно скудны, я простомне нужно иметь возможность вызывать методы objc из lua, и я не возражаю против необходимости делать дополнительную работу, чтобы заставить ее работать (мне не нужна полностью автоматическая система мостов).

Итак, я решил построитьсам маленький мост, основанный на этой странице http://anti -alias.me /? p = 36 .Он содержит ключевую информацию о том, как выполнить то, что мне нужно, но учебник еще не завершен, и у меня есть некоторые сомнения относительно того, как справиться с перегрузкой метода при вызове из lua и т. Д. *

Кто-нибудь знает, если естьсуществует ли какой-либо рабочий мост между objc и lua на iphone, или если может быть так сложно завершить мост, который предлагает вышеуказанный сайт?

Любая информация будет приветствоваться.

Ответы [ 2 ]

37 голосов
/ 13 декабря 2011

Не изобретай велосипед!

Во-первых, вы правы, что luaobjc и некоторые другие варианты устарели. Хороший обзор можно найти на странице LuaCocoa . LuaCocoa - это хорошо, но, очевидно, не поддерживает разработку для iPhone, поэтому единственный другой выбор - Wax . LuaCocoa и Wax являются мостами времени выполнения, что означает, что вы можете (теоретически) получить доступ ко всем классам и методам Objective-C в Lua за счет производительности времени выполнения.

Для игр и из моего опыта накладные расходы производительности во время выполнения настолько значительны, что не гарантируют использование какой-либо библиотеки привязки во время выполнения. С точки зрения того, почему можно использовать язык сценариев, обе библиотеки не понимают цели выбора языка сценариев над языком более низкого уровня: они не предоставляют решение DSL - что означает, что вы все еще собираюсь написать то, что по сути является кодом Objective-C, но с немного другим синтаксисом, без поддержки отладки во время выполнения и без поддержки редактирования кода в XCode. Другими словами: связывание Lua во время выполнения - в лучшем случае сомнительное решение, и у него много минусов. Привязки Lua во время выполнения особенно не подходят для динамичных экшен-игр, нацеленных на постоянно высокую частоту кадров.

То, что вы хотите, это статическая привязка. Как минимум, статические привязки требуют, чтобы вы объявили, какие методы будут доступны в коде Lua. Некоторые библиотеки связывания сканируют ваши файлы заголовков, другие требуют, чтобы вы предоставили специальный файл объявлений, похожий на файл заголовка. Большинство библиотек связывания могут использовать оба подхода. Преимущество - оптимальная производительность во время выполнения и возможность на самом деле проектировать, к каким классам, методам и переменным Lua-скрипты имеют доступ.

Есть только 3 кандидата для привязки кода Lua к приложению для iPhone. Честно говоря, их гораздо больше, но у большинства есть один или несколько существенных недостатков, или они просто нестабильны или предназначены только для специальных целей, или просто не работают для приложений iPhone. Кандидаты:

Большой недостаток, который разделяют все библиотеки статического связывания Lua: ни одна из них не может напрямую связываться с кодом Objective-C. Все они требуют наличия дополнительного уровня C или C ++, который в конечном итоге взаимодействует с вашим кодом Objective-C. Это связано с тем, как Objective-C работает как язык и насколько малую роль он сыграл (до сих пор), когда дело доходит до встраивания Lua в приложения Objective-C.

Недавно я проверил все три библиотеки привязок и пришел насладиться SWIG. Это очень хорошо задокументировано , но имеет некоторую кривую обучения. Но я считаю, что кривая обучения оправдана, поскольку SWIG можно использовать для объединения практически любого языка программирования и сценариев, поэтому полезно знать, как использовать SWIG для будущих проектов. Кроме того, как только вы поймете, как реализован их файл определения, он окажется очень простым (особенно по сравнению с luabind) и значительно более гибким, чем tolua.

1 голос
/ 31 января 2015

ОК, немного опоздал на вечеринку, но в случае, если другие опоздают и на этот пост, есть еще один подход, чтобы добавить к доступному варианту: вручную кодируйте свои API LUA.

Я прочитал лекцию на эту тему, где я живу, закодировал некоторые основные привязки LUA за час. Это не трудно. Из лекции я сделал набор видеоуроков, которые показывают, как начать .

Подход с использованием инструмента генерации привязок, такого как SWIG, хорош, если у вас уже есть именно те API, которые вам нужны для вызова, написанные в Objective-C, и имеет смысл привести все те же API-интерфейсы добавлены в LUA.

Плюсы подхода ручного кодирования:

  • ваш проект просто компилируется с одной стандартной целью XCode
    • все ваши проекты - C & Obj-C
    • LUA - это просто данные, отправленные вместе с вашими изображениями
  • без возражений с "я проверяю сгенерированный код" для Git
  • вы создаете функции LUA для всего, что вам нужно
  • Вы можете легко размещать скрипты, которые живут внутри объекта
  • API находится под вашим контролем и хорошо известен
  • не подвергать API-интерфейсы движка команде / инструментам построения уровней

Последний пункт заключается в том, что если у вас есть функции детализации, которые имеют смысл только на уровне движка, и вы не хотите видеть их при кодировании игрового процесса, вам нужно будет указать SWIG не связывать их.

Ответ Штеффенса идеален, и этот подход является еще одним вариантом, который может подойти некоторым людям в зависимости от проекта.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...