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ć.
BigPEmu 1.12 Richard Whitehouse wydał BigPEmu 1.12
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.
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.109 sekund, wykonano 12 zapytań ]