26.01.2020 00:30
[#306]
Re: Jump! (Amiga Yoomp)
@Kefir_Union, post #216
Piękne.
Miałem małą przerwę od PPA i teraz patrzę a tu takie cuda.
O dziwo mi bardzo podoba się muzyka. Ma taki klimat jakby to było demo scenowe. Co do grywalności nie ma się na razie co wypowiadać, ale graficznie ładnie to wygląda.
Jedyne co, to myślałem, że to tunel będzie się obracać a nie piłka krążyć po tunelu ( czyli że piłka stoi w miejscu i przy ruchu joystickiem w prawo tunel obróci się w lewo a piłka będzie w miejscu ). Ale tak jak jest też jest dobrze, tylko ciężko będzie się grać jak piłka będzie na górze tunelu ( ciężko z ogarnięciem kierunku lewo-prawo ).
Brawo.
Miałem małą przerwę od PPA i teraz patrzę a tu takie cuda.
O dziwo mi bardzo podoba się muzyka. Ma taki klimat jakby to było demo scenowe. Co do grywalności nie ma się na razie co wypowiadać, ale graficznie ładnie to wygląda.
Jedyne co, to myślałem, że to tunel będzie się obracać a nie piłka krążyć po tunelu ( czyli że piłka stoi w miejscu i przy ruchu joystickiem w prawo tunel obróci się w lewo a piłka będzie w miejscu ). Ale tak jak jest też jest dobrze, tylko ciężko będzie się grać jak piłka będzie na górze tunelu ( ciężko z ogarnięciem kierunku lewo-prawo ).
Brawo.
26.01.2020 16:52
[#309]
Re: Jump! (Amiga Yoomp)
@AmmigaCDTV, post #308
Myślałem o tym i kierownica była przygotowywana jako idealny kontroler do takiego sterowania ale ostatecznie zrezygnowałem. Odwrotne sterowanie na godzinie dwunastej to jest taka immanentna cecha tej gry i bardzo dobrze że powoduje zwiększenie trudności.
Po pewnej wprawie przychodzi to zupełnie naturalnie, jak jazda samochodem, nie zastanawiasz się gdzie są odpowiednie pedały tylko naciskasz.
Po pewnej wprawie przychodzi to zupełnie naturalnie, jak jazda samochodem, nie zastanawiasz się gdzie są odpowiednie pedały tylko naciskasz.
01.02.2020 22:41
[#312]
Re: Jump! (Amiga Yoomp)
@Kefir_Union, post #309
Może tym razem napiszesz czy trafiłem lub chociaż czy jestem bliżej prawdy niż poprzednio?
Tak jak poprzednio myślę że użyłeś animacji tunelu, a raczej połówkę animacji tak jak w Stardust:
https://codetapper.com/amiga/sprite-tricks/stardust/
wydawało mi się że tam jest użyty blitter do odbijania animacji, ale się pomyliłem, blitowanie tego na ekran było by zbyt czasochłonne, to jest trick z copperem i ujemnym modulo.
Myślę że wykorzystujesz osobno parzyste i osobno nieparzyste bitplany bo to jest narzucone przez użycie modulo. Jeden zestaw 4 bitplanów jest dla animacji, dlatego kafle mają bazowo 16 kolorów, pozostałe 4 bitplany umożliwiają modyfikację bazowego koloru na 16 różnych sposobów (poprzez blitowanie "gładkich" prostokątów kafli), ale raczej będzie 14 (lub mniej) zestawów kolorów bo 1 lub 2 zestawy musisz poświęcić na kolor czarny żeby "wygasić" kafel oraz biały dla gwiazd i może jeszcze na coś...
Za pomocą coppera (tak jak w Stardust) możesz w odpowiednim miejscu dać ujemne modulo i odbić animację symetrycznie w pionie co widać na kafelkach pionowych, skrajnie bocznych - są one idealnie symetryczne (poza momentem obrotu tunelu gdzie pojawiają sie glicze).
Oczywiście ograniczenia podobnie jak poprzednio czyli tekstura i kształt kafla nie może się zmieniać.
Natomiast nie bardzo mam pomysł na znaczki na kaflach, to znaczy jakiś mam ale wydaje mi się kiepski więc go nie opiszę.
Jeszcze mam pytanie nie dotyczące sposobu działania: czy robiłeś już jakieś testy pod wersję OCS/ECS? Czy będzie taka sama liczba kafli widoczna?
Tak jak poprzednio myślę że użyłeś animacji tunelu, a raczej połówkę animacji tak jak w Stardust:
https://codetapper.com/amiga/sprite-tricks/stardust/
wydawało mi się że tam jest użyty blitter do odbijania animacji, ale się pomyliłem, blitowanie tego na ekran było by zbyt czasochłonne, to jest trick z copperem i ujemnym modulo.
Myślę że wykorzystujesz osobno parzyste i osobno nieparzyste bitplany bo to jest narzucone przez użycie modulo. Jeden zestaw 4 bitplanów jest dla animacji, dlatego kafle mają bazowo 16 kolorów, pozostałe 4 bitplany umożliwiają modyfikację bazowego koloru na 16 różnych sposobów (poprzez blitowanie "gładkich" prostokątów kafli), ale raczej będzie 14 (lub mniej) zestawów kolorów bo 1 lub 2 zestawy musisz poświęcić na kolor czarny żeby "wygasić" kafel oraz biały dla gwiazd i może jeszcze na coś...
Za pomocą coppera (tak jak w Stardust) możesz w odpowiednim miejscu dać ujemne modulo i odbić animację symetrycznie w pionie co widać na kafelkach pionowych, skrajnie bocznych - są one idealnie symetryczne (poza momentem obrotu tunelu gdzie pojawiają sie glicze).
Oczywiście ograniczenia podobnie jak poprzednio czyli tekstura i kształt kafla nie może się zmieniać.
Natomiast nie bardzo mam pomysł na znaczki na kaflach, to znaczy jakiś mam ale wydaje mi się kiepski więc go nie opiszę.
Jeszcze mam pytanie nie dotyczące sposobu działania: czy robiłeś już jakieś testy pod wersję OCS/ECS? Czy będzie taka sama liczba kafli widoczna?
04.02.2020 23:22
[#320]
Re: Jump! (Amiga Yoomp)
@Kefir_Union, post #1
czacha dymi.. ale rozdzielczosc na tych obrazkach to 640x512, przeskalowanie 320x256 nie da takich ladnych rezultatów.. i jak policzyłem kolory z obrazków referencyjnych to wychodziło ponad 22 tys. tak jakby ta gra pracowała w HAM8.. ogólnie szacun.. jakbyś to wypuścił na androida albo iphone to zyskałoby taki rozgłos jak Angry Birds czy coś :)
05.02.2020 08:41
[#321]
Re: Jump! (Amiga Yoomp)
@mateusz_s, post #320
To są zrzuty ekranu z gry, bez żadnych manipulacji. Rozdzielczość to 320x256 z podwojonymi do publikacji pikselami do 640x512 żeby było wygodniej oglądać. Liczba kolorów może wychodzić tak duża ponieważ kompresja jpg jest stratna i wprowadza dodatkowe, pośrednie kolory na obszarach o mniejszym kontraście.
05.02.2020 11:20
[#325]
Re: Jump! (Amiga Yoomp)
@Solo Kazuki, post #322
Trochę się chyba pospieszyłeś z tym stwierdzeniem że to jest realtime, w którym to miejscu Kefir napisał że to jest realtime?
Chyba że chodziło ci o to stwierdzenie:
"No pewnie że nie jest. Zrobiłem programową implementację rdzeni RTX i liczę w czasie rzeczywistym, stąd potrzebny procesor aż 020 i fast"
ale wiesz to Kefir sobie jaja robił...
Poza tym skoro jest planowana wersja na ECS to raczej potwierdza że nie jest to obliczeniowo złożone.
Ostatnia aktualizacja: 05.02.2020 11:24:15 przez Zbych
Chyba że chodziło ci o to stwierdzenie:
"No pewnie że nie jest. Zrobiłem programową implementację rdzeni RTX i liczę w czasie rzeczywistym, stąd potrzebny procesor aż 020 i fast"
ale wiesz to Kefir sobie jaja robił...
Poza tym skoro jest planowana wersja na ECS to raczej potwierdza że nie jest to obliczeniowo złożone.
Ostatnia aktualizacja: 05.02.2020 11:24:15 przez Zbych
05.02.2020 11:23
[#326]
Re: Jump! (Amiga Yoomp)
@Sventevith, post #323
Gdyby taka gra pojawiła się w czasach premiery A1200 ... była by killer appem.
Niestety, zdolni atarowcy musieli ją stworzyć dopiero jesienią roku 2007
https://yoomp.atari.pl
Ostatnia aktualizacja: 05.02.2020 11:25:49 przez Jacques