Язык Lua. Общие вопросы программирования

[alpet 77]

Обкладывать сталкер дллками - палеатив, как я сказала.

Спорное это утверждение. Много-ли потенциала можно из движка ТЧ извлечь, не забираясь глубоко в его внутреннее устройство? Далеко можно зайти с оптимизацией, особенно если захочется задействовать дополнительные ядра ЦП?

Без своей разработки я пока не вижу способов такие вещи делать:

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

2. Вызов методов внутренних C++ классов, раскрывающий возможности опять-же недоступные обычно на уровне Lua.

3. В случае с 65535 ID, получение только существующих из онлайнового или серверного двоичного дерева, за считанные микросекунды вместо перебора. В том числе с фильтрами по владельцу, координатам и т. п. Что к слову позволяет самой DLL наблюдать за состояниями объектов и при необходимости колбеки вызывать, а перехват лога (в версии 1.0006) позволяет синхронизировать версии деревьев.

4. Элементарный перехват клавиатуры.

 

В будущем вероятно удастся даже записывать новые текстуры в память, и корректировать вертексы в буфере DX9. Вряд-ли это позволит движку стать более современным, но пока я оцениваю мир зоны все более и более перестает быть "пластмассовым" и статичным.

Изменено 18 Ноября 2011 пользователем alpet

[alpet 77]

Мелкое замечание по ODS. В тех модах где предполагается отключение luacap в релизной версии, напрямую вызывать экспортируемые функции не стоит. Лучше объявить в _g.script соответствующие глобальные обертки:

function logmsg(msg, flags)
if ODS ~= nil then
    ODS (msg, flags)
end
end

[alpet 77]

kamikazze

Мы не NLC делаем, которое не мод, а арт-объект, который нельзя трогать, в который ни в коем случае нельзя играть, потому что это искусство - им надо любоваться, восхищаясь замыслом и видением художников.

Нельзя так категорично, играть можно и трогать при настойчивости тоже можно. Нравится искать соринку в чужом глазу, покритикуйте технические детали на примерах. Скажем тот-же биндер, вы мастер оптимизации наверное заметили там жуткие тормоза ) В целом доработка его с моей стороны закончилась на этапе... замедления количества циклов:

elps = ElapsedTime(9) 
if elps < 19 then
    SleepEx( 20 - elps )
end

Потому что даже на современных системах графика вылезает за 100FPS, что пропорционально связано с количеством вызовов update. А стремиться к таким запредельным показателям производительности нет смысла, ибо все это обходится недешево - греются комплектующие, шум раздражающий и т.п. Изредка возникают на самом деле потребности в больших расчетах, но на этот счет я веду разработку в пользу использования многоядерности ЦП.

Изменено 2 Января 2012 пользователем alpet

[alpet 77]

Кто-нибудь пытался использовать средства debug для пошаговой (построчной) отладки скриптов в STALKER? У меня как-то не получилось, в колбеки мусор попадает и вызовы не слишком частые - такое подозрение что сильно обрезан отладочный код в XrLua.dll

 

Кстати, lua_newthread я использую для выполнения кода в "песочнице" через LuaSafeCall - позволяет игнорировать мелкие сбои в скриптах такой подход. Для вычислений дополнительными ядрами ЦП, нить лучше создавать полностью новую (lua_newstate), чтобы не включать глобальное пространство имен и доступ к функциям движка (использование чего приведет к сбою наверняка).

[alpet 77]

Если кто ещё интересуется оптимизацией скриптов, я все-таки реализовал поддержку многопоточности. Теперь скорее даже интересно, какие именно задачи можно считать дополнительной нитью. Как я понимаю у большинства игроков сейчас двух-ядерные процессоры, массовый параллелизм в жизнь не провести?

[alpet 77]

Gun12

Это для скриптов сделано, и подразумевается что доступны все функции предоставляемые luacap (некоторые при этом опасно вызывать, если они обращаются к движку), и все функции пользовательских DLL.

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

Реализовать поддержку выделенных нитей можно и в проекте RvP, однако у меня есть в перспективе важное преимущество - можно будет запускать дочерний процесс аналогично как нитку, через достаточно быстрый IPC с ним сообщаться в плане обмена данными. А отдельный процесс уже штука серьёзная, это как минимум лишние 2Гб памяти для какой-либо БД или ещё чего-нить.