01.06.2023 02:02
[#92]
Re: Zapowiedzi nowych gier
@pisklak, post #90
Ok. Zamiast jutro dalej pracować nad grą, napiszę test w Amosie i Blitzu. Porównamy sobie Pointy i BobCole czasowo na bitmapie 2-bitplanowej. Bez udowadniania się chyba nie obejdzie.
PS. Punktów jest 15 i muszą być.
Ostatnia aktualizacja: 01.06.2023 02:04:00 przez tukinem
PS. Punktów jest 15 i muszą być.
Ostatnia aktualizacja: 01.06.2023 02:04:00 przez tukinem
01.06.2023 04:47
[#95]
Re: Zapowiedzi nowych gier
@Umpal, post #87
Absolutnie nie nastawial bym sie na 25 klatek/sek w Amosie pod klasykiemw w zadnej grze przy 320*200 w 32kol.
Moze w jakims demku, jakis prosty efekt ale na pewno nie w dynamicznej grze.
jedna z bardziej dynamicznych gier, nie wiem ile to ma klatek ale jak znajde kody zrodlowe to mozna policzyc ilosc kolorow i obiektow - bieda z nedza.
Ostatnia aktualizacja: 01.06.2023 05:01:07 przez selur
Moze w jakims demku, jakis prosty efekt ale na pewno nie w dynamicznej grze.
jedna z bardziej dynamicznych gier, nie wiem ile to ma klatek ale jak znajde kody zrodlowe to mozna policzyc ilosc kolorow i obiektow - bieda z nedza.
Ostatnia aktualizacja: 01.06.2023 05:01:07 przez selur
01.06.2023 05:26
[#96]
Re: Zapowiedzi nowych gier
@selur, post #95
Ilość fpsów to jedno, ilość bobów i ich rozmiar to drugie, ale obsługa ich. W Tonym każdy typ przeciwnika jest inny. Drzwi i klucze są blitowane, diamenty stoją w miejscu, węże, kolce, eliksiry też. Każdy ma swój system animacji i inne współrzędne do łapania kolizji z Tonym. Głazy łapią kolizje, ale inaczej reagują, bo gdy są opadnięte to Tonego odpychają, a gdy spadają to go zabijają.
Trupek i nietoperz latający poziomo nie dość że ma swój system animacji, to nietoperze poziomo latające latają na ukos. Każdy z nich jest inaczej sterowany. Poza tym, że mają swoje XMax i XMin to jeszcze w odpowiednich momentach latają w górę/dół. Tego nie dałem rady stablicować, bo każdy jest inny. Czaszki też mają swoje YMax i YMin, mają swoje prędkości, bo jedne latają szybciej, a inne wolniej. Nietoperze latające pionowo też mają YMax i YMin. W kolejnych levelach będzie animowana woda na kaflach 32x8pix. Mając wodę na pół ekranu mamy 5 komend Block na ramkę, później w kolejnej klatce znowu 5 x Block dla drugiej bitmapy z drugiego bufora, a później 2 ramki luzu, bo animacja jest raz na 4 ramki
Taką grę jak tu powyżej Blitz ogarnie lepiej, bo zamiast BBlit, czyli Bob z Amosa ma jeszcze o wiele szybszą komendę QBlit, która po zdjęciu boba z ekranu nie wkleja z powrotem zasłoniętego miejsca, a zostawia kolor 0. Wtedy można sobie takich obiektów narobić i z 20. W Tonym winą za spowolnienia jest slow ram, skąd pobierane są bardzo często wartości zmiennych i tablic. W drugiej kolejności procesor jest obciążony sporym liczeniem, bo jednak przeliczanie obiektów, animowanie, sprawdzanie tych wielu warunków robi swoje na pewno. Blitter by jeszcze wyciągnął na pewno trochę. Jak pisałem wcześniej, zdjęcie 6 bobów i zastąpienie ich sprajtami nie zmieniło kompletnie nic.
W drugim levelu Rafał dał mi naprawdę bardzo dużo obiektów do wstawiania i ten level w wersji PAL zwalnia na kilku komnatach tylko, ale przy uruchomieniu na NTSC to jest tragedia. Chyba że ja źle ustawiam winuae do sprawdzania.
Ostatnia aktualizacja: 01.06.2023 05:34:46 przez tukinem
Trupek i nietoperz latający poziomo nie dość że ma swój system animacji, to nietoperze poziomo latające latają na ukos. Każdy z nich jest inaczej sterowany. Poza tym, że mają swoje XMax i XMin to jeszcze w odpowiednich momentach latają w górę/dół. Tego nie dałem rady stablicować, bo każdy jest inny. Czaszki też mają swoje YMax i YMin, mają swoje prędkości, bo jedne latają szybciej, a inne wolniej. Nietoperze latające pionowo też mają YMax i YMin. W kolejnych levelach będzie animowana woda na kaflach 32x8pix. Mając wodę na pół ekranu mamy 5 komend Block na ramkę, później w kolejnej klatce znowu 5 x Block dla drugiej bitmapy z drugiego bufora, a później 2 ramki luzu, bo animacja jest raz na 4 ramki
Taką grę jak tu powyżej Blitz ogarnie lepiej, bo zamiast BBlit, czyli Bob z Amosa ma jeszcze o wiele szybszą komendę QBlit, która po zdjęciu boba z ekranu nie wkleja z powrotem zasłoniętego miejsca, a zostawia kolor 0. Wtedy można sobie takich obiektów narobić i z 20. W Tonym winą za spowolnienia jest slow ram, skąd pobierane są bardzo często wartości zmiennych i tablic. W drugiej kolejności procesor jest obciążony sporym liczeniem, bo jednak przeliczanie obiektów, animowanie, sprawdzanie tych wielu warunków robi swoje na pewno. Blitter by jeszcze wyciągnął na pewno trochę. Jak pisałem wcześniej, zdjęcie 6 bobów i zastąpienie ich sprajtami nie zmieniło kompletnie nic.
W drugim levelu Rafał dał mi naprawdę bardzo dużo obiektów do wstawiania i ten level w wersji PAL zwalnia na kilku komnatach tylko, ale przy uruchomieniu na NTSC to jest tragedia. Chyba że ja źle ustawiam winuae do sprawdzania.
Ostatnia aktualizacja: 01.06.2023 05:34:46 przez tukinem
01.06.2023 05:51
[#97]
Re: Zapowiedzi nowych gier
@tukinem, post #96
dla kazdego obiektu na ekranie masz osobny system animacji ? Ja bym zrobil jeden uniwersalny wywolywany co klatke dla kazdego ruchomego/animowanego obiektu np. w 32 roznych klatkach.
Moze napisz cos wiecej na temat tych kolizji jak je realizujesz.
Ja bym sprobowal zrobic kolizje na zasadzie sprawdzania np. odleglosci od punktu centralnego postaci do danego punktu centralnego potworka
np.
dx=roznica Xpostaci i Xmonster1 a pozniej to samo dy
jesli dx<16 i dy<16 (liczba pikseli dla dx czy dy brana z tablicy dla danego potworka) to zachodzi kolizja jesli odleglosc wieksza to nie zachodzi.
Moze byc to o wiele szybsze niz sprawdzanie wlasnych punktow kolizji kazdego potworka dla zderzenia z Tonym. No ale sposobow jest kilka i trzeba wybrac ten najlepszy.
a co do kolizji Tonego ze scianami/pulapkami to sprawdzalbym punkty kolizji tylko te, ktore sa potrzebne w zaleznosci od kierunku ruchu.
Czyli jesli Tony lezie w lewo to sprawdzamy co ma pod gierami i z lewej strony. Jesli spada w dol to tylko pod stopami, jesli skacze w gore to tylko co nad glowa itp... itd...
Ostatnia aktualizacja: 01.06.2023 05:57:04 przez selur
Moze napisz cos wiecej na temat tych kolizji jak je realizujesz.
Ja bym sprobowal zrobic kolizje na zasadzie sprawdzania np. odleglosci od punktu centralnego postaci do danego punktu centralnego potworka
np.
dx=roznica Xpostaci i Xmonster1 a pozniej to samo dy
jesli dx<16 i dy<16 (liczba pikseli dla dx czy dy brana z tablicy dla danego potworka) to zachodzi kolizja jesli odleglosc wieksza to nie zachodzi.
Moze byc to o wiele szybsze niz sprawdzanie wlasnych punktow kolizji kazdego potworka dla zderzenia z Tonym. No ale sposobow jest kilka i trzeba wybrac ten najlepszy.
a co do kolizji Tonego ze scianami/pulapkami to sprawdzalbym punkty kolizji tylko te, ktore sa potrzebne w zaleznosci od kierunku ruchu.
Czyli jesli Tony lezie w lewo to sprawdzamy co ma pod gierami i z lewej strony. Jesli spada w dol to tylko pod stopami, jesli skacze w gore to tylko co nad glowa itp... itd...
Ostatnia aktualizacja: 01.06.2023 05:57:04 przez selur
01.06.2023 08:50
[#98]
Re: Zapowiedzi nowych gier
@tukinem, post #96
Jak duzo liczysz to ja bym podzielil obliczenia na 2 ramki. Czyli na te co musza byc liczone co ramke, i na te ktore moga byc liczone co druga ramke na przemian. Nie ma co liczyc wszystkiego co ramke, nawet detekcja niektorych kolizji co 2 ramki bedzie ok. Obsluga dzoja tez itp rzeczy.
Ostatnia aktualizacja: 01.06.2023 08:51:29 przez Don_Adan
Ostatnia aktualizacja: 01.06.2023 08:51:29 przez Don_Adan
29.06.2023 11:31
[#101]
Re: Tony - development nowej gry
@mailman, post #1
WERSJA 1.2 jest dostępna do pobrania.
- nowe menu gry
- usunięte wprowadzanie kodu na koniec levelu (a zamiast tego trzeba zebrać klucz końcowy)
- usunięte wyrzucanie mikstur z ekwipunku (jeśli zbieramy klucz a mamy pełny ekwipunek, to jedna mikstura się sama zmienia na klucz)
- nowe menu gry
- usunięte wprowadzanie kodu na koniec levelu (a zamiast tego trzeba zebrać klucz końcowy)
- usunięte wyrzucanie mikstur z ekwipunku (jeśli zbieramy klucz a mamy pełny ekwipunek, to jedna mikstura się sama zmienia na klucz)
08.08.2023 07:17
[#104]
Re: Tony - development nowej gry
@tukinem, post #103
Wczoraj troszkę pograłem (wersja z Aminetu), grafika to wizytówka tej gry i mi się bardzo podoba, świetna muzyka tworzy doskonałą atmosferę.
Silnik działa też naprawdę nieźle (brawo!), przy czym spore zastrzeżenie mam do fizyki skoku. Dlaczego w pewnym momencie nasz bohater zupełnie nagle wytraca prędkość w poziomie i spada pionowo w dół, zamiast odbyć całość skoku płynnym łukiem?
Jest to co najmniej dziwne i mam nadzieję, że zostanie poprawione. Dużo uroku dodałaby też możliwość nie tylko schylania się, ale i czołgania (jak w Ricku).
Bardzo doceniam możliwość zmiany koloru monochromatycznej grafiki, przy czym brakuje porządnej opcji typu amber.
Silnik działa też naprawdę nieźle (brawo!), przy czym spore zastrzeżenie mam do fizyki skoku. Dlaczego w pewnym momencie nasz bohater zupełnie nagle wytraca prędkość w poziomie i spada pionowo w dół, zamiast odbyć całość skoku płynnym łukiem?
Jest to co najmniej dziwne i mam nadzieję, że zostanie poprawione. Dużo uroku dodałaby też możliwość nie tylko schylania się, ale i czołgania (jak w Ricku).
Bardzo doceniam możliwość zmiany koloru monochromatycznej grafiki, przy czym brakuje porządnej opcji typu amber.
11.08.2023 23:36
[#106]
Re: Tony - development nowej gry
@Jacques, post #104
Skakanie w grze od początku było tak zaplanowane. Nie ma paraboli, a podczas spadania lecimy pionowo w dół. Tak w sumie to od początku sugerowałem się filmikiem z wersji Atari którą pisał sam XXL (demoscenowiec Atari) no i tak to zakodowałem. Z czasem jedynie dodałem lepszą dynamikę wzbijania się w górę i opadania. Co do czołgania to zrezygnowaliśmy z tego. Gra ogólnie ma być trudna chociaż od wersji 1.2 jest łatwiej. Teraz mając eliksir można nim pozbyć się wszystkiego oprócz głazów i płomieni, co teraz moim zdaniem jest zbyt łatwe.
Co masz na myśli opcję typu amber?
Ostatnia aktualizacja: 11.08.2023 23:37:26 przez tukinem
Co masz na myśli opcję typu amber?
Ostatnia aktualizacja: 11.08.2023 23:37:26 przez tukinem
12.08.2023 09:38
[#107]
Re: Tony - development nowej gry
@tukinem, post #106
Od początku, ale trochę średnio... Wersja Atari nie ma w tej chwili nawet kodera i to była chyba tylko wprawk/przymiarka xxl-a.
W Montezumie skok po paraboli był idealny, a tutaj XXI wiek i tak dziwnie
Wersja amber, czyli fajny schemat oddający kolorystykę monitora bursztynowego, bo to co jest w obecnej wersji tak za bardzo nie podpada pod to.
W Montezumie skok po paraboli był idealny, a tutaj XXI wiek i tak dziwnie
Wersja amber, czyli fajny schemat oddający kolorystykę monitora bursztynowego, bo to co jest w obecnej wersji tak za bardzo nie podpada pod to.
13.08.2023 21:31
[#108]
Re: Tony - development nowej gry
@Jacques, post #107
Zawsze mogę spróbować podmienić którąś paletę na bursztynową. Podaj mi tylko jakie to są kolory w RGB (0-15).
Może faktycznie to była tylko przymiarka XXLa. Nie wiem. Natomiast taki skok bez tej końcówki paraboli przy spadaniu jest tak zaprojektowany przez Rafała (brata XXLa), a że Rafał tutaj decyduje o wszystkim, a mnie takie skakanie łatwiej było zakodować więc tak zostaje. Czy wszystkie gry muszą mieć jednakowe sterowanie?
Co do kodera na Atari to mamy już nowego, który bardzo szybko nadrobi bo C64 i Atari używają tego samego asemblera. Gorzej z muzyką do gry.
Może faktycznie to była tylko przymiarka XXLa. Nie wiem. Natomiast taki skok bez tej końcówki paraboli przy spadaniu jest tak zaprojektowany przez Rafała (brata XXLa), a że Rafał tutaj decyduje o wszystkim, a mnie takie skakanie łatwiej było zakodować więc tak zostaje. Czy wszystkie gry muszą mieć jednakowe sterowanie?
Co do kodera na Atari to mamy już nowego, który bardzo szybko nadrobi bo C64 i Atari używają tego samego asemblera. Gorzej z muzyką do gry.
14.08.2023 20:26
[#111]
Re: Tony - development nowej gry
@tukinem, post #108
Spróbuj użyć kolorów z palety zrobionej pod Vice:
Bursztynowy to byłby niby biały, czyli #E46617, chociaż pod Photoshopem wygląda na nieco zbyt ciemny. Moim zdaniem.
#
# VICE Palette file
#
# Syntax:
# Red Green Blue Dither
#
# Black
45 34 36 0
# White
E4 66 17 0
# Red
65 2D 2A 0
# Cyan
AA 4C 2A 0
# Purple
70 32 2B 0
# Green
9D 46 2A 0
# Blue
42 26 28 0
# Yellow
D8 61 21 0
# Orange
79 35 2B 0
# Brown
4E 29 29 0
# Light Red
92 41 2A 0
# Dark Gray
5A 2C 2A 0
# Medium Gray
89 3D 2A 0
# Light Green
E2 65 23 0
# Light Blue
81 3A 2A 0
# Light Gray
C6 59 24 0
Bursztynowy to byłby niby biały, czyli #E46617, chociaż pod Photoshopem wygląda na nieco zbyt ciemny. Moim zdaniem.
14.08.2023 23:51
[#119]
Re: Tony - development nowej gry
@Jacques, post #117
Zawsze można się pobawić i kolor poprawić rainbowem lekko żeby nie był jednolity góra i dół lekko ciemniejsze a środek jaśniejszy, chociaż bez AGA mogą być widoczne przeskoki koloru jeśli użyję rainbow. No i wtedy do każdej palety byłby inaczej pisany.
Co do koloru ala Neptun, to był ten zielono-biały ale to wklepałem tak "na swoje oko". Bursztyn dodałem jako nową paletę żeby nic nie usuwać co było.
W sumie dawno tu nic nie pisałem więc może od razu napiszę jak z płynnością gry. Otóż odzyskałem minimalnie szybkość dzięki przepisaniu sterowania z Blitz Basic do Asemblera. Natomiast zmieniłem sposób wyświetlania obiektów, które się nie przesuwają. Gra dostała dużego kopa. Mogłem powrócić do wielu pierwotnych założeń Rafała, gdzie było dużo obiektów w komnatach. Nieprzesuwalne obiekty wstawiam przez Blit. Te, które się przemieszczają to już są wstawiane przez BBlit (jako boby). Animacja wody w drugim levelu wstawiana jest przez BlockScroll, który jest szybki tak jak Block, ale nie używa banku grafik, a kopiuje obszar z innej bitmapy którą mamy w tle. Pełna wersja gry będzie wymagać 1MB fast ramu (slow ramu), bo niestety nie zmieszczę wszystkiego o 0.5MB, a kto wie co jeszcze będzie. Wiem że ma być jeszcze nowy obiekt w grze jako przeciwnik. Oprócz tego piramida będzie większym levelem niż zamek z wersji demo.
Gra zmieści się spokojnie na 2 ADFach. Nauczyłem się pakować i rozpakowywać dane (moduły też co jest najważniejsze) dzięki czemu zaoszczędziłem masę miejsca. Bitmapy z kolizjami zmniejszyłem z 352x188 do 176x94 a kolizje sprawdzam bez dzielenia współrzędnych X i Y przez 2, a jako X LSR 1 i Y LSR 1.
Ktoś tu wcześniej pisał że taki zapis to użycie asemblera. No nie jest tak akurat. X LSR n to funkcja z Blitz Basic, natomiast LSR.w #n,X ti jest dopiero zapis z użyciem asemblera. To tak gwoli ścisłości, bo mi się rzuciło w oczy.
Żeby nie było kolorowo, to mam dziwny problem, bo przy uruchamianiu gry z HDD wszystko działa super. Bootując z ADFa i uruchamiając 3 level, spokojnie zmieniam ADF na drugi i level się ładuje. Natomiast jeśli spod uruchomionego systemu odpalę grę z ADFa to przy 3 levelu nie załaduje się gra. Po zmianie ADFa na drugi dysk gra przestaje się wczytywać. Póki co albo można grać całkiem z HDD albo z ADF przez zabootowanie gry.
góra i dół lekko ciemniejsze a środek jaśniejszy, chociaż bez AGA mogą być widoczne przeskoki koloru jeśli użyję rainbow. No i wtedy do każdej palety byłby inaczej pisany.Co do koloru ala Neptun, to był ten zielono-biały ale to wklepałem tak "na swoje oko". Bursztyn dodałem jako nową paletę żeby nic nie usuwać co było.
W sumie dawno tu nic nie pisałem więc może od razu napiszę jak z płynnością gry. Otóż odzyskałem minimalnie szybkość dzięki przepisaniu sterowania z Blitz Basic do Asemblera. Natomiast zmieniłem sposób wyświetlania obiektów, które się nie przesuwają. Gra dostała dużego kopa. Mogłem powrócić do wielu pierwotnych założeń Rafała, gdzie było dużo obiektów w komnatach. Nieprzesuwalne obiekty wstawiam przez Blit. Te, które się przemieszczają to już są wstawiane przez BBlit (jako boby). Animacja wody w drugim levelu wstawiana jest przez BlockScroll, który jest szybki tak jak Block, ale nie używa banku grafik, a kopiuje obszar z innej bitmapy którą mamy w tle. Pełna wersja gry będzie wymagać 1MB fast ramu (slow ramu), bo niestety nie zmieszczę wszystkiego o 0.5MB, a kto wie co jeszcze będzie. Wiem że ma być jeszcze nowy obiekt w grze jako przeciwnik. Oprócz tego piramida będzie większym levelem niż zamek z wersji demo.
Gra zmieści się spokojnie na 2 ADFach. Nauczyłem się pakować i rozpakowywać dane (moduły też co jest najważniejsze) dzięki czemu zaoszczędziłem masę miejsca. Bitmapy z kolizjami zmniejszyłem z 352x188 do 176x94 a kolizje sprawdzam bez dzielenia współrzędnych X i Y przez 2, a jako X LSR 1 i Y LSR 1.
Ktoś tu wcześniej pisał że taki zapis to użycie asemblera. No nie jest tak akurat. X LSR n to funkcja z Blitz Basic, natomiast LSR.w #n,X ti jest dopiero zapis z użyciem asemblera. To tak gwoli ścisłości, bo mi się rzuciło w oczy.
Żeby nie było kolorowo, to mam dziwny problem, bo przy uruchamianiu gry z HDD wszystko działa super. Bootując z ADFa i uruchamiając 3 level, spokojnie zmieniam ADF na drugi i level się ładuje. Natomiast jeśli spod uruchomionego systemu odpalę grę z ADFa to przy 3 levelu nie załaduje się gra. Po zmianie ADFa na drugi dysk gra przestaje się wczytywać. Póki co albo można grać całkiem z HDD albo z ADF przez zabootowanie gry.