ok.
W necie krąży sporo mitów dot. hardware i kodowania, może to być jeden z nich.
tak na szybko widzę że ustawiasz i Video Base oraz Video Counter. Ja tylko modyfikuję Video Counter.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Jak napisać grę na Atari - cz. 8 Premiera ósmej części popularnej serii poradników Larka o tworzeniu gier na Atari już 28 lipca!
TONY - Ark of the Covenant Kontynuacja przygód Tony'ego na Atari 8-bit, bez przemocy, z naciskiem na spryt i eksplorację.
ABBUC Software Contest 2025: Zgłoszenia Sprawdź aktualną listę programów zgłoszonych do konkursu ABBUC Software Contest 2025. Termin mija 31 lipca!
Gopher2600 0.50.0 Nowa wersja emulatora Atari 2600 z usprawnieniami i nowymi funkcjami debuggera.
Steem SSE 4.2.0 już dostępny Nowa wersja emulatora Steem SSE z istotnymi usprawnieniami i nowościami
atari.area forum » Posty przez Cyprian
ok.
W necie krąży sporo mitów dot. hardware i kodowania, może to być jeden z nich.
tak na szybko widzę że ustawiasz i Video Base oraz Video Counter. Ja tylko modyfikuję Video Counter.
hmm, no może.
Z tym że o tym HBLu czytałem w jakiejś dokumentacji.
a oto dalszy ciąg kodu:
scrn_poi:
REPT 2
nop
ENDR
lea Licznik_Ekranu1+1,A0 ; ustaw nowy adres ekranu
move.b (A0)+,$FFFF8205.w
move.b (A0)+,$FFFF8207.w
move.b (A0)+,$FFFF8209.w
Maciek, gdy z kodu usunę " STOP #$2300 ; wait for 1st HBL" przesuwanie ekranu traci stabilność - co jakiś czas ekran skacze. Czyli w moim przypadku zmiana $FFFF8265 od razu w VBLu nie działa prawidłowo.
W wolnej chwili mogę sprawdzić czy ze zmianą $FFFF8265 trzeba czekać do HBLa (512 cykli) czy można wcześniej jej dokonać
obaj macie rację :)
w moim teście zmieniam $FFFF8265 po pierwszym HBLu a $FFFF820F modyfikuję o 8 bajtów ( -8 bajtów dla hscroll==0) i działa to ok
Petla_VBL
STOP #$2300 ; wait for 1st HBL
move.w #$2500,SR
addq #1,D2
cmp.w #576,D2
blt.b .skip
moveq #0,D2
.skip
moveq #0,D5
move.l D2,D3
and.b #$0F,D3
move.b D3,$FFFF8265.w
bne.s fix_line
move.l Adres_Ekranu,Licznik_Ekranu1
move.b #224-80,$FFFF820F.w ; x-words
move.l D2,D3
and.w #$FFF0,D3
lsr.l #1,D3
add.l D3,Licznik_Ekranu1
bra.s scrn_poi
fix_line:
move.b #224-80-4,$FFFF820F.w
scrn_poi:
Cyprian napisał/a:obeszłe
wiesz, poszłem i obeszłem :)
obeszłe
słuszna numeracja
Atari 666XL i Atari 666ST
ta jest :)
800XL i 1029 - zestaw marzeń :)
były tam głównie 800XL i 1050. potem na jakiś czas pojawiły się dwa Amstrady 464 i 646. a coś koło 90' 286
Chodziłem tam na kurs Atari Basic. Pamiętam że było tam dwóch magików piszących w assemblerze, dzięki jednemu z nich sam zacząłem "kodować".
Do tej pory mam oryginalną dyskietkę QuickAssemblera.
w tym samym klubie, parę lat wcześniej zaczęła się moja przygoda z Atari
https://www.youtube.com/watch?v=NaVs3Iurfq8
EOR to XOR?
"source XOR destination" zabiera trzy cykle szyny (odczyt źródła, odczyt celu, zapis celu) - 12 cykli procesora
Jeśli chodzi o wstawianie instrukcji w czasie działania blittera, to chyba zadziała to tylko w przypadku trybu BLIT, czyli trybu dzielonego
Działa w każdym wariancie - BLIT i HOG. Kwestia jest tylko w tym, by wystartować BLiTTERa instrukcją typu "Class 0", np BSET, ASL, ADD itp: http://pasti.fxatari.com/68kdocs/68kPrefetch.html
A tutaj mój mały przykład:
http://www.atari-forum.com/viewtopic.php?p=96197#p96197
No ciekawe, jak wypadłby blitter w 4 planowym fillerze, ale zaczynam odnosić wrażenie, że mógłby być wolniejszy od motorli (jak sobie spojrzycie na 4 bitplanowego fillera z kilku tematów wstecz, to do wypełniania używam tam movemów i przy długich liniach robię bodajże 64 piksele na jednym movie - to może być już dla blittera za dużo).
myślę że warto by to sprawdzić w praktyce. Z tego co widzę w w przypadku wariantu CPU i MOVEMów dla każdej linii dokonujesz jeszcze fline_m i lline_m które są dość kosztowne.
Mógłbyś teoretycznie zrobić wersje mieszaną wywołującą kod cpu lub blitter'a w zależności od długości linii. Oczywiście taki warunek to dodatkowy koszt
Wachu zrobił już detekcję w kodzie, są to procedury "line0_XXX" :) Wystarczy dla odpowiednio długich podmienić kod z CPU na BLiTTERa.
Myślę że dla cztero-bitplanowego fillera proporcje mogą ulec zmianie.
Jest jeszcze jedna niewykorzystana tutaj zaleta BLiTTERa. W czasie blittingu, CPU może wykonać jedną "długą" instrukcję, np rotacje, mnożenie/dzielenie itp. Z tego co widzę w kodzie, na każdy trójkąt przypadają trzy DIVSy. Być może dało by się je sprytnie przesunąć pod blitting.
P.S. Piękny kod swoją drogą, wszystko z minimalną ilością cykli. :)
a dzięki :)
Ostatnio odbył się kompot z produkcjami na 1bitplan (na ST). Może będzie kolejny. Wtedy z 1bitplanowym fillerem będziecie do przodu :).
ten filler można zastosować również do wielu bitplanów
Jest tylko uwaga, jak dobrze pamiętam, nie jesteś fanem grania w małych okienkach, a to jest rozdzielczość 160x80, czyli przy najmniejszej rozdzielczości Falcona to jest okienko wielkości 1/4 ekranu. Więc DML zastosował tu chwyt marketingowy ;)
to patrz (i słuchaj) teraz https://www.youtube.com/watch?v=hDXSMgW-r5M
:)
i jeszcze coś mi wpadło do głowy. Czy faktycznie poniższa instrukcja jest potrzebna?
move.w d5,d3 ;4
"addq.w #1,d3 ;4" robisz w obrębie Word a nie Long
w międzyczasie wyedytowałem posta:
przemyślałem to jeszcze raz, w wariancie xCount = 1 może być problem z zastosowaniem EndMask
no tak, ale możesz dać albo:
xCount = 40 / yCount = 1
albo:
xCount = 1 / yCount = 40
z tego co pamiętam efekt jest ten sam operacja dokonywana jest na tych samych 40stu słowach.
Oczywiście w zależności od wariantu trzeba odpowiednio ustawić Destination X/Y increment.
---edycja---
przemyślałem to jeszcze raz, w wariancie xCount = 1 może być problem z zastosowaniem EndMask
faktycznie masz rację z yCount.
Ale możesz zamienić xCount z yCount (czyli również Destination X increment oraz Destination y increment) dzięki temu xCount będzie tylko raz inicjowany a yCount przed każdym blitem.
Takie rozwiązanie zastosowałem w mojej procedurze dla sprajtów:
;BLiTTER Init
move.l #$00020002,(A0)+ ; source X increment / source Y increment
move.l A2,(A0)+ ; source address
move.l #-1,(A0)+ ; mask 1 /2
move.w #-1,(A0)+ ; mask 3
move.l #$00080080,(A0)+ ; destination X increment / destination Y increment
lea 2(A0),A4 ; remember source destination
move.l A3,(A0)+ ; destination address
move.w #$0005,(A0)+ ; count X surface
movea.l A0,A1 ; remember count Y surface
move.w D0,(A0)+ ; count Y surface
move.w #$0204,(A0)+ ; HOP / LOP
move.w D4,(A0) ; BUSY / HOG / SMUDGE / LINE NUMBER // FXSR / NFSR / SKEW
; Copy MaskSprite to Screen
move.b D2,(A0) ; start blitter
REPT 3
lea 2(A3),A3
move.w A3,(A4) ; destination address
move.w D0,(A1) ; count Y surface
move.b D2,(A0) ; start blitter
ENDR
;
;BLITTER RE-INIT Sprite to Screen
lea $FFFF8A3C.w,A0
move.l A5,A3
move.w #$0207,$FFFF8A3A.w ; HOP / LOP
; Copy Sprite to Screen
move.w A3,(A4) ; destination address
move.w D0,(A1) ; count Y surface
move.b D2,(A0) ; start blitter
REPT 3
lea 2(A3),A3
move.w A3,(A4) ; destination address
move.w D0,(A1) ; count Y surface
move.b D2,(A0) ; start blitter
ENDR
z tego co widzę to masz parę rejestrów adresowych wolnych.
tak więc, tutaj mógłbyś przypisać każdej masce osobny An i zejść z 24 do 16 cykli:
move.w d0,endmsk1(a6) ;first line mask
move.w d1,endmsk3(a6) ;last line mask
tutaj również dedykowany An, dodatkowo nie ma potrzeby zmiany yCount, więc zamiast Longa możesz zapisać Word:
move.l d3,xCount(a6) ;xcount = d3, ycount = 1 at once
czyli zamiast 16 mamy 8 cykli
tu również dedykowany An:
move.b #$a0,lineNum(a6); HOG 16
zamiast 16 mamy 12 cykle
Czyli z 82 cykli inicjalizacji mógłbyś zejść do 62.
dyskietki od nastu lat leżą gdzieś na strychu. muszę odszukać pudło, potem przeczesać każdą dyskietkę. robota na cały weekend...
Może gouraud pod mono? Chyba jeszcze nikt tego nie zrobił? :P Kiedyś napisałem sobie na PieCa całkiem fajną procedurę do ditheringu. Można by ją przenieść na mono STeka. :)
w Mono? Brzmi ciekawie.
Ditherowany gouraud widziałem tylko w ST-LOW w demie: http://www.pouet.net/prod.php?which=19628 i w grze Interphase: https://www.youtube.com/watch?v=DtUfQEp … lpage#t=16
To pierwsze zrobił Martin Griffiths, źródła są dostępne w sieci. Jakby co to je mam.
tak, tak na szybko pod emu. Wieczorem będę miał więcej czasu i sprawdzę na realnym sprzęcie.
Co do blittera to słuszny kierunek.
---edycja---
działa.
ok, wiem gdzie leżał problem, popierdzielił mi się pecetowy "caps lock" z STkowym "ctrl", są one w tym samym miejscu klawiatury...
atari.area forum » Posty przez Cyprian
Wygenerowano w 0.167 sekund, wykonano 9 zapytań