Podobnie jak mam u siebie:) Też wyznaczam min i max bez sortowania tylko chyba kierunek mam zgodny z zegarem;)

Clippingu nie mam więc nie poratuje. Chętnie zobaczę rezultat. Twoje kody traktuje edukacyjnie, parę pomysłów i wniosków dla siebie już wyniosłem. (choć i tak jestem z wydajnością jeszcze sporo za Wami hehe)

Pół mega? Dlaczego tak dużo? Nie miałem czasu zerknąć w Twój kod... ale limitująć dx do 0-255 a dy do 0-127 co już powinno wystarczyć do "życiowych trójkątów" to masz 256*128*2b = 64K - zakladajac ze wynik jest word'em. 64k jest fajne bo mozna to zalignowac i dostęp jest wygodny... No chyba, że ta tablica u Ciebie to co innego niż myśle, albo potrzebujesz większej precyzji niż ja (ja u siebie mam obie delty limitowane do 0-127 czyli 32k i taka precyzja mi wystarcza).

Co do trackerów to jest na PC też Vortex Tracker: http://bulba.untergrund.net/vortex_e.htm
Co prawda głównie dla ZX i ST pobocznie, więc nie jestem pewien czy wspiera on efekty na timer'ach - być może tylko czysty YM, nie wiem. Aha, jego player routine na ST wydawał mi się jakiś podejrzany jeśli chodzi o utylizacje cpu... Ale ogólnie słuszna droga to emulator + maxymiser lub musicmon jak napisał Bober.

Ok, wybacz kod wyjęty z większego kontekstu, ale może da jakiś obraz:

initMsxSNDH:
        move.l    #sndhPlayTimerC60,$114.w ; setup tc
        rts

sndhPlayTimerC60:
        sub.w    #SNDH_TC_REPLAY_FREQ,sndhPlayTimerC_tccount        
        bgt.s    sndhPlayTimerC_nocall
        add.w    #200,sndhPlayTimerC_tccount

        move.w    sr,-(sp)
        move.w    #$2500,sr
        movem.l d0-a6,-(a7)    
        jsr SNDH_FILE+8
        movem.l (a7)+,d0-a6
        move.w    (sp)+,sr
sndhPlayTimerC_nocall
        move.l  _old_tc(pc),-(sp)
        rts

sndhPlayTimerC_tccount    ds.w    200

SNDH_TC_REPLAY_FREQ to stała z częstotliwością grania. Kiedyś mi to działało, więc jest szansa że działa nadal;) To jest kod wyciągnięty chyba z jakiś przykładów maxymiser'a - nie pamiętam dokładnie gdzie go znalazłem.

Hej, musi działać:) poniżej kilka hintów opartych o problemy które ja miewałem:
- musisz mieć rozpakowany plik SNDH a większość jest spakowanych; do rozpakowania uzyj ICE
- init i play jak piszesz; init +0, play +8
- jeśli nadal nie działa to patrz procedure awaryjną poniżej
- zdarzyło mi się trafić na SNDH z playerami które nie backupja rejestrów, więc przed play zbackupuj rejestery dla testu by zweryfikowac czy to nie problem
- czasem player SNDH chce zaalokować pamięc, więc musimy ją zwrócić na starcie by jakaś była dostępna;) zazwyczaj przez to nie działają sndh z samplami o ile nie dasz na poczatku (pierwsze co robi Twoj kod) swojego programu:

            move.l  4(sp),a5                ; address to basepage
            move.l  $0c(a5),d0              ; length of text segment
            add.l   $14(a5),d0              ; length of data segment
            add.l   $1c(a5),d0              ; length of bss segment
            add.l   #$1000,d0               ; length of stackpointer
            add.l   #$100,d0                ; length of basepage
            move.l  a5,d1                   ; address to basepage
            add.l   d0,d1                   ; end of program
            and.l   #-2,d1                  ; make address even
            move.l  d1,sp                   ; new stackspace

            move.l  d0,-(sp)                ; mshrink()
            move.l  a5,-(sp)                ;
            move.w  d0,-(sp)                ;
            move.w  #$4a,-(sp)              ;
            trap    #1                      ;
            lea     12(sp),sp               ;  

- robisz cuda z timer'ami a SNDH wymaga timer'ów i masz problem. o ile robisz podmiany palet itp co pisałes w innym wątku to musisz mieć pewność, że nie używasz tych samych przerwań co muzyka

edit: jeśli nadal masz problem to daj znać to wyślę Ci example

Właśnie. To pewnie powoduje różnice.

A to jest ciekawe. Bo ja tego nie robię i u mnie jest OK. Ciekaw jestem dlaczego?
Gdzieś czytałem - nie pamiętam gdzie, że aby hscroll dzialal poprawnie trzeba ustawiać rejestry w ścisłej kolejności: video counter registers, hardwarescroll registers, video base registers. Może to jest u Ciebie powodem?

Hej,
Coś jest nie tak. Takie tricki nie są potrzebne. Aha, rozumiem, że chodzi o hscroll jak w tytule..... a nie vscroll jak na końcu posta, tak?
Wydaje mi się, że zapomniałeś o jednym małym ale przy aktualizacji rejestru $ffff8265. Jeżeli wrzucasz w niego coś innego niż 0 to shifter automatycznie będzie pobierać o 16px więcej z framebuffer'a.
Czyli jeśli Twoj framebuffer to 640px i robisz hscroll ste to przy przesunieciu PX = 0 (w rejestrze 8265) to szerokosc framebuffer'a ustawiasz na 640px, ale jeśli masz przesuniecie PX z zakresu 1-15 to musisz to skompensować i ustawić szerokość framebufffera na 640-16px. Pewnie tego nie zrobiłeś i dlatego przy przejsciu z zerowych na niezerowe warotości masz kaszanke.

Kod wyjęty z takeover (z boobswatch part):

boobs_hscroll_vbl:
            movem.l    d0-d2,-(a7)
            move.l  scr1,d0
            add.l    boobs_hscroll_byteOffset,d0

            move.l    d0,d1
            lsr.l #8,d1
            
            move.l    d1,d2
            lsr.w #8,d2
            
            ; video base
            move.b d2,$ffff8201.w
            move.b d1,$ffff8203.w
            move.b d0,$ffff820d.w

            ; pixel offset
            move.b boobs_hscroll_pixelOffset,$ffff8265.w
            ; line offset
            tst.b    boobs_hscroll_pixelOffset
            beq.s    boobs_hscroll_pxOffsetZero
            move.b    #76,$ffff820f.w
            bra.s    boobs_hscroll_afterPxOffset
boobs_hscroll_PxOffsetZero
            move.b    #80,$ffff820f.w
boobs_hscroll_afterPxOffset

            ; video counter
            move.b d2,$FFFF8205.w
            move.b d1,$FFFF8207.w
            move.b d0,$FFFF8209.w

            ; dodajemy
            add.b    #1,boobs_hscroll_pixelOffset
            cmp.b     #15,boobs_hscroll_pixelOffset
            ble.s    boobs_hscroll_notIncByteOffset
            add.l    #8,boobs_hscroll_byteOffset
            move.b  #0,boobs_hscroll_pixelOffset
boobs_hscroll_notIncByteOffset
            movem.l    (a7)+,d0-d2
            rts

Nie uzywałem tam nic więcej niz VBL i działało to ok. Chodzi o warunek ustawienia rejestru $ffff820f.w w zależności od ffff8265.

Rysujesz sam obrys trojkat'a. Nie linie tylko obrys tak by mieć dla każdego X dokładnie dwa punkty Y1, Y2 zapalone na ekranie. Potem robiś EOR każdej linii z linia-1. i masz wypełniony cały blitowany obszar nie zaleznie ile obrysów i i lle face'ów tam masz. czas jest stały - czasem to dobrze a czasem to źle;) Wady: blitter musi czytac i zapisywać dane przez co działa wolniej, jesli masz mało face'ów ale na wielu bitplanach to pewnie wyjdzie wolniej. Jeśli masz dużo małych face'ów np. na 2 planach to może wyjść fajnie.

@Wachu no właśnie miałem podobne obserwacje, aż moje face'y miały relatywnie krótkie linie to nie widziałem ogólnie zysku ze scan line fill na bliterze. przy duuuuzych face'a racja zysk będzie dokładnie jak to udowodniłeś.

@Adam blitterem można wypełniać kilka obiektów na raz ale nie scan line fill'em tylko eor fill'em. technika jest tu inna. no ale wtedy blitter musi czytać i zapisywać dane przez co działa wolniej. ale jest inicjalizowany raz i tak jak mówisz wypełniasz całą scenę "na raz". wszystko ma swoje wady i zalety:) dodatkowo eor fill'em dostajesz bonus wypełniania obiektów niewypukłych.

@wieczor w skali kraju faktycznie tak. w skali europy to już być może nie:)

a tak w ogóle to w dzisiejszych czasach jest już tylko jedna wspólna scena;)

Jest to Falcon 030 z 14MB i FPU a obraz mam w 256kolorach po RBG. Jest to najnowsza chyba wersja Netsurf'a która mam z http://www.netsurf-browser.org/downloads/atari/
Generalnie działa do czasu aż dostanę Bus Error;) No i demon prędkości to to nie jest hehe ale pewnie pod 060 będzie już fajnie.
Próbowałem odpalić Highwire (pod Mintem), ale stwierdził że nie podoba mu się znalezione VDI - nie miałem czasu zgłębić tematu jeszcze.