Nie można pogrupować ponieważ dane na ekran są zapisywane liniowo po bajcie. Gdyby posortować offsety to wtedy zapis danych skakałby po ekranie i wielokrotnie OR-ował te same bajty. W obecnej postaci offsety są pogrupowane tak żeby tworzyć bajt i tylko raz zapisać go do pamięci. Optymalizacja tego algorytmu to grupowanie danych w większe paczki i zapis długich słów MOVEM.
Ostatnia aktualizacja: 03.08.2019 08:59:05 przez Kefir_Union
Nie sadze, zeby zapis movem.l cokolwiek zmienil dla 68000, grupowanie bajtow w dlugie slowa jest na 68000 zbyt wolne, to bedzie jeszcze wolniej dzialalo. Byc moze zapis movem.w moglby byc szybszy. Ale i tak trzeba by dane pogrupowac/przerobic. Specjalista od grupowania danych i nowych procedur graficznych jest hexmage, moze on ma jakis pomysl?
Jest dokładnie tak jak napisałeś. Już wcześniej zastanawiałem się czy nie spróbować posłużyć się MOVEM, ale patrząc na układ ekranu to maksymalnie uzyska się przesłanie 3 rejestrów 32 bitowych, a w większości przypadków będą to 2 a potem trzeba przesunąć wskaźnik docelowy. Robiłem testy ze zwykłym move na 32 bitach i tak jak wspomniałem zysk było widać dopiero po ustawieniu procka wyższego niż 68000. Nie sprawdzałem MOVEM bo po uzyskaniu dobrego wyniku na 14MHz nie szukałem dalej, ale może zrobię krok wstecz i spróbuje takie coś wykonać.
Najwolniejszy jest dostęp do pamięci, sama instrukcja MOVEM niczego magicznego tutaj nie spowoduje, co najwyżej kilka cykli przy zapisie wielu rejestrów naraz.
Testowałeś kod na zwykłej Amidze? U mnie WinUAE działa znacznie szybciej niż prawdziwy hardware, mimo ustawienia zegara na odpowiednią wartość. A1200 pod emulatorem muszę ustawić na ok 9,5MHz żeby działała z taką prędkością jak prawdziwa Amiga na 14MHz.
Ostatnia aktualizacja: 03.08.2019 11:34:11 przez Kefir_Union
Osobiście nie. Udostępniłem programik który wywołuje procedure rysującą ale nie robi swap bitplanów więc nie widać że coś rysuje. Opisałem to w tym wątku.
No i wygląda na to że działa, ale nie na wszystkich dopalaczach.
Tylko propozycja, więc proszę nie reagować gwałtownie ;)
Może skontaktuj się z KK/Altair, bo ostatnio stworzył engine 3D działający dobrze już (ponoć) na A500 z 1MB RAM. Nie wiem czy chcesz stworzyć samemu, czy rozważasz współpracę...
Obejrzałem jego seminarium z Xenium. Fajne, dowiedziałem się parę ciekawostek ale niestety to się nie przyda. Zauważ że w jego silniku nie ma tekstur na podłodze bo tu niestety blitter się nie sprawdzi. Z tego samego powodu ja też nie mogę użyć blittera bo nie ma obszarów które można by potraktować bliterem.
Poza tym ten silnik rysuje 1 klatkę na 4-5 klatek ekranu więc obawiam się że to może być za mało w grze zręcznościowej.
Na razie planuję zrobić redukcję kolorów w wersji A500 co pozwoli troszkę zwiększyć rozdzielczość tunelu.
Powolutku, niestety nie mam ostatnio czasu żeby przysiąść i porządnie zakodzić. Pracuję teraz nad menu, trzeba jeszcze dopracować parę szczegółów w grze (np. liczniki, na razie nie mam pomysłu na ich realizację i rozmieszczenie). Ostatecznie zdecydowałem że wersja A500 (7Mhz) będzie działać w 4 kolorach, a wersja na dopaloną Amigę tak jak pierwotnie czyli 8 kolorów no i wersja A500 ma minimalnie mniejszą rozdziałkę, ale już nie trak drastycznie jak to było w wersji 8 kolorów którą kiedyś tu pokazałem. Gra przy uruchomieniu będzie mierzyła szybkość i wybierała odpowiedni tryb rysowania tunelu.
Jak skończę menu to będę miał większą orientację na co mogę sobie jeszcze pozwolić i wtedy będę rozmawiał o muzyce (nieoficjalnie mogę powiedzieć że najprawdopodobniej muzykę zrobi MCH ;) ).
Jako że mamy koniec roku postanowiłem podsumować aktualny stan projektu.
Gra będzie działać w trzech trybach jakości:
niski – 4 kolory, zmniejszony rozmiar tunelu, dla A500/A600 1MB ram
średni – 4 kolory bez dodatkowego skalowania, dla A500+512 fast ram, lub goła A1200
wysoki – 8 kolorów, dla A500 z cpu 14MHz i 512 fast ram lub A1200+512 fast ram
W rzeczywistości ponieważ tunel jest rysowany w trybie EHB będzie widoczne 7 i 15 kolorów. Ogólnie gra wymaga 1MB ram mieści się na 1 dyskietce.
Kod gry jest w zasadzie gotowy, zostały jakieś zmiany kosmetyczne i usuwanie błędów jakie wyjdą podczas testów (w tej chwili jest taki problem że gra działa na emu natomiast czasami nie chce ruszyć na real A600 i A500 z 512 slow). Do zrobienia na pewno zostało kilka nowych etapów, ponieważ dodałem jeden nowy kafelek akcji (w stosunku do wersji z C64), więc trzeba go wykorzystać w nowych etapach. Poza tym czekam jeszcze na muzykę – obecnie gotowy jest jeden kawałek, a będą jeszcze 2 (jeden do menu i jeden dodatkowy do gry).
Poza tym rozpocząłem rozmowy z wydawcą więc może się okazać że zmieni się trochę grafika w grze co może wydłużyć proces jej wydania. Planowana jest też wersja dla CD32 ale raczej nie będzie się ona różnić od zwykłej wersji (chyba że ktoś mi podpowie jak zrobić obraz płyty dla CD32 zawierającej dane i audio to może pojawi się jako bonus ścieżka audio w wysokiej jakości ale raczej nie w grze a tylko do słuchania).
Przy okazji: szczęśliwego Nowego Roku dla wszystkich forumowiczów :)
Yoomp! z Atari ma 21 etapów, z C64 ma 23, a tu... zobaczymy, chciałbym przynajmniej 3 nowe, ale nie wiem jak to będzie z weną twórczą Zacząłem robić pierwszy nowy etap ale co chwilę muszę przerywać bo coś trzeba poprawić/zmienić/przetestować i nie mogę go skończyć.
Na "papierze" wygląda niby słabo, bo mało kolorów i ograniczenia.. ale obejrzałem filmik i bardzo mi się podoba, nawet wersja pod A500 z 1MB ram
Trzyma kciuki, ja chcę w to zagrać
Zapowiada się, działa i wygląda świetnie, podoba mi się, że jest zachowany rytmiczny dzwiek odbicia piłeczki, gdzie akcja niejako dopełnia muzykę jak na Atari, może powinien być jednak ciut cichszy lub o innym, mniej denerwującym tonie niż w demie.
Domyślny dźwięk odbicia nie jest pierwszy lepszy, szukałem właśnie takiego który nie będzie zbytnio drażnił, ale nie ma problemu zmniejszę głośność z 50 na 40 (64 to max) dla zwykłego i długiego skoku.
Mam 2 wiadomości dobrą i złą:
- dobra: gra dostanie nowe grafiki tła, jeszcze nie wiem ile rodzajów
- zła: gra dostanie nowe grafiki tła ale trzeba poczekać na ich zrobienie co wydłuży czas produkcji
Nie no, moje to był efekt 10 minut zabawy w Personalu. Gdyby to miało być do gry to postarałbym się trochę bardziej, żeby nie było widać "piskelowych schodków" na krzywiznach. Poza tym - trochę mniejszy kontrast by wypadało dać, bo "tło" nie może dominować pola rozgrywki. Ale pomysł od razu mi się narzucił gdy pomyślałem o takim "tunelu".
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.