mi się podoba "kod wywołujący kod wywołujący" :D
lol, musiałem
Enkapsulacja! :P
<offtop>Poprawnie powinno być "był napisałem" lub "napisałem był" ;)
</offtop>
Dzięki, zapamiętam :)
Wracając do tematu:Dlaczego skrypt miałby "czekać"? Lua nie ma żadnych callbacków/delegatów/eventów/listenerów/kanałów/whatever-else, których można by użyć do napisania handlera onMoveForward, który byłby potem wywoływany przez kod gry?
Piszę oldschoolowe RPG. Skrypty w założeniu mają być proste: dodaj przedmiot, porusz postacią, wyświetl dialog, rozpocznij walkę, pokaż cutscenkę. Każdą z tych akcji da się wyrazić jedną linijką skryptu, i prawie każda powoduje kilkusekundowy przestój w skrypcie do czasu reakcji gracza, i w tym czasie animacja ma cały czas działać. Gdybym robił to callbackami/whatever, zamiast dziesięciolinijkowego skryptu miałbym dziesięciofunkcyjny, z niezłym boilerplate'em. Lepiej już by było w takim wypadku wykonywać skrypty po jednej linijce naraz, ale spowolniłoby to skrypty nietrywialne, i nie wiem czy by nie rozwaliło struktury kodu skryptu - ifów, pętli, wywołań funkcji. Tak więc yieldy wydają się najsensowniejsze.
Nie ma tu za wiele do wrappowania, kilka linijek raptem. Jakas struktura z czasem/warunkiem pobudki + lua_State, wolasz lua_yield i kiedy trzeba skrypt obudzic wolasz lua_resume. Koniec.
No tak, na gołej Lua to by było OK. Problem pojawia się z C++-owymi wrapperami typu Luabind, których chcę użyć, a które yieldów nie wspierają (gdy skrypt wywołany przez pcall() yielduje, Lua traktuje to jako błąd wykonania - trzeba używac pcallk(), którego większość wrapperów nie obsługuje (sprawdzałem grepem na źródłach) - jednak to nie jest już problem, ponieważ znalazłem taki wrapper, który to wspiera (mam nadzieję):
lua-intf).
