Generalnie, to trudno będzie Ci zrobić szybki i uniwersalny silnik działający na powiedzmy A1200 z fastem, powolność będzie wynikała z uniwersalności, na szybszych maszynach typu 060 byłoby już lepiej a na PPC to już w ogóle pole do popisu jest ogromne, ale wtedy odchodzimy od założenia "klasyk", czyli także A1200 z fastem (ciekawe jak z pamięciożernością takich silników). Lepiej byłoby w sumie, gdybyś rozbił ten silnik na kilka silników tematycznych (platformówki, przygodówki, bijatyki utd), mógłbyś się wzorować na czymś takim jak MUGEN, silnik generalnie do mordobić 2D, ale widziałem w nim także platformówki (w Beats of Rage też).


Widzę, ze Minniat się zrobił Guru i do wszystkiego będziemy się odnosić w stylu "co Minniat zrobiłby lepiej".



Ostatnia modyfikacja: 09.10.2011 16:35:30

Mam dwa pomysły na interpreter, pierwszy to ten o którym napisałem, przy czym uzyskiwanie adresów funkcji nie stanowi problemu, bo będą one odczytywane z predefiniowanej tablicy adresów funkcji, zaś liczba parametrów rzeczywiście może być zmienna. Żeby to rozwiązać kolejka poleceń do interpretacji mogłaby być w postaci ciągu danych, gdzie wielkość jednego rozkazu może być różna, a nie tablicy z elementami jednakowych rozmiarów. W przypadku gdy jest to ciąg, program będzie wiedział ile miejsca zajmuje każde polecenie (+ ewentualne parametry) i o tyle zwiększał licznik rozkazów. Kwestia adresów skoków byłaby rozwiązana w taki sposób, że jeśli jakieś miejsce w programie miałoby być oznaczone etykietą to kompilator zapamiętywałby to miejsce (np. na stosie bądź innym sposobie przechowywania danych) i później pobierałby ten adres skoku w przypadku napotkania polecenia skoku, końca pętli. Jeśli chodzi o to, że w tym systemie każde polecenie będzie wywoływało funkcję, czyli trzeba będzie zapamiętać rejestry itp. to sądzę, że taki sposób interpretacji programu nie spowoduje odczuwalnego spadku prędkości. Jeśli jednak ktoś zechce żeby było szybciej jest drugi sposób na interpreter:

W drugim (trudniejszym) sposobie kompilator działałby inaczej ponieważ uwzględniałby funkcje inline, tj. budowałby program w taki sposób, że byłby to już program w zasadzie wykonywany przez procesor, pobierałby funkcje typu inline i umieszczał w kodzie. Oczywiście jakieś większe funkcje nie byłyby konwertowane do inline, czyli byłyby wykonywane tak jak w sposobie pierwszym. Tylko, że tu już bliski krok do asemblera więc może nie zapędzajmy się tak daleko.

Co do zmiennych (które są odnośnikami do danych ładowanych z pliku) to należy podejść troszkę inaczej do tego języka aniżeli do zwykłego C. Zmienna typu picture nie będzie wskaźnikiem w zwykłym tego słowa znaczeniu. Raczej pasuje bardziej tu słowo "odnośnik", czyli nazwa której przypisano pewną informacje, tutaj - obrazek. Wszędzie tam gdzie będziemy chcieli zastosować dane zawarte pod tą nazwą będziemy stosowali te zmienne, przy czym dane, których dotyczą, będą tylko do odczytu. Sama zmienna również będzie mogła być modyfikowana tylko przez powołane do tego polecenia, bo jeśli dotyczą one jakichś załadowanych danych, to nie możemy stracić wartości tej zmiennej (czyli odnośnika do danych), dopóki te dane rezydują w pamięci. Co do funkcji, to będą one na pewno mogły zwracać jakąś wartość i pobierać parametry, czy zastosuję przekazywanie parametrów przez wartość, czy referencję to jeszcze nie wiem. Sposób przechowywania zmiennych lokalnych - sądzę, że interpreter powinien robić użytek z rejestrów procesora na ile to możliwe, jeśli się tam nie zmieszczą, to powinien użyć stosu programu, bądź własnego stosu.

Parser to rzecz, nad którą pracowałbym na końcu. Chciałbym zachować przejrzystość języka dlatego nie chciałbym wprowadzać zbyt skomplikowanej składni.

Nie wiem na jakiej zasadzie działa interpreter oraz kompilator AMOSa więc trudno mi powiedzieć czy jest mało, czy dużo punktów wspólnych. AMOS rzeczywiście wydaje się być bliski temu projektowi ze względu na zastosowanie, ale jak w rzeczywistości jest dopiero zobaczymy.

Sporo technicznych aspektów interpretera poruszył Smith (a Asman zadał wcześniej bardzo dobre pytania), projekt tego typu jest naprawdę duży, w zasadzie to należałoby oddzielić dyskusję nt. specyfikacji technicznej od rozmowy nt. funkcji pakietu. Mi nie pozostaje za to nic innego jak zamiary przemienić w czyn i po prostu zabrać się do pracy nad tym pakietem. Mam nadzieję, że praca nad nim sprawi, że będę lepiej pisał projekty, a marzeniem jest by stał się on szeroko stosowanym pakietem do pisania gier na Amigę (choć do tego długa droga). Od czegoś trzeba zacząć, a początek jest najważniejszy, metodą małych kroków opracuję system tworzenia jakiegoś wybranego prostego gatunku gier.

Na koniec tego posta chciałbym przypomnieć, że Asman napisał artykuł do magazynu PPA #6, który już zamówiłem na temat pisania własnej gry dla AmigaOS. Czekam na numer, aż do mnie dotrze i z chęcią przeczytam ten artykuł, do czego namawiam również inne osoby które chciałyby spróbować swoich sił w pisaniu na Amigę. Myślę, że dowiem się z niego czegoś interesującego, może będzie stanowić inspirację podczas pisania pakietu.



Ostatnia modyfikacja: 09.10.2011 18:29:36

jak tak czytam ten wątek to wydaje mi się że na koniec powstanie coś jakby hybryda SDLa albo PyGame (z obsługą grafiki na wysokim poziomie) + jakieś predefiniowane obiekty typu sprite, background, scena, score, player, tilemap, enemy, itp....
czy nie lepiej/łatwiej i z więszym prawdopodobieństwiem że ktoś tego użyje napisać bibliotekę typu engine/runtima z API do obsługi takich obiektów.

skupić by się można wtedy na napisaniu kilku funkcji realizujących jakiś scenariusz skłądający się z wyżej wymienionych obiektów. do tworenia takich scenariuszy łątwo (naprawdę łątwo) można by stworzyć edytor z GUI np MUI, Qt, JAVA(?) i składać szybko ekrany, scenariusze na które z kolei skłądały by się sprity, dźwięki, interakcje pomiędzy obiektami itp itd....

pisanie własnych parserów, języków, pośrednich wirtualnych maszyn, itp to strata czasu. IMHO

Witam,

A propos mojego artykuliku, to nie chciałbym nikogo zawieść. Temat jest rozległy i to co napisałem, to dopiero początek. Trzeba wziąć pod uwagę, że większego doświadczenia w pisaniu w C pod AmigaOS nie mam. Zdaję też sobie sprawę, że mimo moich chęci z pewnością pojawią się wątpliwości w zrozumieniu tekstu. Mam nadzieję, że będzie wiele pytań po lekturze tegoż artykułu.

Obecnie pracuję nad kolejną częścią i jest wiele rzeczy do zrobienia.

Pozdrawiam

Są już jakieś pierwsze efekty tego pomysłu, czy na razie dokarmiacie Google? ;)

Jak to pisał wcześniej kolega Ender, także i moim zdaniem myślę, że cenniejszym byłoby utworzyć kurs/tutorial programowania w C (bądź też z wstawkami assemblera) pod kątem gier. Minniat zaoszczędził by sporo czasu, a społeczność zyskałaby wiele implementując zoptymalizowane rozwiązania bądź modyfikując je do własnych potrzeb. Myślę, że taki blok uporządkowanych tutoriali skupiających się na wyjaśnieniu zasad działania popartych przykładami byłby strzałem w dziesiątkę. Programiści uczyliby się efektywniej ;). Stworzenie pakietu do tworzenia gier to trudna sprawa: trzeba przewidzieć wiele wariantów, uodpornić program na "głupoty" użytkownika i przetestować kompatybilność. To robota na parę lat zanim cokolwiek będzie mogło funkcjonować w pełni sprawnie.
Tutoriale zaś pomogłyby raczkującym programistom wejść na odpowiedni poziom wiedzy umożliwiający pisanie ciekawych projektów. Myślę, że chętnych do programowania znalazło by się parę osób. Pakiet spełniłby swoją rolę, gdyby chętnych było setki, a obawiam się, że aż tylu czynnych userów niestety Amiga w dzisiejszych czasach nie posiada.
Najlepiej sprawdzić "rynek" i jego potrzeby. Zresztą swoim skromnym zdaniem dodam, że wolałbym zobaczyć teraz nowe gry na Amigę od RNS, jako, że gier na Amigę tak naprawdę nie ma (a popatrzcie na ośmiobitowce, na które też i ja się przesiadłem ale nie jestem wyjątkiem).

Trafiles dokladnie w 10 Port box2d to bylo by naprawde cos przydatnego .

Na księżyce Jowisza NASA wysyła już sondy badające czy jest/było tam życie.

A projekt GameX żyje i na razie został przemianowany z języka programowania na bibliotekę do linkowania ze swoimi grami. Rzuciłem newsa na PPA, powinien niedługo się pojawić. Napisałem już program demonstracyjny z animowanymi piłkami i obrazkiem w tle, ale podzielę się nim jak będzie lepiej wyglądał pod kątem estetycznym.

Kochani, szykujcie się na wysyp nowych gierek dla Amigi, bo to już niebawem, z wykorzystaniem GameX będzie można pisać łatwo i przystępnie gry w języku C, które będą szybko działać na klasyku. Arcymaga i Nurka też na pewno napiszę za pomocą tej biblioteczki. Inaczej musiałbym pisać w AMOSie, żeby ukończyć... A tak - systemowo zgodna biblioteka, możliwe przenoszenie na inne systemy.

Dzisiaj mam obowiązki, ale w późniejszej części dnia powinienem kontynuować prace, i tak w przeciągu tygodnia powinienem już pokazać działający program demonstracyjny lub nawet mini-gierkę.

http://www.minniatian.republika.pl/GameX/GameX.html

w kwestii formalnej

s/responsible on/responsible for/

Kochani, szykujcie się na wysyp nowych gierek dla Amigi, bo to już niebawem

Czekam z niecierpliwością Jakie gatunki planujesz wydać w pierwszej kolejności? :)