forum speccy.pl
ZX Spectrum => PROGRAMOWANIE => Wątek zaczęty przez: gorgh w 2018.08.05, 20:11:35
-
właściwie to trzeci, ale pierwszy poważniejszy, działa to cholernie wolno, ale uczę się dopiero optymalizować na z80 :)
Załączam kod, byłbym wdzięczny za wszelkie uwagi :)
-
jp loop
ret
Po co ten ret???
cp 0
Krócej, bo w jednym bajcie:
or a
xor $ff
Jeśli chcesz zanegować (logicznie) akumulator, to prościej - jednym bajtem kodu:
cpl
dec b
jr nz,loop_sin2
Zamiast tych dwóch rozkazów masz jeden:
djnz loop_sin2
ld a,(hl)
ld (de),a
dec e
inc l
To jest bardzo niebezpieczne. Jesteś pewien, że rejestry e i l się nie "przekręcą"? Zamiast tego stosuj inkrementacje i dekerementacje 16-bitowe:
dec de
inc hl
add a,e
ld e,a
ld a,(de)
Uwaga j.w. Dodawanie (add a,e) może przepełnić akumulator i wtedy ld a,(de) pobierze wartość spod adresu, którego nie przewidziałeś. Chyba, że przewidziałeś, stosując jakąś niesamowitą sztuczkę :) (nadal nie rozumiem Twojego algorytmu).
-
Dziękówka za uwagi, przepełnienie rejestrów niczym nie grozi bo dane są pobierane z jednej strony pamięci ($7000-$70ff) i to tak ma działać
-
W domu rzucę na to okiem dokładniej (podoba mi się efekt!:) pomyśl aby zrobić to na atrybutach wtedy można na cały ekran to zrobić i będzie duuuuużo szybsze :)
jr z, nxt_line
jp loop_calc
nxt_line
można
jp nz,loop_calc
nxt_line
Ogólna uwaga - aby procedury szybciej działały zamiast jr... używaj jp... 1 bajt więcej ale szybciej działa.
Zapis w pamięci jest dużo wolniejszy od operacji na rejestrach - używaj alternatywnych rejestrów (exx, ex af,af')
-
dziękuweczka za uwagi Dalthon, właśnie tak sobie pomyślałem, żeby użyć exx, nie wiedziałem,że operacje na pamięci są wolniejsze od rejestrów, zapamiętam
-
Ogólna uwaga - aby procedury szybciej działały zamiast jr... używaj jp... 1 bajt więcej ale szybciej działa.
A żeby uściślić - warunkowe JR ma różne czasy wykonania zależnie od tego, czy warunek jest spełniony (12 t-states) czy nie (7 t-states), warunkowe JP ma zawsze 10 t-states.
JP warto używać w kodzie, który ma się wykonywać "równo" (efekty na borderze, dokładna synchronizacja do rastra) albo w sytuacji, gdy np. przewidujemy "krótką" pętlę (czyli warunek może być spełniony bądź nie mniej więcej w równych proporcjach). Jeśli kod będzie się "kręcił" dość długo w jednym miejscu i wyskakiwał warunkowo raz na jakiś czas (czyli przez większość czasu "przelatywał" przez skok) to bardziej się opłaca JR. Oczywiście w takiej sytuacji dobrze jest przeliczyć takty zużywane na obsługę i np. główną pętlę robić na JR (o ile sięgnie) a warunki na JP itp.
Za każdym razem jeśli kod ma być szybki należy mu się przyjrzeć z tabelką rozkazów i policzyć co się bardziej opłaca. A już najlepiej - jeśli mamy miejsce w pamięci - rozwinąć wszystko co się da rozwinąć ;)
-
dzięki matofesi,
posiedziałem trochę nad kodem i tak jak radziliście zmieniłem operacje na pamięci na operacje na rejestrach, kod obliczający wartość poszczególnych pixeli wcześniej wyglądał tak:
ld a,(s1)
add a,2
ld (s1),a
add a,e
ld e,a
ld a,(de)
ld e,0
ld (byte1),a
ld a,(s2)
add a,3
ld (s2),a
add a,e
ld e,a
ld a,(de)
ld e,0
ld (byte2),a
ld a,(s3)
add a,6
ld (s3),a
add a,e
ld e,a
ld a,(de)
ld e,0
ld (byte3),a
ld a,(s4)
add a,8
ld (s4),a
add a,e
ld e,a
ld a,(de)
ld e,0
push hl
ld hl,byte1
add a,(hl)
jr nc,forw1
inc e
forw1
inc l
add a,(hl)
jr nc,forw2
inc e
forw2
inc l
add a,(hl)
jr nc,forw3
inc e
forw3
pop hl
teraz wygląda tak:
exx
ld a,b
add a,2
ld b,a
ld (for_sinus1+1),a
for_sinus1
ld a,($7000)
ld (for_add1+1),a
ld a,c
add a,3
ld c,a
ld (for_sinus2+1),a
for_sinus2
ld a,($7000)
ld (for_add2+1),a
ld a,d
add a,6
ld d,a
ld (for_sinus3+1),a
for_sinus3
ld a,($7000)
ld (for_add3+1),a
ld a,e
add a,8
ld e,a
ld (for_sinus4+1),a
for_sinus4
ld a,($7000)
exx
ld e,0
for_add1
add a,0
jp nc,for_add2
inc e
for_add2
add a,0
jp nc,for_add3
inc e
for_add3
add a,0
jp nc,finished
inc e
finished
I działa to znacznie szybciej :)
-
Nie analizując dogłębnie algorytmu zasugeruję jeszcze jedną rzecz - używasz "sla a" do mnożenia przez dwa. To jest wysoce nieekonomiczne - sla to 8 t-stateów a "add a,a" robiące w tym wypadku to samo tylko 4. Niby grosze, ale jednak ;)
Poz tym jeśli masz stosunkowo krótką pętlę DJNZ do przy każdym jej "obrocie" tracisz 13 t-stateów - jeśli nie ma ograniczeń co do rozmiaru kodu rozwiń pętlę np tak:
; ld b,$40
rept $40
;loop_sin2
ld a,(hl)
cpl
ld (de),a
inc e
inc l
endm
; djnz loop_sin2
Na każdej trzech pętli oszczędzisz ponad 800 t-stateów.
Pewnie jakby się temu przyjrzeć z głębszą analizą samego algorytmu dałoby się urwać jeszcze coś ;)
-
wow dziękuweczka, cenne rady panie!
-
Na każdej trzech pętli oszczędzisz ponad 800 t-stateów.
Akurat ta procka jest wywoływana tylko 1 raz, ale rozpętlanie kiedyś się na pewno przyda
-
Akurat ta procka jest wywoływana tylko 1 raz
No widzisz... tak to jest jak się człowiek skupia na szczegółach a nie na szerszym obrazie ;)
-
spoczko, ale jestem wdzięczny za wszelkie uwagi, z80 to zupełnie inna filozofia niż 6502/6510
-
To może jeszcze takie coś:
set_vars
ld a,(x1)
add a,4
ld (sb1),a
sub 3
ld (x1),a
ld a,(x2)
add a,7
ld (sb2),a
sub 5
ld (x2),a
ld a,(x3)
add a,3
ld (sb3),a
sub 6
ld (x3),a
ld a,(x4)
add a,1
ld (sb4),a
add a,4
ld (x4),a
ret
Reorganizacja kolejności oszczędza ci przy każdym wywołaniu cztery dostępy do pamięci. Też grosze, ale w niektórych sytuacjach może się opłacać ;)
-
faktycznie :)
-
I jeszcze jedna rzecz... Tym razem w procedurze rysującej. Najpierw sama procedura (od loop_draw):
loop_draw
ld a,(hl)
add a,a
add a,a
inc hl
add a,(hl)
add a,a
inc hl
push hl
ld h,high pixels
ld l,a
push bc
ld b,(hl)
inc l
ld c,(hl)
ex de,hl
ld (hl),b
inc h
ld (hl),c
inc h
ld (hl),c
inc h
ld (hl),b
ex de,hl
dec d
dec d
dec d
pop bc
pop hl
A do tego zmieniona tablica pikseli:
pixels
db 0,0,0,6,9,6
db 15,15,0,96,0,102
db 9,102,15,111,144,96
db 144,102,153,102,159,111
db 240,240,240,246,249,246
db 255,255
Modyfikacja najpierw zmienia liczenie przesunięcia w tablicy pikseli tak, żeby indeksować do tablicy dwu- a nie cztero- bajtowej (usunięcie jednego add a,a). Dalej zapamiętujemy na stosie BC a następnie dwa bajty piksela ładujemy do B i C. Zamieniamy HL z DE (bo nie da się wrzucić B lub C pod adres z DE) i ładujemy piksel z B i C zamiast czytać za każdym razem z pamięci. Dzięki temu dla każdego piksela czytasz dwa razy zamiast czterech i nie musisz dodatkowo inkrementować L przed kolejnymi odczytami. Czyli ścinamy jakieś dwadzieścia t-state'ów na piksel. Nadal cudów nie ma, ale jakaś poprawa chyba jest ;)
-
ha! I to jest pomysł.
W międzyczasie zoptymalizowałem trochę procedurę liczącą pixle, że liczy się od razu 2 pixle, przy czym pierwszy pixel jest zapisywany
add a,a
add a,a
ld (for_value+1),a
A przy liczniu wartości rejestu e (zwiększanie aby pixel miał wartość od 0 do 3) zamiast zerować ten rejestr robię po prostu:
for_value
ld e,$ff
Dzięki temu ilość danych w tablicy zmniejsza się z 1024 elementów do 512 elementów i zczytywanie wartości pixla z tablicy to po prostu
ld a,(hl)
add a,a
inc hl
zamiast
ld a,(hl)
add a,a
add a,a
inc hl
add a,(hl)
add a,a
inc hl
-
A właśnie, coś budziło mój instynktowny sprzeciw, jak zobaczyłem adres początku Twojego programu. Już wiem co :)
Dolna część pamięci od $4000 do $7999 jest wolniejsza, ponieważ kiedy ULA pobiera z niej dane do obrazu, zatrzymuje zegar procesora. Więc program będzie się wykonywał szybciej jeśli umieścisz go powyżej $8000.
Tu trochę informacji https://www.worldofspectrum.org/faq/reference/48kreference.htm#Contention (https://www.worldofspectrum.org/faq/reference/48kreference.htm#Contention)
-
nice, chociaż tego artykułu na razie nie za bardzo rozumiem, muszę się wczytać
przy okazji zaoszczędziłem jeszcze 2048 cykli zastępując
inc hl
tym:
inc l
jako, że tablica, po której indeksuję ma 512 wartości to tylko raz trzeba zwiększyć h
-
nice, chociaż tego artykułu na razie nie za bardzo rozumiem, muszę się wczytać
wersja skrótowa (i wystarczającą): kod umieszczamy 32768-49151 oraz w banku 0 (49152-65535) - wszędzie indziej "działa wolniej" :)
co do bankowania: https://www.worldofspectrum.org/faq/reference/128kreference.htm - chociaż na naszym forum jest to lepiej wyjaśnione :)
-
Kod jako taki nie działa wolniej ;) Wolniej działają dostępy do pamięci (i portów). Konkretnie to jest tak, że zależnie od tego w którym dokładnie cyklu pracy ULA nastąpi próba dostępu do dzielonej pamięci (w ZXS 48 $4000-$7fff) ULA zatrzyma zegar procesora na 0-6 cykli. Kod umieszczony w tej pamięci będzie faktycznie chodził wolniej, bo jego wykonanie to również dostępy do pamięci. Ale niestety nie da się tak po prostu podać procentowo jak dużo zje ULA bo jest to mocno zależne od tego, co się wykonuje. Kod umieszczony powyżej $7fff i liczący sobie coś na danych w tym samym zakresie będzie chodził na pełnej prędkości procesora. Ten sam kod zapisujący coś do pamięci ekranu będzie zwalniany w zależności od tego w który punkt się akurat wstrzeli. Da się to wszystko dokładnie policzyć pod warunkiem, że to, co robisz da się zsynchronizować z rastrem. Jeśli nie to trzeba się po prostu dopasować "na oko" i liczyć z tym, że będzie chodzić tak jak będzie chodzić ;)
-
Aha, rozumiem. Czyli najlepiej w obszarze $5800-$7fff trzymać dane do których rzadko jest dostęp
-
Napisałem "działa wolniej" a nie działa wolniej :) :) :)
Każdy sobie sam trzyma dane w pamięci - nie ma jednego złotego wzorca :) Ja akurat tam głównie trzymam spakowane dane które sobie rozpakowuję jak są potrzebne albo składowe grafiki. Pewnie co koder, to inny rozkład danych, umiejscowienie stosu, vectora przerwań itd. itp.
-
<brawa> za wątek. Siedzę i czytam z rozdziawioną paszczą.
-
Dla mnie to fajna gimnastyka umysłowa, choć zbytnio się nie zagłębiałem w kod.
Sam niedawno usiadłem do asemblera, po ćwierć wieku przerwy. Frajda :D
-
Dawno nie było równie ciekawego wątku!
-
I to musiał się człowiek z małego Atari pojawić bo się zx'owcom nie chce kodować... :D
-
Bo nie każdy jest "koderem" a dla niektórych (np. dla mnie) BASIC jest szczytem wiedzy tajemnej. Nie przeraża mnie sam ASM, ale ilość narzędzi aby z kodu otrzymać program wykonywany w postaci pliku .tap czy .tzx.
gorgh: Czy już masz poprawioną wersję programu z początku watku? Podoba się mi efekt wizualny.
-
Nie przeraża mnie sam ASM, ale ilość narzędzi aby z kodu otrzymać program wykonywany w postaci pliku .tap czy .tzx.
Ke? Proste jak... się tutaj zajrzy: http://zxspectrumdev.blogspot.com/2009/01/setting-up-development-environment-on.html
-
Nie przeraża mnie sam ASM, ale ilość narzędzi aby z kodu otrzymać program wykonywany w postaci pliku .tap czy .tzx.
Hmmm... Jedno? ;)
pasmo --tapbas plik.asm plik.tap
-
gorgh: Czy już masz poprawioną wersję programu z początku watku? Podoba się mi efekt wizualny.
tak, załączam razem ze źródłami, prędkość mi się już podoba, trafi to do dema na forever jak Bóg da (trzeba tylko kolory odwrócić to teraz jest w negatywie)
-
Już naliczylem dwa: pasmo i emulator :P. A ZXa podpinam pod monitor i działa z BASIC :P
gorgh: :) plynny efekt wizualny pod EightyOne.
-
Już naliczylem dwa: pasmo i emulator :P. A ZXa podpinam pod monitor i działa z BASIC :P
Chciałeś przejść z kodu ASM do TAP/TZX - do tego wystarczy jedno narzędzie :P
-
Już naliczylem dwa: pasmo i emulator :P
Ke? a spojrzałeś na link który podałem? Potem działasz tylko na ConTEXT - F9 kompilujesz, F10 uruchamiasz. Wszystko dzieje się samo :P
-
Cytuje:
When I develop Machine Code games for the Sinclair ZX Spectrum, I use the following Development Tools:
•ConText Text Editor (http://www.contexteditor.org/)
•Pasmo Assembler (Pasmo)
•Spectaculator Emulator (http://www.spectaculator.com/)
Az trzy (3) programy potrzebne i pod Winzgroza :P
Ale Panowie, spokojnie, programisty ze mnie nie zrobicie. Nie ten wiek, nie te umiejetnosci, nie te zainteresowania, ale kibicuje nowemu forumowiczowi.
-
dzisiaj znowu powalczyłem, zrobiłem okręgi xorowane, działa na razie wolno, trochę wolniej od plazmy, ale jeszcze będę apelował
edit: wykorzystałem tą samą procedurę rysowania, tylko, że teraz nie są liczone odrębnie pixele, tylko w procedurze stawiającej je od razu pobierane są wartości z tablicy (dwukrotnie, bo to ta sama bitmapa tylko z przesunięciem), dlatego też można było podwoić ilość pixeli.
-
po krótkiej zabawie w efekty postanowiłem zabrać się za coś większego- planuję zrobić port Yoompa na ZX 128. Algorytm jest bajecznie prosty, tylko kod trzeba rozpętlić na jakieś 50 kb :)
-
Wszystkie dywagacje o timingach wydzieliłem do nowego wątku (http://www.speccy.pl/forum/index.php?topic=4487.msg68902).
-
szanowni koledzy, proszę o optymalizację tej procedury:
ld a,($ffff) ;13
and %11000000 ;7
ld c,a ; ;4
ld a,($ffff) ;13
and %00110000 ;7
ld d,a ;4
ld a,($ffff) ;13
and %00001100 ;7
ld e,a ;4
ld a,($ffff) ;13
and b ;4
add1
add a,c ;4
add2
add a,d ;4
add3
add a,e ;4
ld l,a ;4
ld a,(hl) ;7
ld ($ffff),a ;13
inc h ;4
ld a,(hl) ;7
ld ($ffff),a ;13
dec h ;4
Procedura ma na celu postawienie 2 bajtów (jeden pod drugim) i jest rozpętlona. Rozmiar pixela- 2 x 2. Procedura generująca hektar kodu podstawia na sztywno miejsca w tablicy z których ma się brać pixel (każdy pixel zajmuje 2 bity i jest powtórzony 4 razy w bajcie) - to rozkazy
ld a,($ffff)
rejestry c,d i e służą do przechowywania wartości danych pixli do późniejszego dodawania, rejestr b przechowuje wartość "%00000011" dla oszczędzenia 3 cykli przy rozkazie "and".
Algorytm wykonuje się w 153 T stanach, nie za bardzo mam pomysł jak to dalej optymalizować.
-
Tak na szybko i zakładając, że to jest kod samomodyfikujący i w miejsce tych wszystkich FFów coś z zewnątrz ładuje odpowiednie adresy to nie specjalnie widzę tu miejsce do optymalizacji. Jakbym nie oglądał to brakuje rejestrów ;)
-
Skoro b trzyma tylko wartość dla oszczędności and'owania to może...
ld a,($ffff) ;13
ld b,a ;4
and %11000000 ;7
ld c,a ;4
ld a,b ;4
and %00110000 ;7
ld d,a ;4
ld a,b ;4
and %00001100 ;7
ld e,a ;4
ld a,b ;4
and %00000011 ;7
i wtedy oszczędzasz 24 T...
-
fajnie by tak było, tylko, że ($ffff) to za każdym razem inna wartość
-
(https://vader.joemonster.org/upload/zox/63250352b48315sorki_potworki.jpg)
-
ha! po dwóch dniach bojów udało się!
gra będzie chodzić w 4 ramkach, niestety mniej raczej jest niemożliwe, jutro to zanimuję
-
szanowni koledzy, proszę o optymalizację tej procedury:
ld a,($ffff) ;13
and %11000000 ;7
ld c,a ; ;4
ld a,($ffff) ;13
and %00110000 ;7
ld d,a ;4
ld a,($ffff) ;13
and %00001100 ;7
ld e,a ;4
ld a,($ffff) ;13
and b ;4
add1
add a,c ;4
add2
add a,d ;4
add3
add a,e ;4
ld l,a ;4
ld a,(hl) ;7
ld ($ffff),a ;13
inc h ;4
ld a,(hl) ;7
ld ($ffff),a ;13
dec h ;4
Procedura ma na celu postawienie 2 bajtów (jeden pod drugim) i jest rozpętlona. Rozmiar pixela- 2 x 2. Procedura generująca hektar kodu podstawia na sztywno miejsca w tablicy z których ma się brać pixel (każdy pixel zajmuje 2 bity i jest powtórzony 4 razy w bajcie) - to rozkazy
ld a,($ffff)
rejestry c,d i e służą do przechowywania wartości danych pixli do późniejszego dodawania, rejestr b przechowuje wartość "%00000011" dla oszczędzenia 3 cykli przy rozkazie "and".
Algorytm wykonuje się w 153 T stanach, nie za bardzo mam pomysł jak to dalej optymalizować.
To samo w 129 taktach:
ld hl, $ffff ; 10
ld a,(hl) ; 7
and 0xc0 ; 7
ld c,a ; 4
ld a, (hl) ; 7
and 48 ; 7
or c ; 4
ld c,a ; 4
ld a, (hl) ; 7
and 12 ; 7
or c ; 4
ld c,a ; 4
ld a, (hl) ; 7
and b ; 4
or c ; 4
ld e, a ; 4
ld a, (de) ; 7
ld (hl), a ; 7
inc d ; 4
ld a, (de) ; 7
ld (hl), a ; 7
dec d ; 4
-
@Dr Piotr Robisz ten sam błąd co Dalthon. $ffff to nie jest $ffff tylko miejsce, w które inny kod wstawia adresy. Każdy może być inny.
-
A nie lepiej wstawiać te adresy do tablicy a potem odczytywać zamiast ld a,($ffff) ld a,(hl) inc hl?
-
@Dalthon Ale to są adresy. Jak je wsadzisz do tablicy, to trzeba je będzie pobrać a potem z nich dopiero pobrać właściwe dane.
-
a to się powtórzę:
(https://vader.joemonster.org/upload/zox/63250352b48315sorki_potworki.jpg)
może powinienem przyjrzeć się co to i jak ma robić zanim coś będę doradzał..
-
Nie przejmuj się - w pierwszej chwili po przeczytaniu twojego posta zacząłem już liczyć i kombinować jak to poprzestawiać. Dopiero po dłuższej chwili do mnie dotarło, że coś jednak jest nie tak ;)
-
dziękuję za wszelkie próby pomocy, dziś udało mi się zanimować tunel, na razie bez perspektywy
http://parafie.filonet.eu/misc/3.gif
-
z ciekawostek dla programistów: rozpętlony kod zajmuje 4 banki pamięci i 61 kb danych. Wywołań procedury stawiania 2 bajtów (1x4 pixele) jest 420 w ćwiartce czyli w sumie 1680. Każde wywołanie to 153 T stany. Ekran jest rysowany ćwiartkami. Tablica z danymi dla pixeli zajmuje 2500 bajtów czyli 10 stron pamięci i jest modyfikowana za każdym razem cała.
-
Dzięki wielkie za ten wątek @gorgh i @pozostali!
-
@Dr Piotr Robisz ten sam błąd co Dalthon.
A to zacytuje za Dalthonem :)
(https://vader.joemonster.org/upload/zox/63250352b48315sorki_potworki.jpg)
$ffff to nie jest $ffff tylko miejsce, w które inny kod wstawia adresy. Każdy może być inny.
Czyli samodyfikujacy sie kod, a takim razie mozna zejsc do 143 cykli:
ld a,($ffff) ; 13
and d ; 4
ld c,a ; 4
ld a,($ffff) ; 13
and e ; 4
or c ; 4
ld c,a ; 4
ld a,($ffff) ; 13
and 12 ; 7
or c ; 4
ld c,a ; 4
ld a,($ffff) ; 13
and b ; 4
or c ; 4
ld l, a ; 4
ld a,(hl) ;7
ld ($ffff),a ;13
inc h ;4
ld a,(hl) ;7
ld ($ffff),a ;13
dec h ;4
gdzies na paczatku tylko trzeba dac ld de, 0xc030 :)
-
wow Dr Piotr! Masz maga intuicję, dziękuję!
W prawdzie wychodzi 147 cykli a nie 143 ale to już oszczędność 10080 cykli na cały obraz, dzięki temu zmieszczę się w 4 ramkach z muzyką!
Dodatkowo procka jest mniejsza o 2 bajty, więc to oszczędność 3360 bajtów
Dziękuję!
Umieszczę Cię w podziękowaniach w grze
-
a tak to wygląda w praniu
-
Ciekawy efekt.
-
dziękuję Klaud
Właśnie mnie olśniło, przecież układ bitów w wyliczonym bajcie może równie dobrze służyć za pierwszy bajt do wyglądu pixeli!
więc zamiast
ld l,a ;4
ld a,(hl) ;7
ld ($ffff),a ;13
inc h ;4
ld a,(hl) ;7
ld ($ffff),a ;13
dec h ;4
jest :
ld l,a ;4
ld ($ffff),a ;13
ld a,(hl) ;7
ld ($ffff),a ;13
czyli oszczędność 15 cykli!
-
wczoraj postanowiłem sprofilować rozwinięty kod, czyli zamiast czytać za każdym razem pamięć, co zajmuje 13 cykli, w miejscach gdzie ta sama lokacja czytana jest kilka razy po prostu czytam ją jeden raz, pozwoliło to na zaoszczędzenie 48204 T stanów na cały obraz i sama procedura rysowania wyrabia się teraz w 2,44 ramki i zajmuje zamiast 56 kb tylko 40. Jest więc szansa na port dla Amstrada. W załączniku binarka.
-
Bardzo fajne efekty, choć może zamiast na Forever to na speccy.pl party? ;)
-
w sumie niezły pomysł
-
Hmmm, 40kB. Jeśli nie przełączasz video ramu, to może jest szansa, że ruszy też na gumiaku? :)
-
ZX Freeq: niestety nie, 40 kb to sam kod stawiania pixli, a dane planszy i kod gry...poza tym 48k ma 6 kb video ram :)
-
Propo Amstradowej wersji tego Yoompa. To po pierwsze wydaje mi się że na CPC jest już tego typu gierka.
A po drugie to wiesz gorgh że CPC w takiej rozdziałce jak ma ZX, ma po 2 bity na piksel a nie 1. W dodatku bity od jednego oraz sąsiednich pikseli nie są ułożone w bajcie po kolei.
-
Tak, masz rację ZbyniuR, trochę się pospieszyłem z tym Amstradem, poczytałem dzisiaj i program by chodził 20% wolniej, żadna tragedia ale mnie to chyba nie bawi, mimo 16 kolorów, może kiedyś.
Ale za to wstępnie luknąłem sobie na Gameboya i jak doczytam więcej to może, może...
-
W CPC żeby jakiś element grafiki się pojawił lub zniknął to najprościej jest zmodyfikować paletę kolorów. Zresztą w demkach jakoś się tunele robi, więc się da. Nie od razu Kraków... :)
Nie mogę sobie przypomnieć jak ta gra się na CPC nazywała.
-
Pewnie Traiblazer
https://www.youtube.com/watch?v=AV3ElKsyTro (https://www.youtube.com/watch?v=AV3ElKsyTro)
Linkowałem już Gorghowi wersję tego na ZX gdzie indziej ;)
-
Nie, takich płaskich to jest pewnie więcej.
Ale jestem pewien że przez chwilę grałem w coś podobnego tyle że w tunelu, jak się zaczęło obracać do góry nogami to traciłem orientację i wpadałem do dziury więc szybko sobie odpuściłem, a innych emulatorów niż CPC nie używam. Możliwe że to była jakaś nowa gra z ostatnich lat.
-
Tu się gorgh nie chwali, ale na http://atarionline.pl/forum/comments.php?DiscussionID=4157&page=5
już owszem, że pracuje nad Amstradową wersją.
-
Tak ZbyniuR, obie wersje będą powstawać równolegle
-
czołem panowie,
Parę dni temu wróciłem do kodowania na Z80 i skleciłem intro na party Forever, po kilku miesiącach rozłąki musiałem na nowo sobie przypominać działanie rozkazów, ale jakoś poszło. Świetną zabawę miałem z optymalizacją, jak zwykle jest to najfajniejsza część pracy.
Teraz mam w planach grę na Atari, ale zaraz po niej ruszę z tym Yoompem.
Pozdrawiam i do zo na speccy party, postaram się dotrzeć