29.03.2019 15:48
[#1]
Aspekty techniczne gier na Amigę
Jako że nie ma do tej pory takiego wątku a przy okazji Bridge Strike wywiązała się dyskusja to myślę że warto abyśmy mieli miejsce na tego typu dyskusje.
Zacznę ja, bo podobne wątki toczą się na EAB. np o Metal Slugu - czy się da? albo ogólnie o portowaniu gier arcade. Mnie zaciekawił temat Rastana i że niby się nie da ;) ...
Zrobiłem mały filmik gdzie pokazuję jak redukowałem kolory z 74 do 32 w Rastanie z arcade'ów. Jak dla mnie efekt zadawalający a pewnie mogło by być jeszcze lepiej gdyby dodać ditheringi i poświęcić więcej czasu na retusze.
Myślę że zszedłbym do 24-28.
http://retronavigator.com/post/183795128698/the-purpose-of-this-video-is-to-show-how-the
Oczywiście dyskutujmy o wszelkich aspektach technicznych przy pisaniu gier na Ami.
Zacznę ja, bo podobne wątki toczą się na EAB. np o Metal Slugu - czy się da? albo ogólnie o portowaniu gier arcade. Mnie zaciekawił temat Rastana i że niby się nie da ;) ...
Zrobiłem mały filmik gdzie pokazuję jak redukowałem kolory z 74 do 32 w Rastanie z arcade'ów. Jak dla mnie efekt zadawalający a pewnie mogło by być jeszcze lepiej gdyby dodać ditheringi i poświęcić więcej czasu na retusze.
Myślę że zszedłbym do 24-28.
http://retronavigator.com/post/183795128698/the-purpose-of-this-video-is-to-show-how-the
Oczywiście dyskutujmy o wszelkich aspektach technicznych przy pisaniu gier na Ami.
29.03.2019 16:22
[#2]
Re: Aspekty techniczne gier na Amigę
@retronav, post #1
Fajny temat. Ja mogę zapodać parę ciekawostek z gry Benefactor, które pamiętam. Napisałem swego czasu edytor plansz do tej gry, który obsługiwał pierwsze dwa światy i pozwalał na tworzenie pełnych etapów (przy czym napisałem też program, który wyświetlał pełne mapy ze wszystkich światów - ale go nie publikowałem).
Ogólnie typów obiektów w grze jest ok. 200 i naprawdę trudno było je wszystkie rozpracować. Dlatego nie powstała obsługa edycji pozostałych światów.
- Gra jest napisana w zoptymalizowanym asemblerze. W zasadzie każda pojedyncza instrukcja to kunszt sam w sobie.
- Każda mapa składa się z nagłówka, gdzie określona jest szerokość planszy, liczba stworków do uratowania itp., opcjonalnej tęczy oraz wody generowanej przez Coppera. Jest określona tabela przełączników (dot. przycisków i mechanizmów), trasy stworków (czynności, które wykonują), cechy obiektów oraz dane samej mapy (kafelki).
- Wszystkie dane obiektów animowanych rozpakowywane są z pliku z grafiką (w każdym etapie występuje tablica z numerami grafik do rozpakowania).
- W grze na stałe zapisane są parametry obiektów animowanych dla Blittera oraz przeróżne tablice pomocnicze (np. trasy tych latających statków na etapie Techno Treat). Są szybkie algorytmy staczania się kuli po zboczu lub spadających kluczy (jest obsługiwane przyśpieszenie).
- Obiekty w grze dzielą się na trzy typy: z maską (głównie te poruszające się), bez maski (obiekty nieruchome) oraz składające się z odcinków. Różnią się trybem Blittera, który je rysuje.
- Wszystkie mnożenia są zastępowane tablicami wielokrotności.
Ot, takie ciekawostki. Może kogoś zainteresują lub zainspirują. Swego czasu bardzo mnie to interesowało. Teraz staram się dokończyć mój klon Sokobana i od niedawna wreszcie mi się to udaje.
Ale to inna historia...
Ogólnie typów obiektów w grze jest ok. 200 i naprawdę trudno było je wszystkie rozpracować. Dlatego nie powstała obsługa edycji pozostałych światów.
- Gra jest napisana w zoptymalizowanym asemblerze. W zasadzie każda pojedyncza instrukcja to kunszt sam w sobie.
- Każda mapa składa się z nagłówka, gdzie określona jest szerokość planszy, liczba stworków do uratowania itp., opcjonalnej tęczy oraz wody generowanej przez Coppera. Jest określona tabela przełączników (dot. przycisków i mechanizmów), trasy stworków (czynności, które wykonują), cechy obiektów oraz dane samej mapy (kafelki).
- Wszystkie dane obiektów animowanych rozpakowywane są z pliku z grafiką (w każdym etapie występuje tablica z numerami grafik do rozpakowania).
- W grze na stałe zapisane są parametry obiektów animowanych dla Blittera oraz przeróżne tablice pomocnicze (np. trasy tych latających statków na etapie Techno Treat). Są szybkie algorytmy staczania się kuli po zboczu lub spadających kluczy (jest obsługiwane przyśpieszenie).
- Obiekty w grze dzielą się na trzy typy: z maską (głównie te poruszające się), bez maski (obiekty nieruchome) oraz składające się z odcinków. Różnią się trybem Blittera, który je rysuje.
- Wszystkie mnożenia są zastępowane tablicami wielokrotności.
Ot, takie ciekawostki. Może kogoś zainteresują lub zainspirują. Swego czasu bardzo mnie to interesowało. Teraz staram się dokończyć mój klon Sokobana i od niedawna wreszcie mi się to udaje.
Ale to inna historia... 
) 29.03.2019 19:21
[#4]
Re: Aspekty techniczne gier na Amigę
@BULI, post #3
Dzięki
tak jak pisałem na blogu myślę że bez znacznej straty na jakości zszedłbym do 24-28 kolorów
HUD na pewno da się zrobić na zmieniając kolory copperem dla tego odpóściłem w tym przykładzie.
Zrobię jeszcze jeden (chyba) taki przykład z innego ekranu z Rastana. chyba że macie jakąś inną grę (Metal Slug ;) ?)
Oczywiście w moim podejściu z Rastanem nie było by paralaxy tak jak na arcade bo nie dało by się zrobić dual playfield,
ale na AGA.... kto wie ;) pewnie wyszło by to podobnie do tego co McGeezer robił z Rygarem.
tak jak pisałem na blogu myślę że bez znacznej straty na jakości zszedłbym do 24-28 kolorów
HUD na pewno da się zrobić na zmieniając kolory copperem dla tego odpóściłem w tym przykładzie.
Zrobię jeszcze jeden (chyba) taki przykład z innego ekranu z Rastana. chyba że macie jakąś inną grę (Metal Slug ;) ?)
Oczywiście w moim podejściu z Rastanem nie było by paralaxy tak jak na arcade bo nie dało by się zrobić dual playfield,
ale na AGA.... kto wie ;) pewnie wyszło by to podobnie do tego co McGeezer robił z Rygarem.
29.03.2019 21:18
[#6]
Re: Aspekty techniczne gier na Amigę
@BULI, post #5
myslalem o czyms ala metal slug na vampire (nie port) natywnie, ale.. nie mam vampira :P
wiekszosc ograncizen przy tworzeniu nowych zwazych gier zdjelo by posiadanie vampira, niestety dostepnosc tego po juz w sumie mozna powiedziec latach jest mega slaba. powinno sie dac kupic i juz :(
fajny temat, bede obserwowal :)
wiekszosc ograncizen przy tworzeniu nowych zwazych gier zdjelo by posiadanie vampira, niestety dostepnosc tego po juz w sumie mozna powiedziec latach jest mega slaba. powinno sie dac kupic i juz :(
fajny temat, bede obserwowal :)
29.03.2019 21:32
[#8]
Re: Aspekty techniczne gier na Amigę
@retronav, post #4
pewnie wyszło by to podobnie do tego co McGeezer robił z Rygarem.\
Jako, że grzebałem i przy tym ;) Grafika do Rygara wygląda schludnie ale trochę detali niestety umknęło. Próbowałem naprawić kilka rzeczy ale w sumie mimo prób doszedłem do tych samych rezultatów.
Najlepszym wyjściem była redukcja i dorysowanie utraconych detali.
Ciężki temat przy redukcji palety. 30.03.2019 00:30
[#11]
Re: Aspekty techniczne gier na Amigę
@BULI, post #5
Podobno na AGA byloby za latwo :) Zreszta chyba glowny problem z ta gra to jest ilosc pamieci chip potrzebna na grafike. Czyli 0.5MB chipu to cbyba za malo, przy 1MB chipu moze daloby sie zrobic. Wszystko zalezy od pomyslu na konwersje i jaka jakosc mialaby byc,tzn. ile kolorow. Ja widzialem tylko pierwszy etap gry, i nawet nie wiem czy tam mozna sie cofac i o ile ewentualnie. Ale zeby zmniejszyc ilosc chipu na tlo to mozna zamiast 2 screenow 320x192, dac 3 screeny 160x192. Oczywiscie dane musza byc doczytywane tak jak w konwersjach/grach Random Access, typu Saint Dragon lub Swiv. No i jakis fajny trackloader musialby byc, byc moze z longtrackami, zeby wiecej danych weszlo. Jako challenge to moglo by byc fajne, ale powinna byc jeszcze jakas fajna nagroda dla kodera i grafika, bo oni by musieli glowna robote zrobic. O ile to w ogole jest wykonalne, bo nie liczylem ilosci potrzebnej pamieci graficznej.