Odp: szybkie wektory na przerwaniu pokeya
z tym, że przerwanie raz ma wystąpić po CLI a raz nie, wszystko w zależności od nachylenia rysowanej linii co przekłada się na wartość w liczniku zliczającym do zera
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
z tym, że przerwanie raz ma wystąpić po CLI a raz nie, wszystko w zależności od nachylenia rysowanej linii co przekłada się na wartość w liczniku zliczającym do zera
Jasne. Ciekawy pomysł.
No właśnie zrozumiałem że w zależności od DeltaX lub DeltaY jest określona częstotliwość licznika (timera) i na tej podstawie w ciągu głównym się rysuje X lub Y jest na IRQ zwiększany. Ale nie wiem czy to może być wystarczająco precyzyjne. Ale pomysł ciekawy :) Przyznaję iż zupełnie bym w ten sposób nie pomyślał :) Czy jest to do zrealizowania nie wiem. Nie miałbym chyba cierpliwości aby próbować :)
Brawa za oryginalny pomysł. Jednak szczerze wątpię, czy uda się osiągnąć sensowną dokładność - przeszkadza m.in. DMA. Tak jak pisał Seban, możesz pozbyć się STA $d209. Testy na Atari800 (Win) możesz sobie darować, przerwania POKEYa są tam bardzo niedokładne.
dzięks. Właśnie sprawdziłem program po lekkiej modyfikacji na sprzęcie i o dziwo okazuje się, że Atari800Win bardzo podobnie rozkładał linie jak Atarynka, zaś w wersji 1.7 Altirra ma jakiś błąd fałszujący działanie programu przy przerwaniach Pokeya, zresztą słychać to podczas odgrywania muzy, nie wiem jak jest w nowszych wersjach.
Z precyzją jest problem, ale może uda się to jeszcze skalibrować.
w załączniku wspomniany FastDraw Konop-a, procedura rysowania linii jest rozpisana rozkaz po rozkazie, wcześniej oczywiście inna procedura odpowiednio modyfikuje odpowiedni kod jednej z ośmiu rozpisanych linii draw0, draw1 ... draw7
org draw0
_dr00 lda $ffff,y
ora #$80
_dr01 sta $ffff,y
dex
beq _out0
_dr02 lda $ffff,y
ora #$40
_dr03 sta $ffff,y
dex
beq _out0
_dr04 lda $ffff,y
ora #$20
_dr05 sta $ffff,y
dex
beq _out0
_dr06 lda $ffff,y
ora #$10
_dr07 sta $ffff,y
dex
beq _out0
_dr08 lda $ffff,y
...
...
...
Ostatnio edytowany przez tebe (2011-08-19 20:26:06)
Teraz jest Altirra 1.9, a nawet 2.0 beta.
Po przemyśleniu sprawy moje zwątpienie w sukces nieco się zmniejszyło.
Porównaj to, chyba będzie trochę szybsze:
clc
draw
tax
ora:sta (scr_ptr),y
dec dy
beq draw_end
tya
adc #$20
tay
txa
cli:sei
bcc draw
inc scr_ptr+1
clc
jmp draw
irq
mvx #0 ^2e
inx:stx ^2e
lsr @
bcc irq_rti
ror @
iny
irq_rti
rti
Ostatnio edytowany przez Fox (2011-08-19 20:41:41)
M0 ora $ffff,y
M1 sta $ffff,y
inc M0+2
inc M1+2
16 cykli do przodu / blok 8 pix
7 cykli do tyłu raz na blok 8 pix
9 cykli do przodu w pełnym rozrachunku
Umieszczenie na zpg poprawi odrobinę wydajność.
EDIT:
Statystycznie lepszym wariantem jest dokonywanie skoku gdy C = 1, co będzie miało miejsce najwyżej jeden raz na 8 pix. Zyskujemy w ten sposób 1 cykl przy zwiększeniu współrzędnej X.
lsr @
bcs skok
rti
skok ror *
iny
rti
Ostatnio edytowany przez Marek Konopka (2011-08-19 23:00:16)
dzięki za sugestie, postaram się to przyswoić i może przyspieszyć działanie, ale radykalnych zmian już raczej nie zrobię, bo musiałbym od początku eksperymentalnie dobierać częstotliwość występowania przerwań dla każdego nachylenia w obrębie ćwiartki koła.
Statystycznie lepszym wariantem jest dokonywanie skoku gdy C = 1, co będzie miało miejsce najwyżej jeden raz na 8 pix. Zyskujemy w ten sposób 1 cykl przy zwiększeniu współrzędnej X.
to można jeszcze odwrócić kierunek rysowania linii i zamiast zabawy LSR,BCC,ROR użyć po prostu:
cmp #$80
rol @
Zapomniałeś o iny. Musi to nastąpić w ściśle określonym przypadku (przekroczenie bajtu) i w związku z tym trzeba dodać skok, co pogorszy czas wykonywania tego wariantu.
Ostatnio edytowany przez Marek Konopka (2011-08-20 13:43:10)
fakt :) masz rację :)
mały updejt, procka gotowa, pozostało jeszcze zrobienie procki kasowania linii
edit:
stosunek czasu do długości linii :
najlepszy przypadek -0.19, najgorszy- 0.45
dla porównania trzy testy procki z paczki MADS : najlepszy przypadek - 0.45, najgorszy -0.53
Ostatnio edytowany przez gorgh (2011-09-01 14:04:41)
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.074 sekund, wykonano 10 zapytań ]