26

(108 odpowiedzi, napisanych Programowanie - 8 bit)

Szczerze i bez ironii: powodzenia. Osobiście trzymam kciuki za twój projekt, ale jeśli masz już dosyć komentarzy, to przystopuj trochę.

27

(7 odpowiedzi, napisanych Zloty)

Obejrzyjcie www.riverwash.info i powiedzcie, co o tym sądzicie?

Jestem za. Jeśli tylko starczy kasy, to w tym roku jadę.

28

(7 odpowiedzi, napisanych Zloty)

Jeśli jadę, to tylko pociągiem.

Jakie są koszty orientacyjne?

29

(24 odpowiedzi, napisanych Programowanie - 8 bit)

Zenon/Dial napisał/a:

Kiedy "owoc" pokosztujemy ?

Nie mam pojęcia, ale raczej nie na foreverze. Narazie to jest jeszcze etap doprowadzania techniki do jakichś ogólnych standardów.

30

(24 odpowiedzi, napisanych Programowanie - 8 bit)

No to trochę mi się rozjaśniło. :) THX wszystkim za sugestie.

Dely, Wasze wsparcie jest dla mnie nieocenione - nic nie motywuje bardziej do dalszej pracy. Dziękuję. :)

31

(24 odpowiedzi, napisanych Programowanie - 8 bit)

Wczoraj wnikliwiej wczytałem się w artykuł Krógera o wypełniankach z któregoś Seriousa, i poruszyło mnie. Kolega pisze tam o półprekalkach typu stablicowanie współrzędnych bryły po rotacji. Zaznacza jeszcze, że jest to dopuszczalne i sam tego używa, co mnie ucieszyło. :) Zaraz też przyszło mi do głowy, że w takiej tablicy możnaby umieścić również kolory wierzchołków dla gouarda, czy współrzędne tekstury dla environmental mappingu - zamiast wyliczać z dot productów i innych intensywnych działań. Nie znam dokładnie obyczajów koderów 8-bit, dlatego pytam: czy dopuszczalny prekalk to poprostu taki, który nie jest animką, czy też granica jest ściślejsza?

32

(8 odpowiedzi, napisanych Bałagan)

Ja również podpisuję się pod listą życzeń :]

33

(16 odpowiedzi, napisanych Software, Gry - 16/32bit)

Jeśli chodzi o ST (i po części Falcona), to Saulout podrzucił mi kiedyś kilka dobrych doxów:

http://matlos.w.interia.pl/ASM_BOOK.ZIP
http://matlos.w.interia.pl/atariSTtut.rar.zip
http://matlos.w.interia.pl/ingram.rar

Sporo ciekawych rzeczy jest też na http://ihrisko.cyberio.org/~mikro/

34

(10 odpowiedzi, napisanych Programowanie - 8 bit)

"zjedz jeszcze bardziej 20 tys to z tego co pamietam ilosc cykli miedzy wywolaniami przerwania wygaszania pionowego"

Zauważyłem dziwną (?) rzecz. Jak wspominałem, ekran ma rozmiar 80x59. Efekt wykorzystuje z tego obszar maksymalnie 80x44 (i pożera 21 600 cykli). Wtedy 15 linii na dole jest nietkniętych. Jeżeli przesuniemy obraz o te 15 linii w dół, tak że to część górnej połowy jest nietknięta, migotanie w okolicach środka już nie występuje i synchro się trzyma.

Jeżeli ktoś wie dlaczego dopiero w takich warunkach, prosiłbym o wyjaśnienie.

W każdym razie dzięki wszystkim za pomoc! :)

35

(10 odpowiedzi, napisanych Programowanie - 8 bit)

drac: troszkę namieszałem... vbl jako procedura o nazwie #nmi. To jest ten fragment:

nmi
_day ldy #0
          jsr efekt
          inc _day+1

         rti

xxl: obniżyłem do ok. 16 000 cykli (w najgorszym wypadku) i problem z liniami dalej obecny :(. Dmactl natomiast podczas przerwania nie jest modyfikowany. Znaczy że powinien być?

36

(10 odpowiedzi, napisanych Programowanie - 8 bit)

Yello!
Mam pewną procedurkę w VBL'u, która rysuje co ramkę coś na ekranie, tyle że podczas wyświetlania pojawiają się pewne drobne niepożądane efekty.

Korzystam z trybu GTIA - 80x59, 16 odcieni i po cztery linie o tym samym adresie. W pewnych miejscach (okolice środka ekranu) szwankuje synchronizacja i domyślam się że przyczyną jest moje (niewłaściwe?) podejście do VBL'a. Ustawienie adresu procedury wygląda tak:

    lda 20
    cmp 20
    beq *-2

      sei
    lda #0
    sta $d40e     ;wyłączamy nmi
    lda #$fe
    sta $d301     ;wyłączamy OS

    lda #<nmi
    sta $fffa
    lda #>nmi
    sta $fffb       ;adres przerwania

    lda #$40
    sta $d40e    ;zezwalamy tylko na vbl

I po tym następuje już tylko:

loop    jmp loop

I odtąd praktycznie działa już tylko przerwanie. Wygląda tak:

_day    ldy #0
    jsr efekt
    inc _day+1

    rti

Efekt jest więc liczony podczas powrotu pionowego, podczas którego jeśli dobrze rozumiem, Antic czeka aż VBL zakończy działanie. VBL się kończy, Antic przystępuje do wyświetlania linii, a w tym czasie program nie modyfikuje zawartości ekranu, dlaczego więc w pewnych miejscach niektórych linii pojawia się coś np. takiego:

01 43 [>]12 21 23[<] 13 ... etc, aż do czterdziestego bajtu  \
01 43 [>]34 44 51[<] 13 ... etc                               >4 linie o tym samym adresie
01 43 [>]86 00 64[<] 13 ... etc                              / 
01 43 [>]11 21 23[<] 13 ... etc                             /

hm?

I jeszcze jedno: kiedy obciążę tą procedurkę graficzną trochę bardziej, to przez kilka(-naście,-dziesiąt,-set, zależnie od obciążenia) pierwszych ramek norma jest wyrabiana, a potem procedura przerwania zdaje się nie móc dobrnąć do końca.

Co należy zrobić żeby wyeliminować usterki?

37

(23 odpowiedzi, napisanych Zloty)

Również dołączam się do opinii o party i wszystkich pozdrawiam!

38

(88 odpowiedzi, napisanych Zloty)

No to czekają mnie urodziny na party :)
99% i 21xtak!

39

(6 odpowiedzi, napisanych Programowanie - 8 bit)

Rozumiem że:
alfa - kąt obrotu wokół osi x
beta - y
gamma - z

Jak coś przekręciłem to poprawić.

Wzorki wyszły Ci trochę inne, a i wyniki też nieco się różnią (jeśli obrót punktu wokół osi z o 180 stopni powinien dać zmianę znaku współrzędnej y, a dopiero spostrzegłem że tak chyba ma być, to są OK), ale nie wchodząc w szczegóły, samą ideę już łapię. Wielkie dzięki. Na QP'06, jeśli będę, jeszcze raz stawiam Alpen Golda. :)

40

(6 odpowiedzi, napisanych Programowanie - 8 bit)

No okay mikey, ale mi chodzi o to jak te równania wyprowadzono. Poprostu chciałbym je zrozumieć, a nie tylko zrzynać i implementować. ;)

41

(6 odpowiedzi, napisanych Programowanie - 8 bit)

Rzecz idzie jakoś tak:

We precalculate these constants everytime we change an angle

    xx = [cos(A)cos(B)]
    xy = [sin(A)cos(B)]
    xz = [sin(B)]

    yx = [sin(A)cos(C) + cos(A)sin(B)sin(C)]
    yy = [-cos(A)cos(C) + sin(A)sin(B)sin(C)]
    yz = [-cos(B)sin(C)]

    zx = [sin(A)sin(C) - cos(A)sin(B)cos(C)]
    zy = [-cos(A)sin(C) - sin(A)sin(B)cos(C)]
    zz = [cos(B)cos(C)]

and the rotation becomes somewhat easier

    x'' = x * xx + y * xy + z * xz
    y'' = x * yx + y * yy + z * yz
    z'' = x * zx + y * zy + z * zz

No i dla mnie bomba, sprawdzałem na papierze że wzory sensowne i dają chyba poprawne obroty, ale ni cholery nie widzę związku z tymi prostszymi równaniami, które można spotkać w typowych książkach. Stąd prosiłbym uprzejmie o namiary na jakieś rzeczowe artykuły, ewentualnie własną interpretację powyższego wycinka.

greetz ;)

42

(10 odpowiedzi, napisanych Bałagan)

Wszystkiego dobrego i Wesołych (tylko bez przesady... :) ) Świąt.

A na Sylwestra - mocnej gorzały i tęgiej głowy.

43

(21 odpowiedzi, napisanych Programowanie - 8 bit)

"pod Emulcem masz swietny Debuger"

Może błędnie przypisuję swój odchył początkującym koderom, ale chyba spora część stawiających wczesne kroki w asmie olewa debuggera, choć to najważniejszy obok książki przewodnik. Polecam pobawić się tym narzędziem, bo jest przydatne tak na początku, gdy trzeba zaznajomić się z podstawowymi "kaprysami" 6502, jak i w późniejszej drodze, kiedy będziesz pisał słupki kodu po 1000km długości i wystąpią pierwsze trudności z ogarnięciem tego całego bałaganu. :)

Nie wspominam już o tak oczywistych tipsach jak modlitwa do Ducha Św... ;)

BTW: Gdy już nie będzie wątpliwości "Assembler - jak", ale "Assembler - co", to warto zajrzeć tutaj:

http://www.ffd2.com/fridge/chacking/

Mag jest o C64, ale jako że i Commodor i Atarka posiadają procesor z tej samej rodziny i natrafia się na te same problemy pisząć np. wektorówkę, polecam serię artykułów od numeru #8. Wcześniej warto byłoby jednak zaprzyjaźnić się z ANTICiem (http://www.s-direktnet.de/homepages/k_nadj/main.html) i wykonać kilka prostych programików dla nabrania wprawy i oswojenia się z asmem, np:

-generowanie xor-tekstury i przerzucenie na ekran w postaci kwadratu
-stawianie pikseli o określonych współrzędnych
-przenikanie bitmap
-rozmycie bitmapy (tudzież efekt ognia)
-wykres sin/cos
-plasma
-rysowanie linii wg Bresenhama

To kilka propozycji wg których ja rozpocząłem swoją naukę w praktyce, i przy których zobaczyłem pewne rezultaty.

Happy coding i pozdro :)

44

(4 odpowiedzi, napisanych Programowanie - 8 bit)

pr0be:

"zamiast wypelniania 2cykli/pixel bedziesz miec 4cykle/pixel"

No, to jest prawda. Ale trzeba jeszcze spojrzeć wstecz na proces obróbki piksela. Chcemy np. postawić zapalić punkt o zadanych współrzędnych. Zabawa z połówkami bajtów oczywiście nie jest przesadnie ciężka, ale czy dla nibble'ów da się zrobić równie szybką (i prostą na dodatek) procedurkę jak:

    lda kolor
    ldy x_pos
    sta (line_adr),y

Jeszcze więcej zalet ukazuje chunk przy efektach typu blur (przynajmniej póki nie zna się sensownych tricków, które dałyby speeda). Pozostaje więc troska o szybką prockę do przerzucenia bufora... Twoja zdaje się niezła.

tebe:

Jeśli masz jakiś prosty programik z wykorzystaniem tego egzotyka, to mile widziany! Trochę ciężko sobie wyobrazić jak działa.

pr0be & tebe:

Dzięki chłopaki!

45

(4 odpowiedzi, napisanych Programowanie - 8 bit)

Tak sobie myślę, że operowanie na 4-bajtowych wartościach w mode 9 jest niezbyt szybkie, a i wygoda pisania wszelakich operacji

na obrazie w trybach tego typu pozostawia do życzenia. Nasunął mi się więc banalny pomysł, żeby zrobić dwa tylne bufory - jeden

standardowy, a drugi z jednobajtowymi wartościami kolorów pikseli. Nie wiem czy jasno tłumaczę: jeśli normalnie mamy dla dwóch

punktów coś takiego:

#$AF

to w back-backbufferze jest to rozpisane jako:

#AA, #$FF

Tak więc proces chunk2nibble przebiega w następujący sposób:

    ldx #59        ;59
yeh    ldy cnt2        ;licznik dla chunkbufora

kp    lda (c_bufpnt),y
    and #$F0        ;lewy nibble
    sta lewy
    iny        ;next bajt
    lda (c_bufpnt),y
    and #$0F        ;prawy nibble
    ora lewy        ;sklej
    iny
    sty cnt2
    ldy cnt1        ;licznik dla ekranu
    sta (scrpnt),y    ;na bufor, tudzież ekran

    iny
    sty cnt1
    cpy #40
    bne yeh

Do tego dochodzi oczywiście przeładowanie adresów, które też zabija sporo cykli (nawet jeśli na raz załatwimy więcej niż jedną

linię, jak w przykładzie). Jeśli za pomocą tej procki przerzucam chunk'a bezpośrednio na screen, to niestety widać jak wszystko się

rysuje, a dodatkowego bufora nie chcę angażować. W związku z tym dwa pytania:

1. Jak to zrobić żeby chodziło w jednej ramce (niekoniecznie optymalizując mój kod - może stosując inne techniki?)
2. Czy to ma wogóle sens?

Z góry jak zawsze THC.

46

(5 odpowiedzi, napisanych Bałagan)

Chodzi oczywiście o kolory. Gdyby GTIA oferował szerszą możliwość zmiany palety w szesnastokolorowym grayscale, nie byłoby problemu. A tak różnica między zapisem grzybowym a atarowskim uwidacznia się pod postacią efektu "powywracanych" barw.

Czy istnieją jakieś programy, które potrafią zapisać bitmapę jako indexed color zgodnie ze standardem GTIA'owskim?

47

(33 odpowiedzi, napisanych Zloty)

Z mojej strony podziękowania za Waszą życzliwość.

PS. Spoko, jeszcze ze dwa party i oduczę się debilizmu, tylko dajcie piwa. :)

48

(50 odpowiedzi, napisanych Scena - 8bit)

Jeśli nie znajduje Ci biblioteki conio.h, to wrzuć ją do folderu z projektem i zamiast pisać w programie <conio.h> zastosuj "conio.h" (nazwa pliku objęta cudzysłowiem). Powinno pomóc, choć to hamska metoda.

49

(11 odpowiedzi, napisanych Scena - 8bit)

Takie buty...

A to nie ujmuje realizmu obrotowi (rotacja skokowa)? Jeśli nie stanowiłoby problemu, mógłbym Cię prosić o ciut szersze wyjaśnienie?

50

(11 odpowiedzi, napisanych Scena - 8bit)

"Ogólnie, nie podoba mi się ten kod, zacznij uczyć się może assemblera od czegoś prostszego, poważnie"

Tak kiedyś myślałem że może lepiej scrolla na początek, ale potrzebowałem czegoś, co nie wymagało znajomości ANTICA, tylko czystego 6502. A że nic innego mi do głowy nie przyszło, to bierze się traktorzysta za ferrari. :) Postaram się dokładnie zanalizować wszystkie uwagi (dziękuję za odzew, dla mnie to ważne, bo sam sobie - jak eru dobrze zauważyłeś - nijak radzę) po rozłączeniu z TPSA.

pozdrawiam

[ Dodano: Pon Sty 24, 2005 10:10 ]
eru:

"Jeśli już, to asl+rol. A poza tym, nie łatwiej przepisać bajtów całych?"
Nie jestem kumaty w slangu. Możesz wyjaśnić na przykładzie?

"Ojej. I czemu chcesz używać 360 stopni? Używaj 256, to znacząco ułatwia życie"

Tzn. przy obrocie o 360 robimy najpierw 256 i później tak obrócone punkty dodatkowo ruszamy o 64 stopnie?

"Poza tym, w Rotate na oko w X i Y wstawiasz to samo, zupełnie bez sensu, nic nie kumam już."

Nie tylko w X i Y, ale także w Z :). Inne są jedynie zmienne kątów i sinusów (_sinx, _siny, _sinz...), a reszta rzeczywiście identyczna. Chciałem kiedyś zrobić pętlę na jednej procedurze, ale był problem ze zmianą adresu etykiety. Teraz dopiero się domyślam, jak to wykonać - czy poprawne będzie coś w stylu:

    ldy #2            ;przesunięcie
    lda katx,y        ;katx+2b = katy

"Czemu indeksujesz (sinus)?"
Myślałem, że (zmienna),y dodaje do adresu wartość z y. Robi to więc sinus,y?
BTW: rol katx+1 - tak się da, czy tylko w taki sposób jak u Ciebie?

pr0be:

Co do przykładu 1: chodzi więc poprostu o coś w stylu xchg ah, al, tzn. zamianę bajtów miejscami?

"ale jesli to ma byc prosta scena 3d najlepszym i najszybszym sposobem jest zrobienie sobie tablicy sin(a)*x"

Myślę że na początek rzeczywiście dobry sposób, a ja niepotrzebnie komplikuję sobie zabawę...

Zdaje sobie sprawę, że moja "pryczka" w obecnym stadium nie nadaje się do czegokolwiek poważniejszego (chyba, że nadrobiłoby się dizajnem, narazie jednak chodzi o samo zrozumienie kodowania), ale gdyby poprawić wytłuszczone przez Was błędy, to jest szansa na jakiś obrót (choćby 8 punktów w ramce ;)), czy pisać to od początku trzeci raz?