28.08.2024 16:54
[#241]
Re: Ami Robbo 2
@asman, post #239
To bardzo ciekawe, w czym to piszesz ?
6 lat temu zacząłem w assemblerze
ale projekt porzuciłem... bo nie lubię robić konwersji.
z miesiąc temu bawiąc się C stwierdziłem że spróbuję wrócić do tematu w ... C a konkretnie z kompilatorem oscar64.
kodu jest 10 razy mniej (w liniach) i to co wtedy zrobiłem odtworzyłem w 2 dni w C. łatwizna. muszę tylko zrobić swoją grafikę, levele itp.
... a żeby nie było offtopowo to powiem że zdobyte doświadczenie mógłbym w sumie przełożyć na projekt amigowy w BB2 tym bardziej że to też już mam rozgrzebane. oglądać od 30 sekundy.
28.08.2024 17:45
[#244]
Re: Ami Robbo 2
@c64portal, post #243
Jeszcze scroll jak scroll ale dokaflowanie to już porażka. Co innego przenieść o jeden kafel całą bitmapę Blockscrollem i dorysować dalej, a co innego pilnować kombinacje z korkociągiem i jednocześnie scroll pionowy. Do tego potrzeba minimum profesora informatyki. Serio mówię i z fascynacją podziwiam Twój silnik.
Ostatnia aktualizacja: 28.08.2024 17:54:15 przez tukinem
Ostatnia aktualizacja: 28.08.2024 17:54:15 przez tukinem
28.08.2024 19:04
[#246]
Re: Ami Robbo 2
@c64portal, post #245
Chodziło mi o silnik z Laury. Wygląda mniej więcej jak tutaj w AmiRobbo, czyli 512x512. W podwójnym buforowaniu na 5 bitplanach to około 320KB chip ramu. I tu znowu niektórzy będą krzyczeć, że gra nie pójdzie na A500 z slow ramem. Mówię o pełnej grze z dźwiękami, muzyką, sporą ilością shapów w pamięci itd.
Shmup to wiadomo, że jest scroll non stop w jednym kierunku a pozycja Y pewnie jest sterowana funkcją QWrap
Znowu mnie nie daje spokoju scroll z gier takich jak Superfrog, Zool, Minky, czy nawet taki Scooby And Scrappy Doo, gdzie ładnie płynnie scrolluje we wszystkich kierunkach jednocześnie wielkie światy, a gra wymaga 512 KB chip ram. Dla mnie nie jest sztuką napisać taki scroll jak tu w AmiRobbo 2 gdzie cały level mam narysowany w chip ramie i tylko przesuwam bitplany. Sztuką jest minimalna bitmapa i dorysowywanie, tak jak w przypadku TonyGO które napisałem. Tam nie ma korkociągu, bo scroll jest nieskończony, a korkociąg ma pewien limit.
Shmup to wiadomo, że jest scroll non stop w jednym kierunku a pozycja Y pewnie jest sterowana funkcją QWrap
Znowu mnie nie daje spokoju scroll z gier takich jak Superfrog, Zool, Minky, czy nawet taki Scooby And Scrappy Doo, gdzie ładnie płynnie scrolluje we wszystkich kierunkach jednocześnie wielkie światy, a gra wymaga 512 KB chip ram. Dla mnie nie jest sztuką napisać taki scroll jak tu w AmiRobbo 2 gdzie cały level mam narysowany w chip ramie i tylko przesuwam bitplany. Sztuką jest minimalna bitmapa i dorysowywanie, tak jak w przypadku TonyGO które napisałem. Tam nie ma korkociągu, bo scroll jest nieskończony, a korkociąg ma pewien limit.
08.09.2024 00:09
[#250]
Re: Ami Robbo 2
@tukinem, post #249
Widze, ze kolizje juz dzialaja.
Mi osobiscie nie podoba sie ten efekt "flash" po zebraniu ostatniej srubki na danym levelu.
Razi mnie to, kojarzy mi sie z bledem w grze/programie.
Nie wiem tez, czy nie jest czasem jakas choroba z takim blyskaniem zwiazana, na niektorych pudelkach z grami sa bodaj informacje o czyms takim
Napis w stylu "Go to ship" lub "Ship fixed/ready" bylby lepszy.
Mi osobiscie nie podoba sie ten efekt "flash" po zebraniu ostatniej srubki na danym levelu.
Razi mnie to, kojarzy mi sie z bledem w grze/programie.
Nie wiem tez, czy nie jest czasem jakas choroba z takim blyskaniem zwiazana, na niektorych pudelkach z grami sa bodaj informacje o czyms takim
Napis w stylu "Go to ship" lub "Ship fixed/ready" bylby lepszy.
08.09.2024 00:19
[#251]
Re: Ami Robbo 2
@Don_Adan, post #250
Chodzi o błysk kolorem 0 na $DFF180? Nie wiem czemu, ale taki nawyk mi się zrobił odkąd pisałem Tonego. Może dlatego że to szybkie działanie, które i tak znika przy kolejnej ramce. Trochę 8-bitowo też to wygląda. W sumie to nawet nie trzeba żadnego efektu, bo na belce na dole mamy podane, ile śrubek zostało do zebrania. Może usunę to mruganie.
Kolizje już od dawna są. Obecnie to dzisiaj stworzyłem 32 level do gry. Wszystkich będzie 50, ale do gry będzie można pobierać paczki z dodatkowymi światami, które uruchamiamy przez CUSTOM WORLD w menu gry. Już ta opcja działa.
Ogólnie samego kodu, to mam powiedzmy 95%. Zostało tylko dopisanie ekranów z postępem fabuły, a reszta to klepanie leveli. No i czekam jeszcze na sampel od otwierania drzwi oraz przesuwania skrzyń, bo te są zbyt "metalowe". Muzyk ma ostatnio urwanie głowy i nie dziwię się.
Kolizje już od dawna są. Obecnie to dzisiaj stworzyłem 32 level do gry. Wszystkich będzie 50, ale do gry będzie można pobierać paczki z dodatkowymi światami, które uruchamiamy przez CUSTOM WORLD w menu gry. Już ta opcja działa.
Ogólnie samego kodu, to mam powiedzmy 95%. Zostało tylko dopisanie ekranów z postępem fabuły, a reszta to klepanie leveli. No i czekam jeszcze na sampel od otwierania drzwi oraz przesuwania skrzyń, bo te są zbyt "metalowe". Muzyk ma ostatnio urwanie głowy i nie dziwię się.
08.09.2024 04:18
[#254]
Re: Ami Robbo 2
@Don_Adan, post #253
Mogę usunąć ten efekt. Tymbardziej, że on powoduje kolejne odegranie sampla zbierania baterii, bo tak to mam zapisane w procedurze. Usuwając procedurę zaoszczędzę jakieś 80 bajtów kodu :)
Ja będę mógł najbardziej ingerować w DLC. Każda paczka DLC to będzie 20 leveli + pliki graficzne + pliki dźwiękowe. Jeśli ktoś by chciał stworzyć własne na swoich grafikach, to bym musiał udostępnić kod, który przerabia tileset na plik z bankiem shapów i bankiem sprajtów. Tu akurat kod jest elastyczny i z bitmapy 5-bitplanowej kopiuje 4 bitplany do drugiej bitmapy, z której wycina sprajty. Z 5-bitplanowych shapów nie da się stworzyć sprajta - taka blokada w Blitz Basic. Amos potrafił
Czyli, jeśli ktoś by chciał pełne DLC stworzyć, to musiałby posiadać edytor leveli, który myślę, że Szafir udostępni bezproblemowo, konwerter grafiki na pliki GFX.SHP oraz SPR.SHP i PAL.DAT, gdzie siedzą dane palety, oraz musiałby ręcznie sobie stworzyć sample w IFF 8SVX. Oczywiście można mieszać i z gry skopiować, tylko że w grze są numerowane np. GFX1.SHP, a w DLC to po prostu GFX.SHP.
Jeszcze kwestia ustalonej przez Selura drugiej połowy palety, która jest stała oraz wzór tilesetu do gry. Mógłbym śmiało dać wzór w IFF, w którym jest postawowa grafika z Atari 8-bit. Taki użytkownik mógłby sobie pozmieniać paletę oraz grafiki pod siebie. Grafiki Selura również mógłby zmienić, a jedynie musiałby pamiętać, że kolory sprajtów w IFF muszą być z indeksów 17-31. Grafiki do dolnej belki również mógłby zmienić wedle uznania. Wtedy taki plik IFF by sobie wczytał do konwertera grafik i voila. Musiałbym się zastanowić jeszcze, czy nie ma jakichś ograniczeń. Na pewno trzeba tworzyć poziomy z głową, bo jeśli nawali stworków, czy laserów jeden obok drugiego, no to będzie wolno, mimo że nie blituje się co ramkę, ale trochę logiki tam jest. Stworek sprawdza sobie po swoim kierunku, czy może przejść w bok, jeśli nie to prosto, jeśli nie to w drugi bok itd. Z oczami jest trudniej, bo one wędrują za robocikiem i szukają drogi w linii prostej, ale po pewnym algorytmie, który jest w kodzie. Lasery są jeszcze bardziej skomplikowane, bo jeśli laser ma bardzo długi strzał, to cała jego długość kafel po kaflu jest sprawdzana, czy dobił do ściany/innego przedmiotu i ma wracać, czy nie. W Electromanie lasery były bobami, bo były animowane, tutaj są po prostu blitami. Laser obrotowy dodatkowo losuje następny kierunek strzału, bo on po każdym wystrzale wybiera sobie kolejny kierunek losowo. Samo blitowanie obiektów nie jest oparte na bobach, ale dochodzi jeszcze odryowanie tła po obiekcie, odrysowanie dolnej części wyższego kafla, bo jeśli tam jest murek, lub skrzynka, to trzeba ją odrysować (widok top-down).
No i przy wyborze konkretnej paczki DLC nie wybieramy katalogu, a dowolny plik w tym katalogu. No niestety, musiałem użyć standardowy FileRequester zgodny z kickstartem 1.3. Requester od samego katalogu już wymaga kicku 2.0, bo używa biblioteki ASL - a dokładnie to funkcja ASLPathRequest$(). No szkoda.
Ja będę mógł najbardziej ingerować w DLC. Każda paczka DLC to będzie 20 leveli + pliki graficzne + pliki dźwiękowe. Jeśli ktoś by chciał stworzyć własne na swoich grafikach, to bym musiał udostępnić kod, który przerabia tileset na plik z bankiem shapów i bankiem sprajtów. Tu akurat kod jest elastyczny i z bitmapy 5-bitplanowej kopiuje 4 bitplany do drugiej bitmapy, z której wycina sprajty. Z 5-bitplanowych shapów nie da się stworzyć sprajta - taka blokada w Blitz Basic. Amos potrafił
Czyli, jeśli ktoś by chciał pełne DLC stworzyć, to musiałby posiadać edytor leveli, który myślę, że Szafir udostępni bezproblemowo, konwerter grafiki na pliki GFX.SHP oraz SPR.SHP i PAL.DAT, gdzie siedzą dane palety, oraz musiałby ręcznie sobie stworzyć sample w IFF 8SVX. Oczywiście można mieszać i z gry skopiować, tylko że w grze są numerowane np. GFX1.SHP, a w DLC to po prostu GFX.SHP.
Jeszcze kwestia ustalonej przez Selura drugiej połowy palety, która jest stała oraz wzór tilesetu do gry. Mógłbym śmiało dać wzór w IFF, w którym jest postawowa grafika z Atari 8-bit. Taki użytkownik mógłby sobie pozmieniać paletę oraz grafiki pod siebie. Grafiki Selura również mógłby zmienić, a jedynie musiałby pamiętać, że kolory sprajtów w IFF muszą być z indeksów 17-31. Grafiki do dolnej belki również mógłby zmienić wedle uznania. Wtedy taki plik IFF by sobie wczytał do konwertera grafik i voila. Musiałbym się zastanowić jeszcze, czy nie ma jakichś ograniczeń. Na pewno trzeba tworzyć poziomy z głową, bo jeśli nawali stworków, czy laserów jeden obok drugiego, no to będzie wolno, mimo że nie blituje się co ramkę, ale trochę logiki tam jest. Stworek sprawdza sobie po swoim kierunku, czy może przejść w bok, jeśli nie to prosto, jeśli nie to w drugi bok itd. Z oczami jest trudniej, bo one wędrują za robocikiem i szukają drogi w linii prostej, ale po pewnym algorytmie, który jest w kodzie. Lasery są jeszcze bardziej skomplikowane, bo jeśli laser ma bardzo długi strzał, to cała jego długość kafel po kaflu jest sprawdzana, czy dobił do ściany/innego przedmiotu i ma wracać, czy nie. W Electromanie lasery były bobami, bo były animowane, tutaj są po prostu blitami. Laser obrotowy dodatkowo losuje następny kierunek strzału, bo on po każdym wystrzale wybiera sobie kolejny kierunek losowo. Samo blitowanie obiektów nie jest oparte na bobach, ale dochodzi jeszcze odryowanie tła po obiekcie, odrysowanie dolnej części wyższego kafla, bo jeśli tam jest murek, lub skrzynka, to trzeba ją odrysować (widok top-down).
No i przy wyborze konkretnej paczki DLC nie wybieramy katalogu, a dowolny plik w tym katalogu. No niestety, musiałem użyć standardowy FileRequester zgodny z kickstartem 1.3. Requester od samego katalogu już wymaga kicku 2.0, bo używa biblioteki ASL - a dokładnie to funkcja ASLPathRequest$(). No szkoda.
08.09.2024 12:21
[#257]
Re: Ami Robbo 2
@karolb, post #256
Obejrzalem jak to wyglada w oryginale na Atari:
link
I jest roznica, tam ten blysk dotyczy tylko obszaru mapy/gry.
W wersji na Amige jest na calym ekranie.
Dla mnie po prostu wali po oczach.
Takie cos jak jest w wersji Atari mogloby byc.
Ale obecny blysk w wersji Amigowej mi sie nie podoba.
link
I jest roznica, tam ten blysk dotyczy tylko obszaru mapy/gry.
W wersji na Amige jest na calym ekranie.
Dla mnie po prostu wali po oczach.
Takie cos jak jest w wersji Atari mogloby byc.
Ale obecny blysk w wersji Amigowej mi sie nie podoba.
08.09.2024 12:29
[#258]
Re: Ami Robbo 2
@Aniol, post #255
No i jak tu dogodzić każdemu? Zostawię w sumie to miganie. I tak nie jest to mruganie kolorem $f,$f,$f, tylko "większą połówką" czyli $8,$8$8. A pochwalę się jak to zwinnie zrobiłem
Robocika ręcznie poprawiałem żeby był animowany zgodnie z kolejnością animacji kodu gry. W każdym świecie robocik jest inny. Miał być ten sam, ale jest inny dla każdego światu.
Zostawię w sumie to miganie. I tak nie jest to mruganie kolorem $f,$f,$f, tylko "większą połówką" czyli $8,$8$8. A pochwalę się jak to zwinnie zrobiłem ;PETLA LICZY OD 9 DO 0, a kolor przyjmuje wartosci RGB w zaleznosci od bitu 0 zmiennej 'i' For i.b = 9 To 0 Step -1 PalRGB 0 , 0 , -(i BitTst 0) LSL 3 , -(i BitTst 0) LSL 3 , -(i BitTst 0) LSL 3 VWait ; VBLANK DisplayPalette 0,0 ; aktualizacja palety ekranu glownego DisplayPalette 1,0 ; aktualizacja palety belki ekranu Next
Robocika ręcznie poprawiałem żeby był animowany zgodnie z kolejnością animacji kodu gry. W każdym świecie robocik jest inny. Miał być ten sam, ale jest inny dla każdego światu.
08.09.2024 16:04
[#259]
Re: Ami Robbo 2
@tukinem, post #258
Zrobisz jak uwazasz, w koncu to Twoja adaptacja Robbo.
Mi sie takie blyskanie po calym ekranie nie podoba, zwykle w Amigowym kodzie oznacza to, ze program wykonal cos nieprawidlowego i informuje o tym na zewnatrz autora/uzytkownika programu.
W wersji z Atari sa za to znaki zapytania "?" do zbierania.
Nie zauwazylem tych znakow w Twojej wersji.
Mi sie takie blyskanie po calym ekranie nie podoba, zwykle w Amigowym kodzie oznacza to, ze program wykonal cos nieprawidlowego i informuje o tym na zewnatrz autora/uzytkownika programu.
W wersji z Atari sa za to znaki zapytania "?" do zbierania.
Nie zauwazylem tych znakow w Twojej wersji.
08.09.2024 17:36
[#262]
Re: Ami Robbo 2
@Jacques, post #260
Czy w AmiRobbo można cisnąć w stronę rozwiniętego "lasera" w oczekiwaniu na jego zmniejszenie jak na Atari?
Można. Jedynie nawet, jeśli minimalnie wejdziemy w "kafelek" , na który laser zaczyna wchodzić, to nas zabije. Widać to dokładnie w 8:06 mojego filmiku jak straciłem życie.
08.09.2024 18:11
[#264]
Re: Ami Robbo 2
@tukinem, post #262
Jak chcesz, to mozesz wprowadzic sekrety w niektorych levelach.
Typu przesuwasz bombe pod sciane.
Strzelasz w bombe, rozwala sie sciane.
Wtedy ukazuje sie mini komnata.
A w niej:
Bomba (chyba, ze jest nadmiar bomb na planszy to wtedy niepotrzebna)
oraz np.
Extra Life
Extra Points (choc chyba w tej grze nie ma punktow)
Extra Key ?
itp
Typu przesuwasz bombe pod sciane.
Strzelasz w bombe, rozwala sie sciane.
Wtedy ukazuje sie mini komnata.
A w niej:
Bomba (chyba, ze jest nadmiar bomb na planszy to wtedy niepotrzebna)
oraz np.
Extra Life
Extra Points (choc chyba w tej grze nie ma punktow)
Extra Key ?
itp
08.09.2024 19:23
[#266]
Re: Ami Robbo 2
@Don_Adan, post #264
Nie nie, już nic nie wprowadzam.
Była mowa o minimalizmie, więc gra śmiga na 512kB Chip RAM, ale wymaga 1MB fastu. Oprócz tego działa już ledwo na gołej A600 (i pewnie 500 plus też, ale nie wypowiem się, bo nie mam ROMu do tego). Mam już praktycznie 99% gotowego kodu pełnej wersji. Zostało mi dopasować napisy do jednego ekranu fabuły gry - tego ostatniego. Oprócz tego zostało wprowadzić 16 cheatów do gry, ale miejsce na nie jest i tak już alokowane, tyle że teraz to 8 spacji (nie mylić z osiem gwiazdek!!!
). Reszta jest gotowa i nic już nie wejdzie. Plik exe to 103kB i jeśli urośnie, to pożera już zbyt dużo RAMu. Póki co wprowadziłem napisy typu "BLABLABLA", żeby wiedzieć czy kod w ostatecznym rozmiarze wystartuje bezproblemowo na A600. Z tym był największy problem, bo już potrafiłem przekroczyć 1MB, który jest dostępny.
Zostało jeszcze potestować, czy gdzieś się nie wysypuje przy grze z DLC w przypadku, gdy bootujemy grę z dyskietki i przekładamy nośnik na ten z dodatkowymi światami.
Była mowa o minimalizmie, więc gra śmiga na 512kB Chip RAM, ale wymaga 1MB fastu. Oprócz tego działa już ledwo na gołej A600 (i pewnie 500 plus też, ale nie wypowiem się, bo nie mam ROMu do tego). Mam już praktycznie 99% gotowego kodu pełnej wersji. Zostało mi dopasować napisy do jednego ekranu fabuły gry - tego ostatniego. Oprócz tego zostało wprowadzić 16 cheatów do gry, ale miejsce na nie jest i tak już alokowane, tyle że teraz to 8 spacji (nie mylić z osiem gwiazdek!!!
). Reszta jest gotowa i nic już nie wejdzie. Plik exe to 103kB i jeśli urośnie, to pożera już zbyt dużo RAMu. Póki co wprowadziłem napisy typu "BLABLABLA", żeby wiedzieć czy kod w ostatecznym rozmiarze wystartuje bezproblemowo na A600. Z tym był największy problem, bo już potrafiłem przekroczyć 1MB, który jest dostępny.Zostało jeszcze potestować, czy gdzieś się nie wysypuje przy grze z DLC w przypadku, gdy bootujemy grę z dyskietki i przekładamy nośnik na ten z dodatkowymi światami.
08.09.2024 20:47
[#269]
Re: Ami Robbo 2
@amikoksu, post #267
Kody już są.
Każdy level ma swój cheat, oprócz tego są kody na nieśmiertelność, amunicję oraz na odporność na magnesy.
Robbo w oryginale chyba nie wyświetlał kodów, tutaj też się nie wyświetlają. Zastanawiam się, czy zostawić to asemblerowcom-crackerom, czy jak za dawnych czasów opublikować w którymś numerze K&A. Zbyt łatwo byłoby, gdybym podał cheaty razem z grą.
Każdy level ma swój cheat, oprócz tego są kody na nieśmiertelność, amunicję oraz na odporność na magnesy.
Robbo w oryginale chyba nie wyświetlał kodów, tutaj też się nie wyświetlają. Zastanawiam się, czy zostawić to asemblerowcom-crackerom, czy jak za dawnych czasów opublikować w którymś numerze K&A. Zbyt łatwo byłoby, gdybym podał cheaty razem z grą.
26.09.2024 17:45
[#270]
Re: Ami Robbo 2
@tukinem, post #1
Mogę już zaprezentować wersję BETA demka Ami Robbo 2:
Dosyć proste jest, ale same poziomy jeszcze utrudnimy.
Kolory kluczy w trzecim tilesecie się nie zgadzają z kolorami na belce z inwentarzem. Wiem o tym i to już jest poprawione, ale nie zostało zaktualizowane w wersji demo.
Jak i pełna wersja, tak demo również ma identyczne wymagania minimalne:
- Amiga 500 OCS z minimum 1MB fast RAM
- Amiga 500+/600 bez dodatkowej pamięci fast RAM
Oprócz tego mogę się pochwalić, że napisałem edytor paczek DLC działający pod AmigaOS. Nie sprawdzałem wymagań minimalnych dla niego, ale ogólnie można sobie tworzyć paczki DLC, które zawierają:
- własny tileset do gry
- własne dźwięki, ale twórca musi sobie sam stworzyć pliki IFF 8SVX
- 20 map tworzonych w tym właśnie edytorze
Edytor jest napisany po angielsku i będę go publikować zarówno na Aminecie, jak i na moim profilu itch. Można w nim zarówno tworzyć nowy pakiet DLC, jak i edytować już istniejący.
A oto jego zrzuty ekranu:
"MAIN SCREEN"
"ABOUT"
"TILESET"
"MAPA"
Dosyć proste jest, ale same poziomy jeszcze utrudnimy.
Kolory kluczy w trzecim tilesecie się nie zgadzają z kolorami na belce z inwentarzem. Wiem o tym i to już jest poprawione, ale nie zostało zaktualizowane w wersji demo.
Jak i pełna wersja, tak demo również ma identyczne wymagania minimalne:
- Amiga 500 OCS z minimum 1MB fast RAM
- Amiga 500+/600 bez dodatkowej pamięci fast RAM
Oprócz tego mogę się pochwalić, że napisałem edytor paczek DLC działający pod AmigaOS. Nie sprawdzałem wymagań minimalnych dla niego, ale ogólnie można sobie tworzyć paczki DLC, które zawierają:
- własny tileset do gry
- własne dźwięki, ale twórca musi sobie sam stworzyć pliki IFF 8SVX
- 20 map tworzonych w tym właśnie edytorze
Edytor jest napisany po angielsku i będę go publikować zarówno na Aminecie, jak i na moim profilu itch. Można w nim zarówno tworzyć nowy pakiet DLC, jak i edytować już istniejący.
A oto jego zrzuty ekranu:
"MAIN SCREEN"
"ABOUT"
"TILESET"
"MAPA"