Glhack, Vulture i nethack-nao.

Chyba za długo siedziałem pod kamieniem. Właśnie znalazłem w repo glhack. Że ja na to wcześniej nie wpadłem… Lepiej późno niż wcale. Idąc za ciosem, skompilowałem jeszcze Vulture:

I szczerze mówiąc, wszystkie trzy wersje: konsolowa, 2D GLHack i Vulture mają coś w sobie (nethacka ;) tak wiem). Glhack podoba mi się chyba najbardziej: ma ładne tilesy i wygodną obsługę z klawiatury jak w Uniksach (w Vulture yuhjklbn są przekręcone w rzucie izometrycznym, trzeba się przyzwyczaić ;)).

Update: aby cieszyć się ładną czcionką w stylu IBMGraphics na Linuksie potrzebne będzie nethack-nao z obsługą utf-8 i ncurses stąd i ustawienie w ~/.nethackrc:

OPTIONS=cursesgraphics
OPTIONS=windowtype:curses
OPTIONS=windowborders:3
OPTIONS=popup_dialog
OPTIONS=align_message:bottom
OPTIONS=align_status:right
OPTIONS=guicolor

Glhack, Vulture i nethack-nao.

Lua + gemlib.

Jak się spodziewałem utworzenie własnej biblioteki w C dla Lua jest bardzo proste. Póki co moja „biblioteka” to ambitna funkcja v_pline() z gemlib rysująca polilinię, z dowolnej (ile się zmieści) ilości danych przekazywanych przez stos Lua. Nauczka nr 1: nie używać malloc() z libstd PureC (wywala się), tylko Malloc() z tos.h.
gem_v_plineluagem1

 

 

 

 

Cała filozofia, to utworzenie modułu np. gemlib.c, w którym będą zdefiniowane funkcje z biblioteki w C, w tym przykładzie jest aż jedna: vpline() o definicji jak niżej:

static int vpline(lua_State *L) {
/* narysuj polilinię */
}

potem:


static const luaL_Reg gemlib[] = {
{"v_pline", vpline},
{NULL, NULL}};

LUAMOD_API int luaopen_gemlib (lua_State *L) {
luaL_newlib(L, gemlib);
return 1;
}

i dodanie: LUAMOD_API int (luaopen_gemlib) (lua_State *L); np do lualib.h oraz
{„gem”, luaopen_gemlib} do loadedlibs[] w linit.c, żeby interpreter go zarejestrował, bo moduł jest statycznie linkowany więc nie trzeba go ładować.

Wybiorę co najciekawsze funkcje GEM/VDI/AES i zobaczymy co z tego wyjdzie. Proceduralne tworzenie grafiki ze skryptu Lua może być całkiem zabawne ;).

Mam sporo przemyśleń i wątpliwości czy obsługa GUI z Lua jest do zrobienia, ale w tym cała frajda ;).

Lua + gemlib.

Gemlib.

Szkoda, że tak niewiele dobrej dokumentacji się zachowało (albo ja nie wiem gdzie szukać). Znalazłem GEM’s Programmers Reference z Abacus Software i Professional GEM, i tu jest sporo fajnych artykułów. I jeszcze to na początek i ten wątek na Atari Forum jest bardzo ciekawy. Ok, znalazłem jeszcze to. Chyba wystarczy ;).gemlib
No i API Gemlib jest chyba dość spójne, bo dla prostych przykładów można bez problemów linkować z GEM.LIB (w wersji 0.43.6) zamiast PCGEMLIB.LIB z PURE C.

gemlib_st

Zaczynam powoli zmieniać zdanie na temat ST…

Gemlib.

Lua-5.3.0 dla Atari ST (PureC).

No i wyszła wersja Lua-5.3.0. Binarka dla Atari ST tutaj. A gdyby ktoś chciał poeksperymentować wrzucam mój kompletny katalog PURE_C, wraz ze katalogiem lua530 i paroma koniecznymi nagłówkami. A w katalogu src znajduje się plik projektu lua.prj (i lamerski patch ze zmianami względem oryginalnych źródeł, już zaaplikowany). purec_lua530Jak widać powyżej, działa w Aranym. Aby skompilować, ładujemy plik lua.prj w menu Project -> Select, a potem Project -> Make all. W pliku lua.prj trzeba ustawić właściwy katalog w którym utworzona zostanie binarka (u mnie g:\build\lua\lua53.prg). lua530

Lua-5.3.0 dla Atari ST (PureC).

Partycjonowanie karty Atari Side.

Zgodnie z obietnicami, zamieszczam opis partycjonowania karty CF dla Atari Side: FAT32 posłuży do ładowania gier przez Side Loader, a FAT16 do wymiany danych z PC.

Potrzebne będa:

  • Interfejs SIO2PC i AspeQt (lub SIO2SD)
  • APT_Tools_SDFS.atr ze strony FJC.
  • W powyższym atr jest FATFS.SYS i stamtąd go skopiujemy, można go też wyciągnąć  z toolkit_rev_c.atr ze strony SDX.

Postępując jak na filmie:

Partycjonujemy kartę FDISK-iem na Atari. Moja karta ma 128MB (naprawdę mi wystarcza). W pierwszej kolejności inicjalizujemy kartę i dodajemy APT i partycję dla SDX. Jeśli chcemy skasować zawartość karty i utworzyć partycje od nowa wybieramy z menu Disk -> Initialize, jeśli chcemy dodać partycje czy dowiązanie dajemy Disk -> Open. Jeśli karta jest pusta, FDISK zapyta czy ją zainicjalizować.

Nie tworzymy FAT16/32 w FDISKU atarowym (trzeba wybrać odpowiednią opcję). Zrobimy to w następnym kroku w FDISKU pod Linuksem.

Ważne: Partycja FAT16 o rozmiarze mniejszym niż 32MB, większych sterownik fatfs.sys v0.7 nie obsługuje.

Formatujemy partycję SDX i FAT. FAT32 musi mieć powyżej 32MB, żeby mkfs.fat nie krzyczał, że ma za mało klastrów na utworzenie systemu plików. Dla starego Side Loadera dobrze aby FAT32 był przed FAT16, inaczej loader znajdzie FAT16 i nie będzie wiedział co z nim zrobić.

Dodajemy FAT16 jako „External” w atarowym FDISKU i przypisujemy mu literę.

Odpalamy FATFS.SYS i przechodzimy na D2:. Budowanie indeksu plików (oczekiwanie po DIR) może chwile potrwać, ale powinniśmy się cieszyć zawartością partycji FAT16 pod SDX (read only). FAT32 służy do odpalania gier z loadera.

Kopiowanie danych z PC do SDX jest dzięki temu dużo szybsze i wygodniejsze.

.

Partycjonowanie karty Atari Side.

Lua-5.3.0-rc4 dla Atari ST.

No i udało się skompilować w PureC ;) Binarka, gdyby ktoś chciał się pobawić (148KB), tutaj.

lua530rc4

Lua530rc4 jest nawet trochę szybsze od 503 z 2006 roku.

iterator_closure_generator5Interpreter zdaje się działać na miarę możliwości platformy, powyżej ST spotyka iteratory, generatory i domknięcia ;)

f2c

Dla większych serii danych i dużych ilości obliczeń w Lua 5.3.0 różnica GCC vs PureC nie jest już tak duża: jeśli policzymy 30 elementów nieszczęsnego Fibonacciego, 30 razy w pętli, to czas wykonania dla binarki skompilowanej GCC wynosi: 1591x5ms=7,955s a dla PureC 1495x5ms=7,475s. Różnica 6.7%. W 5.2.3 2186x5ms=10,930s. 46% vs 6.7% robi różnicę ;). Dla małych skryptów różnica oczywiście da się we znaki, a 3x większy rozmiar binarki na wolniejszych dyskach da sporą różnicę czasu wykonania.

Niewiarygodne jest to, że da się taki projekt w 2015 skompilować w PureC, który ma 22 lata :]

I jeszcze jeden przykład, tym razem OOP w Lua:

OO_luaJasne, proste i przejrzyste, a możliwości implementacji OOP „po swojemu” ogromne (brak narzuconego modelu obiektowego).

Lua-5.3.0-rc4 dla Atari ST.

Lua, ewolucja.

Lubię zbiegi okoliczności (święta). Szukałem małego, szybkiego języka skryptowego,
a o tym języku słyszałem już wcześniej. Niestety jestem dość sceptyczny do tego typu projektów (ile powstało nowych, wartych uwagi języków w ciągu ostatnich 10-lat?)
i czasem mi trochę schodzi żeby się zbliżyć do tematu, więc w tym przypadku musiało minąć prawie 10 lat…

Ale do sedna: twórcy Lua stworzyli najlepsze wprowadzenie do języka programowania, jakie kiedykolwiek czytałem: „The evolution of LUA”. Szczerze polecam każdemu. Jest to historia rozwoju i opis pojawiających się kolejno możliwości, ale napisana w sposób bardzo pragmatyczny i co najważniejsze, bardzo jasny. Przykład: zawsze się zastanawiałem, kiedy w Pythonie pojawiały się pewne kluczowe elementy, albo np. w której wersji dany „feature”, który np. lubię nadużywać, już był. W „The evolution…” jest to podane wprost:evolution_of_luaPowiem wprost: szacunek dla Brazylijczyków. Inni powinni się od nich uczyć.

Lua, ewolucja.