takie coś będzie git?

http://www.sarnau.info/atari:atari_ste_ … on_the_ste
http://atari-ste.anvil-soft.com/html/devdocu2.htm
http://www.atari-forum.com/wiki/index.p … _/_Paradox

No ale w czym problem, przecież to jest dość proste ?

jurex, możesz go udostępnić?

Ha, pobawiłem się tym hardware scroll'em i przyznaję że jest cholernie prosty i efektowny. Ech, szkoda że w "tamtych" czasach góra 5 gier go wykorzystywała. Można było przeca robić gry które by wykrywały czy jest STE i jeśli tak to scrollowały płynnnie, a pozostałym STx'om zostałby dziadowski scroll procesorem :D

sqward, no racja. Taki Cannon Fodder woła o pomstę do nieba :(

Jeśli faktycznie świat gamedev wyznaje zasadę "get the shit done FAST" to badziewne konwersje nie są winą koderów tylko kierowników projektów i manadżerii która zmusza do takiej pośpiechu. Wtedy nie ma czasu na dopieszczanie, tylko robi się po najmniejszej linii oporu, ale faktycznie, najlepiej zwalić wszystko na koderów :P

jury: to zależy. ja w pracy widzę, że jest grupa koderów (manageró), którzy odwalają wszystko po najmniejszej linii oporu. I nawet nie mówie tutaj o stronie wizualnej projektów, tylko o np. nie hackowanie wszystkiego w taki sposób, że następny projekt trezeba pisać od zera. Ciekawe jest to, że to właśnie ludzie, którzy pisali gry na amigę i ST. Poprostu wtedy się tak pisało.

Z tym to nawet nie będę polemizował, bo to wszystko oczywiście zależy od poszczególnego egzemplarza kodera :)
Więc są i tacy ( niestety chyba nie w mniejszości ) którzy zawsze idą po najmniejszej linii oporu niezależnie od wszystkiego. Natomiast w momencie tworzenia projektu metodą "get the shit done FAST" wszyscy w zespole muszą zapierniczać jak odrzutowce przez co zazwyczaj projekt traci na wartości. A "get the shit done FAST" zawsze i wyłącznie narzuca manadżeria a nie ostatnie pionki które projekt wykonują, czyli w tym przypadku koderzy.

Bawię się tym scrollem dalej i coś mi się wykrzacza po wpisaniu mojego vbl'a pod $70. Ratunku, nie wiem o co mu chodzi, bo już zgłupłem.
Okroiłem wszystko tylko do wyświetlenia PI1 i wrzucenia mojej procedury vbl, która komplenie nic nie robi i nadal lipa.
Wstrętny kod:

           jsr    init

    movem.l    picture1+2,d0-d7
    movem.l    d0-d7,$ff8240

    move.w    #2,-(a7)
    trap    #14
    addq.l    #2,a7

    move.l    d0,a0
    move.l    #picture1+34,a1
    move.l    #picture2+34,a2

    move.l    #199,d0
l1
    move.l    #39,d1
l2    move.l    (a1)+,(a0)+
    dbf    d1,l2
    move.l    #39,d2
l3    move.l    (a2)+,(a0)+
    dbf    d2,l3
    dbf    d0,l1

    move.w    #7,-(a7)
    trap    #1
    addq.l    #2,a7

    move.l    #vbl,$70

    move.w    #7,-(a7)
    trap    #1
    addq.l    #2,a7

    move.b    #0,$ff820f

    move.w    #$777,$ff8240

    jsr    restore

    clr.l    -(a7)
    trap    #1

vbl    
    move.l    d0,d1
    rte

    include    init.s

    section    data

picture1    incbin    demon9.pi1
picture2    incbin    demon9.pi1

adr_ekr    ds.l    1

init.s jest rodem prosto z tutoriala perihelion'a

adamk: to zależy co ma w init i restore ;)

OK, za mało danych dałem chyba :)
W init i restore mam oczywiscie zapamietanie i odzyskanie oryginalnego vbl'a.
Zawartość zaprzykładowego przezemnie vbl'a nie ma znaczenia. Tak dla jaj :) aby coś było wpisałem to move.l d0,d1 :)
To niech moja vbl'ka wygląda tak:
vbl
rte
A problem mam taki że jak debuguję to coś to już w momencie move.l #vbl,$70 emulator się zawiesza.

A co do tego:

Tak, wiem. Ale robię scroll'a poziomego i za chwilę pojawi się jeszcze 8 incbin'ow i kazdy będzie inny. To tylko przyklad. Skupmy się na tym ze się zawiesza w momencie move.l #vbl,$70 :)

jury: to spróbuj wwalić tam jakiegoś nop'a, wrzucić słowo even przed VBL i odpal zamiast monsta np. adebug. monst daje ciała czasami.