Open andrew-boyarshin opened 10 years ago
Уже присутствует в version_plan.txt. Помимо изменений к коде движка может потребоваться адаптация скриптов из оригинальной игры.
Я знаю про version_plan. Но лучше завести issue, в котором идет обсуждение путей решения данной проблемы. Пока что пробую приучить LuaBind beta 7(чистый, без правок GSC) к движку. Исправляю ошибки компиляции.
Понял, что тупанул, надо было сразу на эту связку. Но новый LuaBind требует Boost поновее, так что сразу обновляю его до самой последней версии. LuaJIT вынесен в E:/dev/luajit. Компилировать его Visual Studio - я не знаю как. Не важно, главное будет записать как билдить Lua модуль. Фактически, я делаю LuaBind и связываю его с остальным движком(обновляю старый код под новый LuaBind).
Наконец-то удалось скомпилировать Lua-стэк движка. Еще не интегрировал с остальными частями движка. Ненавижу C++ name mangling! Столько времени угробил на такой пустяк... При обновлении пришлось вырезать memory_allocator, боюсь это обернётся очень плохо... А пока 6 ошибок компиляции всего решения и на сегодня всё. Да, @nitrocaster, пожалуйста пометьте, что я работаю над LuaJIT и LuaBind в version_plan. И ещё: надо не забыть про странный кусок кода в старой имплементации LuaBind, который был связан с добавлением функции в глобальную область видимости...
LuaBind beta7 (в X-Ray LuaBind beta 7 RC4):
+* removed functor (use object with call_function() instead)
Блин, надо будет переделывать столько кода...
Уезжаю до вечера 31.08. Работал над связкой X-Ray и LuaBind.
Продолжил портирование. Часть - успешно(переименование функций, небольшое изменение синтаксических конструкций). Есть и проблемы. В LuaBind были вырезаны некоторые фичи: итерация по property экспортированных классов(временно закоментировал), get_lua_table() пока что не знаю, чем заменить. Но в целом работа идёт.
Решил не портировать xrSE - как я понял, это редактор скриптов Lua с возможностью отладки. Там всё слишком плохо - слишком много удаленных функций. В итоге это бесполезно - легче написать новый на C# с NLua. Работаю дальше.
Вообщем, во всем решении осталось менее 6 ошибок компиляции. За завтра надеюсь их пофиксить. Я не портировал xrAI и xrSE - слишком запарно, а хочется уже билд. Проблемы - где-то header потерял, где-то пути неверные прописал. Одна серьезная проблема - name mangling в luabind, хотя компилятор один и тот-же. Странно, но думаю разберусь с этим.
Продолжил работу. На поверхность всплыли косяки с архитектурой рендеров(или просто я такой), поэтому сделал базовый проект для всех рендеров(xrRender). И ещё не разобрался с name mangling проблемами в luabind.
Не очень понимаю, о чем идет речь. LuaBind и LuaJIT - это не части движка.
Где он находится?
Какой именно?
В оригинальном LuaBind помимо luabind_memory.cpp не было нескольких других связанных файлов. X-Ray переопределяет new/delete для сбора статистики и отладки, и изменения в LuaBind сделаны как раз для использования аллокатора движка. Похоже, придется оставить их исходники в репозитории.
Да, я это уже предполагал, хотя ещё не копал глубже в эту часть движка.
Удалите из списка работающих над портом на LuaJIT 2 и LuaBind 0.9. Я не буду работать над этим, как бы это не было досадно. Не могу, не потяну. Выложу на GitHub LuaBind и инструкции по сборке Lua-стэка движка, там всё хорошо настроено для VS 2013(разные конфигурации - Debug, Release, .lib Debug, .lib Release). Причина: страннейшие ошибки по причине ужасной архитектуры решения X-Ray Engine. P.S. Когда будут исходники ЗП - тогда буду работать до посинения.
Тогда до октября :)
Эх
А что эх?)
Lua был обновлён. Только тему не закрыли =)
@Xottab-DUTY Нет, движок Чистого Неба всё так же на старой версии.
@andrew-boyarshin А, блин.. Не заметил, что это репозиторий движка ЧН)
RU
Сделал отдельный issue для этой задачи. Сейчас в движке:
Сейчас LuaBind заброшен(последний коммит 2010 года). LuaJIT обновился до 2.0.3. Можно опробовать связку:
Но необходимо сначала diff изменений от GSC в LuaBind и LuaJIT, чтобы знать, что они изменили в оригинальных файлах. Сложное - адаптация старого кода к новому и неизбежный дебаггинг(вида "куда подевалась половина экспортированных классов"). Если перенос пройдет успешно, производительность Lua движка вырастет в разы.