Ja też jestem przekonany o konieczności wstawek w ASM chociażby przy sprajtach. Ale Gotham jest przyzwyczajony na Symbianie że C potrafi wszystko i wydaje mi się że nie zdaje sobie sprawy z tego o ile Z80 jest wolniejszy w porównaniu ze smartphonami, a do tego zakręcona organizacja pamięci graficznej która komplikuje kod i spowalnia wszelkie modyfikacje w pamięci ekranu.
Ale znalazł stronkę gdzie sprajty z NESa są rozłożone na klatki obok siebie na tym samym obrazku, co mnie cieszy.
http://www.spriters-resource.com/nes/cv/sheet/8477 <- tu i następne 2 Sheet-y.
Ja zamierzam pokonwertować mapy i sprajty i zrobić w Basicu coś co będzie ich prezentacją i edytorem. Mam znacznie więcej czasu za to większe kłopoty z natchnieniem niż on.
Przyznaję że od 4 dni nic z tym nie robiłem, a właśnie oglądając sprajty uświadomiłem sobie że aby to pasowało do map to muszę zmienić kolejność kolorów w palecie, a tym samym pokonwertować to co mam od nowa.
W każdym bądź razie na tak przygotowanych danych będzie można zależnie od natchnienia, albo pisać kod w C albo dopieszczać pikselki.
Przydałaby się procedura w ASM która przerzuca kafelki między ekranem a buforem i z powrotem (czyli dwie jej wersje). Z tym że w buforze dane o kolejnych linijkach z jakich składa się obiekt są zaraz po poprzedniej linijce, natomiast w pamięci ekranu początek każdej następnej linijki obiektu jest o 2048 bajtów dalej niż poprzednia. Tzn tak łatwo to jest tylko w przypadku gdy kafelek ma maks 8 linii w pionie. A że na razie tylko taki przypadek rozpatrujemy. To nie komplikujmy.
Kafel ma 4 bajty szerokości (2 pix w bajcie) i 8 bajtów wysokości, razem 32 bajty. I chciałbym aby można było za pomocą POKE wstawiać w nią dwa jednobajtowe parametry x i y (współrzędne lewego górnego bajta kafla na ekranie) (oba liczone od 0) oraz 2bajtowo adres bufora, który może być dowolny. I pod tym adresem jest lub ma być (zależnie od tego w którą stronę przerzucamy kafel) te 32 bajty. Natomiast w pamięci ekranu do adresu początkowego pamięci ekranu &C000 dodajemy x oraz y*80 i tam wstawiamy (lub bierzemy) 4 pierwsze bajty kafla, a kolejne 4 są 2048 bajtów dalej niż 1szy bajt 1ej linijki obiektu. I tak samo kolejne linie obiektu są o 2048 bajtów dalej niż początek poprzedniej linii. Procedura musi się kończyć RET (&C9). I żebym umiał ją wklepać z Basica podaj mi ją bajt po bajcie w Hexach, (coś jak w listingach z liniami DATA z Bajtka), bo z listingiem asemblera nie będę wiedział co zrobić. Zaznaczając w którym bajcie wstawić x,y i adrBuf. Mam nadzieję że dość jasno opisałem o co mi chodzi.
A tak w ogóle to dzięki Rafał za zaoferowanie pomocy.
