Построить простой мост между objc и lua?

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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