Autor Wątek: Szybki język skryptowy potrzebny  (Przeczytany 2666 razy)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 11, 2016, 14:50:14
Hej!

Pytanie i temat do dyskusji jak w nazwie wątku.


Szczególne wymagania, które bardzo bym prosił uwzględnić przed zaproponowaniem czegokolwiek:

1) Jak w temacie - szybki. W szczególności interesuje mnie szybkość matematyki na typach wektorowych (vec2, vec3).

2) WAŻNE - Przenośność, wymaganie 1. - Język skryptowy musi być dostępny na luźnej licencji (MIT/BSD) jako C/C++ bez dependencji (czyli tylko biblioteka standardowa). LGPL odpada, bo niektóre platformy na które kompiluję nie pozwalają na podanie kilku modułów i linkowanie dynamiczne (Blackberry, asm.js).

3) Przenośność, wymaganie 2. - Z przyczyn wielu targetów odpadają też nietypowe build systemy. Wystarczy że każda z moich platform docelowych wymyśliła sobie jakiś własny, więc język skryptowy powinien być kodem C/C++ kompilowalnym bez szczególnych dodatkowych zachodów (ewentualnie tylko z kilkoma definami do kompilacji).


Czy znacie coś, co by spełniło wszystkie powyższe założenia?


Pozdrawiam,
KK

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline JasonVoorhees

  • Użytkownik
    • The Immortal Life of the Son of Jay

  • +2
# Styczeń 11, 2016, 21:27:53
Lua.

Offline yarpen

  • Użytkownik

# Styczeń 11, 2016, 22:49:10
Lua jest fajna, ale z tym punktem 1 to tak sobie, przynajmniej w golej wersji (jest LuaJIT, ale tutaj z kolei moze byc problem z pktem 3). Tak szczerze to nie wiem czy jezyk spelniajacy te wszystkie wymagania, moze jakas totalna niszowka...

Offline draghan

  • Użytkownik

# Styczeń 13, 2016, 10:49:18
Hmmm... Może AngelScript? :)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

  • +1
# Styczeń 20, 2016, 00:30:49
Koniec końców poważnie rozważam zrobienie skryptów w... C++. Do samego developmentu wystarczy mi właściwie, by szybka podmiana skryptów mogła odbywać się tylko pod Windowsem, gdzie "skrypt" można skompilować jako osobny projekt do DLL i podmieniać w runtime. Aplikacja obserwuje zmianę daty pliku DLL, po czym go kopiuje (żeby nie blokować następnej kompilacji) i ładuje nowy kod w dowolnym momencie. Na pozostałe platformy całość będzie skompilowana do monolitycznej aplikacji.

Zrobiłem już test i wygląda to obiecująco, a czas kompilacji DLLki z kilku plików jest wręcz pomijalny (biorąc pod uwagę /MP i precompiled header). Samo podłączanie funkcji pomiędzy DLL a exe też dość prosto załatwiam używając dwóch klas o metodach wyłącznie wirtualnych działających w roli namespace/tablicy wskaźników. No i mamy pełną wydajność i zerowy narzut na przekazywaniu klas/struktur (przez wskaźniki/referencje) pomiędzy skryptami i exe.

Online koirat

  • Użytkownik

# Styczeń 20, 2016, 01:04:02
Polecał bym embedować mono wewnątrz swojego programu i używać c# jako języka skryptowego. W podobny sposób zrealizowano to w Unity3d.

Jednak problemem może być licencja, nie jestem dokładnie pewien jaka jest.

http://www.mono-project.com/docs/advanced/embedding/

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Styczeń 20, 2016, 01:32:02
Polecał bym embedować mono wewnątrz swojego programu i używać c# jako języka skryptowego. W podobny sposób zrealizowano to w Unity3d.

Jednak problemem może być licencja, nie jestem dokładnie pewien jaka jest.

http://www.mono-project.com/docs/advanced/embedding/
Myślałem o tym, ale ilość kodu mnie przeraziła.

Offline Krzych

  • Użytkownik

# Styczeń 20, 2016, 10:53:28
Koniec końców poważnie rozważam zrobienie skryptów w... C++. Do samego developmentu wystarczy mi właściwie, by szybka podmiana skryptów mogła odbywać się tylko pod Windowsem, gdzie "skrypt" można skompilować jako osobny projekt do DLL i podmieniać w runtime. Aplikacja obserwuje zmianę daty pliku DLL, po czym go kopiuje (żeby nie blokować następnej kompilacji) i ładuje nowy kod w dowolnym momencie. Na pozostałe platformy całość będzie skompilowana do monolitycznej aplikacji.

Zrobiłem już test i wygląda to obiecująco, a czas kompilacji DLLki z kilku plików jest wręcz pomijalny (biorąc pod uwagę /MP i precompiled header). Samo podłączanie funkcji pomiędzy DLL a exe też dość prosto załatwiam używając dwóch klas o metodach wyłącznie wirtualnych działających w roli namespace/tablicy wskaźników. No i mamy pełną wydajność i zerowy narzut na przekazywaniu klas/struktur (przez wskaźniki/referencje) pomiędzy skryptami i exe.

Już ktoś to zrobił i opisał: http://blog.molecular-matters.com/2014/05/10/using-runtime-compiled-c-code-as-a-scripting-language-under-the-hood/

Offline Paweł

  • Użytkownik

# Styczeń 29, 2016, 21:36:44

Offline MrKaktus

  • Użytkownik

  • +1
# Styczeń 31, 2016, 21:21:47
Przeciez to dokladnie to samo rozwiazanie co w Unreal Engine 4. Kod gry jest budowany do DLLki i hot reaload podmienia ja w ddytorze dla preview.