[#1] A może by tak Yoomp! OCS ?
Tak się zastanawiam czy ciągnąć ten projekt, czy dużo jest osób chętnych żeby zagrać w wersję ocs (z dopalaczem) zwłaszcza patrząc na to co przygotowuje Kefir.
Pierwotnie chciałem napisać na gołą A500 ale szybko się okazało że nawet A1200 bez fast ramu nie daje rady przy tym co sobie założyłem, więc jeśli dojdzie do skutku to gra będzie wymagać troszkę fast ramu i procek ok. 14 MHz (choć z testów wynika że wszystko zależy od dopałki). W każdym razie ma to być dość wierny port tego co zrobiłem na C64 ale z większą liczbą kolorów i większą rozdziałką tunelu. Powoli sobie dłubię, ale patrzę na screeny z tego co robi Kefir i wygląda to obłędnie, więc mam trochę wątpliwości czy to ma sens.
Tak to na razie wgląda, oczywiście muzyka jest testowo i grafika pewnie jeszcze się zmieni.


Ostatnia aktualizacja: 01.08.2019 20:07:25 przez Zbych
2
[#2] Re: A może by tak Yoomp! OCS ?

@Zbych, post #1

A czemu nie? Kefir robi swoje, a Ty swoje. Przecież poziomy będą się od siebie różnić praktycznie wszystkim, więc moim zdaniem warto. Więcej na pewno jest osób posiadających OCS/ECS (i też dopalone), niż sprzętu z AGA.
[#3] Re: A może by tak Yoomp! OCS ?

@Zbych, post #1

Odpowiadając na pytanie zawarte w tytule - JAK NAJBARDZIEJ TAK!!!
[#4] Re: A może by tak Yoomp! OCS ?

@Zbych, post #1

Jasne TAKKKK !
[#5] Re: A może by tak Yoomp! OCS ?

@Zbych, post #1

TAAAAAK!!!!
[#6] Re: A może by tak Yoomp! OCS ?

@Zbych, post #1

rób synek a nie p.... itol :)
[#7] Re: A może by tak Yoomp! OCS ?

@Zbych, post #1

Jak najbardziej tak
Mówi Ci to jeden z młodszych użytkowników i posiadaczy Amigi (rocznik 98’) OK
[#8] Re: A może by tak Yoomp! OCS ?

@Bartek2075, post #7

super pomysl, lecz moim zdaniem muzyka byla lepsza na atari niz c64. wpadala w ucho i byla zsynchronizowana z uderzeniami pilki.
[#9] Re: A może by tak Yoomp! OCS ?

@Zbych, post #1

ZBYCH - ROBIĆ I NIE MARUDZIĆ .

Tamta wersja wygląda obłednie, ale Twoja jest bardziej wierna oryginałowi. Jako fan Yoompa stwierdzam, że z przyjemnością zagrałbym w Twoją jak i w tamtą. Zresztą Yoomp to na tyle świetna gra, ze nigdy dosyć. Poproszę o inne plansze niz w edycjach na Atari i C64 i będzie wypas. Nie porzucaj tego projektu!
[#10] Re: A może by tak Yoomp! OCS ?

@micromax, post #8

super pomysl, lecz moim zdaniem muzyka byla lepsza na atari niz c64. wpadala w ucho i byla zsynchronizowana z uderzeniami pilki.

Nie wiem w którym momencie na C64 muzyka nie była zsynchronizowana, nie zdarzyła mi się taka sytuacja. Grałeś na real C64 czy wywnioskowałeś to na podstawie filmików? Bo na większości filmików wygląda że się nie synchronizuje ale to problem kodeków/graberów i raczej wynika ze sposobu generowania obrazu przez C64.
Co do samej muzyki to każdy ma swój gust ja tam wole wersje C64 ze wspaniałymi basami.
[#11] Re: A może by tak Yoomp! OCS ?

@Zbych, post #10

widzialem na real c64. nie istotne. wazne aby byla i na amidze.
3mam kciuki
[#12] Re: A może by tak Yoomp! OCS ?

@Zbych, post #10

Mam jeszcze jeden dylemat: czy dodać możliwość uruchomienia gry na gołej A500 ale z drastycznie pogorszoną jakością. Żeby zachować taką samą liczbę kolorów i szybkość rozgrywki musiałem znacznie zmniejszyć rozdzielczość tunelu więc finalnie niektóre piksele są większe niż na C64. Myślę że to wygląda baaaardzo kiepsko, a nawet może wywołać hejt w w stylu "jak można coś tak brzydkiego napisać". Poza tym możliwość uruchomienia na gołym sprzęcie to też więcej kodzenia dla mnie więc nie spieszy mi się do takiego rozwiązania.
Z drugiej zaś strony może lepiej dać możliwość uruchomienia nawet w kiepskiej jakości niż wyświetlać ekran z komunikatem "Sorry your cpu is too slow". No i tak się zastanawiam co lepiej.

Tak to wygląda w niższej jakości:
[#13] Re: A może by tak Yoomp! OCS ?

@Zbych, post #12

Albo zoptymalizować jeszcze to, co jest?
A odpowiadając na pytanie - jasne, że rób!
Będzie kolekcjonerka w pudełeczku?
[#14] Re: A może by tak Yoomp! OCS ?

@_arti, post #13

Powstaje nowa, odmieniona i wypasiona wersja AGA, to może ta osobna przeznaczona dla OCS powinna jak najwięcej czerpać z Atari 8-bit - koncepcyjnego prekursora Amigi?
Fajnie jakby była podrasowana wersja na miarę OCS i Pauli, czyli w podstawie te same poziomy, muzyka wzorowana na atarowskiej, idealnie synchronizująca się z dźwiękiem odbijania piłki i pól specjalnych (czego nie było na C64)?

Byłoby to coś pięknego, wierna wersja 16-bit tylko z lepszą grafiką i muzyką dostosowaną do Pauli, a nie zupełnie inną.

Trzymam kciuki, zapowiada się świetnie.

Ostatnia aktualizacja: 02.08.2019 11:41:42 przez Jacques
[#15] Re: A może by tak Yoomp! OCS ?

@Zbych, post #1

fajnie, czekam ! bedzie co testowac na mojej a500 z wichrem :)
[#16] Re: A może by tak Yoomp! OCS ?

@_arti, post #13

Albo zoptymalizować jeszcze to, co jest? (...)

Ciężko, bo nie mam już pomysłu na dalszą optymalizację. Przyznaję że nie pisałem jeszcze pod MC68xxx (no chyba że przepisanie kodu z gazety 20 lat wstecz się liczy ) więc może nie znam różnych tricków. Próbowałem kilka sposobów rysowania tunelu, operując na bajtach i na długich słowach ale to dawało zysk tylko na procesorach z wyższej serii. Chyba że da się jakoś przyspieszyć dostęp do pamięci CHIP przez CPU. Chętnie posłucham jakichś wskazówek.
[#17] Re: A może by tak Yoomp! OCS ?

@Zbych, post #16

Głównym wcinaczem dostępu do CHIPu jest Denise.

- jeśli nie używasz sprajtów to je wyłącz.
- w ilu kolorach otwierasz ekran? Czy dasz radę tutaj zredukować?
- ubijasz system żeby nic Ci w tle nie latało?
- używasz blittera? Jak tak to sam na rejestrach czy używasz funkcji systemowej? Czy zawsze blitujesz przez wszystkie bitplane'y? Jak tak, to czy aktualizujesz je jednym blitem czy n blitów, gdzie n to liczba bitplane'ów?
- możesz skrócić wysokość ekranu żeby Denise przez mniejszą część klatki robiła dostępy do CHIPu. Zwolnisz tym samym cykle dla cpu i blittera.

Sam CPU nie będzie najszybszy bo jest w stanie najszybciej dostawać się do CHIPu co drugi cykl. Aby mieć dostępy cykl-w-cykl potrzebujesz użyć również blittera.

Zawsze możesz zrobić mega pixelozę w trybie copperchunky ;d

Ostatnia aktualizacja: 02.08.2019 12:41:13 przez teh_KaiN
[#18] Re: A może by tak Yoomp! OCS ?

@Zbych, post #1

Robić - ja wolę wersję C64
[#19] Re: A może by tak Yoomp! OCS ?

@Zbych, post #16

Mozesz wkleic tutaj jakas procedure, ktora zuzywa sporo czasu procesora, to sie zobaczy o ile mozna ja przyspieszyc.
[#20] Re: A może by tak Yoomp! OCS ?

@Don_Adan, post #19

A co do muzyki, to jak masz dobrego muzyka to mozna dac muzyke do wyboru w menu:
1. Atari 800
2. C64
3. Amiga v1
4. Amiga v2
Dla takich gier to jest najlepsze rozwiazanie, kazdy sobie wybierze jaka lubi sluchac. Tez w Lotusie lubilem sobie muzyke wybierac.
[#21] Re: A może by tak Yoomp! OCS ?

@Don_Adan, post #19

Co mogę powiedzieć:
- sprajt potrzebny mi do piłki więc nie mogę go wyłączyć
- bitplany podzieliłem na 2 grupy pierwsza to tunel druga to tło, pierwotnie planowałem dual playfield ale potem wpadłem na pomysł żeby zrobić przyciemnianie środka tunelu z użyciem EHB (BTW czy ktoś wie dlaczego na emu 1200 czasami bez powodu wyłącza się tryb EHB i tam gdzie powinny być przyciemnione kolory dostaję kolor czarny nie wiem czy na real maszynie tez tak będzie...) raczej potrzebuję wszystkie bitplany
- system wydaje mi się że ubijam... do początkowej inicjalizacji użyłem tego kodu link dostosowałem go do mich potrzeb
- bliter używam tylko do rysowania cienia, czyli 1 bitplan, operuję bezpośrednio na rejestrach

Mógłbym zmniejszyć ekran ale myślę że to niewiele pomoże. Z tego co mi się wydaje to potrzebuję przyspieszyć około 3x aby osiągnąć to co mam teraz z fast ramem i cpu 14mhz więc raczej marne szanse.

Tunel rysuje się przez powtarzanie sekwencji:
MOVE.B $606A(A0),D0
OR.B $406A(A0),D0
OR.B $2069(A0),D0
OR.B $0069(A0),D0
MOVE.B D0,(A1)+


Ostatnia aktualizacja: 02.08.2019 14:53:11 przez Zbych
[#22] Re: A może by tak Yoomp! OCS ?

@Zbych, post #21

Pracuj na słowach 16-bitowych będzie 2x szybciej bo 2x mniej powtórzeń sekwencji.
Przy słowach 32 bitowych jeszcze trochę szybciej, około 2.5x przyspieszenia.
Jeśli to możliwe wartości ofsetów trzymaj w rejestrach danych, lub gotowe adresy w rejestrach adresowych (kompaktowy kod - szybsze wykonanie).
Oczekiwane przez Ciebie przyspieszenie wydaje się być osiągalne.

Jakoś tak:
lea $606a(a0),a2
lea $406a(a0),a3
lea $2069(a0),a4
lea $0069(a0),a5

loop:
move.l (a2)+,d0
or.l   (a3)+,d0
or.l   (a4)+,d0
or.l   (a5)+,d0
move.l d0,(a1)+
dbf    d1,loop



Ostatnia aktualizacja: 02.08.2019 15:27:12 przez makarsky
[#23] Re: A może by tak Yoomp! OCS ?

@makarsky, post #22

Dane do offsetów nie są liniowe, ale coś mi podpowiedziałeś. Mógłbym spróbować coś takiego:
move.w (a0)+,d0   ;odczyt offsetu
move.b (a1,d0.w),d1
or.b (a2,d0.w),d1
or.b (a3,d0.w),d1
or.b (a4,d0.w),d1
move.b d1,(a5)+

Musiałbym to sobie przetestować.
Operacje na 32 bitach raczej odpadają bo do każdego rysowanego bajtu musiałbym dokładać LSL.L #8,d1 i 4x zwieszyć pamięc tekstury, albo bez lsl około 16x zwiększyć ilość pamięci na teksturę (obecnie jest to prawie 100kb).
[#24] Re: A może by tak Yoomp! OCS ?

@makarsky, post #22

Tutaj musialby uwazac na odczyt/zapis spod nieparzystego adresu, bo sie wywali na 68000. $2069(a0) lub $606a(ao) jest na pewno na nieparzystym adresie zaleznie od wartosci A0.

Ostatnia aktualizacja: 02.08.2019 16:18:21 przez Don_Adan
[#25] Re: A może by tak Yoomp! OCS ?

@Zbych, post #23

To Ci nie zadziala, to jest zbyt wolne. Musisz przeorganizowac dane w takim razie. Zeby najlepiej dalo sie dzialac w pelni na dlugich slowach, a minimalnie na slowach. O bajtach zapomnij. Nie trzeba uzywac lsl.l #8,d1 sa szybsze metody na 68000.

Ostatnia aktualizacja: 02.08.2019 16:20:42 przez Don_Adan
[#26] Re: A może by tak Yoomp! OCS ?

@Zbych, post #12

Szczerze mówiąc wygląda to gorzej niż na C64. Może da się wykorzystać 6502, który w Amidze obsługuje klawiaturę?
[#27] Re: A może by tak Yoomp! OCS ?

@Kefir_Union, post #26

Szczerze mówiąc wygląda to gorzej niż na C64. Może da się wykorzystać 6502, który w Amidze obsługuje klawiaturę?

Wyczuwam w tej wypowiedzi nutkę złośliwości.
W każdym razie dlatego głęboko się zastanawiam czy będzie możliwość uruchomienia na gołej A500.
Mam jeszcze ze 2 pomysły do sprawdzenia, ale nie wierze żeby one mogły znacząco wpłynąć na szybkość.
Na razie wracamy do punktu wyjścia bo nie widzę możliwości zastosowania żadnej z podanych propozycji.
Chodzi o to że offsety w kodzie :
MOVE.B    $6068(A0),D0
     OR.B    $4068(A0),D0
     OR.B    $2070(A0),D0
     OR.B    $0070(A0),D0
     MOVE.B  D0,(A1)+
      MOVE.B    $6070(A0),D0
     OR.B    $4071(A0),D0
     OR.B    $2071(A0),D0
     OR.B    $0072(A0),D0
     MOVE.B  D0,(A1)+

są za każdym razem inne i bliżej środka układu coraz bardziej się różnią, nie widzę możliwości reorganizacji tych danych. Mogę spróbować zamienić na operacje 16 bitowe ale wątpię żeby to miało znaczący wpływ, ale sprawdzę i pomierzę to.
[#28] Re: A może by tak Yoomp! OCS ?

@Zbych, post #27

Oj tam od razu złośliwości

Zamiast przesuwania bitów użyj instrukcji swap. Do zapełnienie długiego słowa potrzeba dwóch swap i jeden lsl.
[#29] Re: A może by tak Yoomp! OCS ?

@Zbych, post #27

Musialbys dluzszy kod dac/wkleic, bo tak to nie wiem dlaczego nie mozesz miec pogrupowane $6068(A0) razem z $6070(A0), albo $4068(a0) z $4071(a0) itd .Tylko sa tam jakies inne dane jeszcze. Wedlug mnie wersja wordowa bylaby chyba najlepsza (jest dwa razy szybsza), pewnie tablice bylyby wieksze ale powinno sie wszystko zmiescic. Poza tym jedna rzecz jeszcze, czy dane spod adresu A0 sa modyfikowane w ogole przez cos? Czy to sa stale jakies tablice raz inicjowane czy wczytane?
[#30] Re: A może by tak Yoomp! OCS ?

@Kefir_Union, post #26

Może da się wykorzystać 6502, który w Amidze obsługuje klawiaturę?
To nie jest 6502.
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem