spowolnienia nadal będą istnieć, ogólnie jednak działa szybciej niż v1.1

okazuje się że procka na stronie zerowej nie odpowiada całkowicie za ruchome obiekty w grze, od E_2264 zaczyna się pętla która realizuje przepisywanie obiektów na ekran, prawdopodobnie z uwzględnieniem przesłaniania przez obiekty (bohater zwalnia kiedy nachodzi na jakieś obiekty), pętla przepisująca zaczyna sie od E_22bd i jest trudniejsza do przyspieszenia, tak na oko 2 cykle na bajt może się uda przyspieszyć

E_22bf, E_22c2 tylko starszy bajt jest modyfikowany, młodszy zawsze =0


E_22bd    ldx #$00
E_22bf    lda $C000,x
E_22c2    sta $ff00,x
    inx
E_22c6    cpx #$00
    bne E_22bf

    dec E_22c2+2

    inc E_22bf+2
    bmi E_22d5
    dey
    bpl E_22bd

E_22d5    dec E_0047
    bpl E_2264
    rts

poprawie kod wzorując się na Twoich poprawkach Eru

eee działa, tylko trzeba wypełnić do pełnej strony tak aby etykieta E_0100 zaczynała sie od adresu $0100

rejestr X ustawiany jest tak, że koniec bufora E_0400, E_0500 przypada na ich ostatni bajt (E_0400+$ff, E_0500+$ff)

1,430

(8 odpowiedzi, napisanych Programowanie - 8 bit)

a nie jest to MOD z 4bitowymi samplami

http://madteam.atari8.info/gry/knightlore.7z

dzięki Magnus, Twoja poprawka jak najbardziej działa, dodatkowo zamieniłem JSR PUTSHAPE na JMP PUTSHAPE i RTS na JMP PUTSHAPE_RETURN

można wprowadzić jakiś limit ramek, jeśli liczba ramek nie przekroczyła 3 to czekaj do 3 ramek, w przeciwnym wypadku leć dalej i nie oglądaj się za siebie

ok, zmiany zaproponowane przez Magnusa zaaplikowane, fragmenty kodu które modyfikowały te INX-y / NOP-y usunięte

ogólnie program inicjujący PUT SHAPE zaczyna się od E_1AA2

plik do ściągnięcia z w/w linka

p.s.
Laoo jak znajdzie troche czasu poprawi Atari++ zgodnie z sugestią Eru dotyczącą profilowania kodu 6502, będzie można testować nie męcząc Eru :)

http://madteam.atari8.info/gry/knightlore.7z

nowsza wersja pod w/w linkiem, jeszcze więcej pętli rozpisałem, m.in. pętle czyszczącą ducha programowego (CLEAR_SHAPE), pętle lustra dla bitmapy statycznej FastMirror, dodałem tablice decyzji dla detekcji kolizji kierunku DirectCollision

wyłączyłem PMG aby zyskać parę cykli na linię więcej :)

dzieki Eru, teraz widać gdzie trzeba drążyć

w KL wykorzystywane są bitmapy szerokości 2,3,4 bajtów, wykorzystałem tą właściwość i rozpisałem kopiowanie i przesuwanie bitów dla tych szerokości

dodatkowo udało się zintegrować tablice przesunięć bitów z tablicą odbicia lustrzanego

dla testowej bitmapy 32x38 pixli wersja standardowa zajmowała ok. 40000 cykli, aktualna ok. 12000 (napisałem taki mini emulator 6502 aby wykonał oba testowe programy i zliczył cykle)

i co z tego skoro po tych poprawkach szybkość gry nadal nie jest w 100% zadowalająca, coś tam jeszcze pożera zachłannie cykle

plik wraz ze źródłami można pociągnąć stąd http://madteam.atari8.info/gry/knightlore.7z

gre można uruchomić tylko przez XRLoader, wersja dla emula (min 128 dodatkowej pamięci) w katalogu ..\asm\xrload.obx

na potrzeby testów gra wykorzystuje pamięć dodatkową, normalnie zajmuje obszar $0000..$BFFF, muzyki i efektów dźwiękowych brak, zostały wycięte dla maksymalnej szybkości działania (program DLI też jest krótszy i szybszy pare cykli)

tak Windows

nawet nie wiem jak się zabrać za profilowanie kodu, mam dokonać nowej kompilacji Atari800 ? czym ? Visual C ?

nie wykluczone że ktoś jeszcze może mieć pomysł na przyspieszenie w/w fragmentu gry, dlatego jestem ciekaw pomysłów

oto fragment kodu KL który prosi się o przyspieszenie i rezygnacje z przesuwania bitów, jest on w dużej mierze odpowiedzialny za spowolnienia działania gry, realizuje przepisanie danych z bitmapą kształtu i maski do buforów, następnie przesuwa N-krotnie bity w tychże buforach

ogólnie KL na podstawie rodzaju obiektu wykonuje obsługę bitmapy statycznej lub bitmapy ducha (ducha jak bohater, przeszkadzajki, przedmioty do zebrania)

bitmapy z kształtem jak i maską zapisane są standardowo bo liniowo, np. dla bitmapy o szerokości 3 bajtów mamy

012
345
678
9 ..... itd.


E_1B92  program realizujący obsługę ruchomych obiektów (bohater, przeszkadzajki, przedmioty), który prosi się o dopalacze :)

E_0378    przechowuje aktualny kierunek, przyjmuje wartości 0 lub 7, 0 dla kierunku w górę, 7 dla kierunku w dół, na podstawie kierunku podejmowana jest decyzja czy dokonywać lustrzanego odbicia bitmapy czy nie

E_0400    bufor dla bitmapy z kształtem (256 bajtów)
E_0500    bufor dla bitmapy z maską kształtu (dla operacji AND) (256 bajtów)

E_000E+1 zmienna przechowująca wysokość bitmapy
E_001B+1 zmienna przechowująca wysokość bitmapy

E_0046  zmienna przechowująca szerokość bitmapy (przepisywana do zmiennych E_004E i E_004F)

E_004D    zmienna przechowująca wartość ofsetu względem początku strony pamięci, dane w buforach E_0400 i E_0500 umieszczane są tak aby kończyły się na ostatnim bajcie strony, dzięki temu nie trzeba dokonywać dodatkowych testów wystarczy INY\ BNE LOOP

E_0050    zmienna w której przechowywana jest liczba bitów (pixli) do przesunięcie (przesuwa w prawo przez ROR)

mirror    tablica pod adresem $5300 (256 bajtów) z predefiniowanymi wartościami, przy jej pomocy dokonywane jest lustrzane odbicie bitmapy


E_1AA2    ldx E_0047
    lda temp1+$d8,x
    beq E_1AA1
    cpx E_0070
    bcs E_1AB2
    lda E_0670,x
    bmi E_1A9E
E_1AB2    lda E_03A0,x
    sta E_0045

    lda E_0378,x
    pha
    lda E_0350,x
    clc
    adc E_0300,x
    sec
    sbc #$20
    pha
    and #$F8
    sta E_0012+1
    sta E_005A
    pla
    and #$07
    sta E_0048
    beq E_1AD5
    inc E_0045
E_1AD5    lda E_0045
    asl @
    asl @
    asl @
    adc E_005A
    sta E_005B
    ldx #$00
    ldy #{inx}
    pla
    beq E_1AEA
    ldx E_0045
    dex

    ldy #{dex}
E_1AEA    sty E_1B04

    lda #{nop}
    sta E_0020
    sta E_0021
    sta E_0022

    lda E_0012+1
    lsr @
    lsr @
    lsr @
    tay

E_1AFB    mva    E_0400,y    E_0052,x
    mva    #{inx}        E_001E,x
E_1B04    inx
    iny
    dec E_0045
    bne E_1AFB

    ldx E_0047
    lda E_0500,x
    cmp #$13
    bcc E_1B17
    clc
    adc E_0670,x

E_1B17    tay
    lda E_0300,x
    lsr @
    sta E_001B+1

    lda #$90
    sec
    sbc E_0350,x
    lsr @
    clc
    adc E_001B+1
    adc E_0328,x
    sec
    sbc E_2E66,y
    pha
    lsr @
    lsr @
    lsr @
    sta E_001B+1

    lda #$6A
    clc
    adc E_001B+1
    bmi E_1B8B
    sta E_0008+1
    pla
    and #$07
    eor #$07
    sta E_0006+1

    lda E_03A0,x        ; szerokość bitmapy
    sta E_0046

    lda bmpHeights,y
    sta E_000E+1
    sta E_001B+1
    tya
    asl @
    tay

    mva    bmpAddress,y    E_0049
    clc
    adc <msk0-bmp0        ; młodszy bajt ofsetu do maski bitmapy
    sta E_004B

    mva    bmpAddress+1,y    E_0049+1
    adc >msk0-bmp0        ; starszy bajt ofsetu do maski bitmapy
    sta E_004B+1

    ldy E_0046        ; 0-szerokość_bitmapy*wysokość_bitmapy
    lda #$00        ; obliczamy ofset aby umieścić dane pod koniec strony buforów E_0400, E_0500
E_1B6B    sec            ; dzięki temu będzie można osiągnąć koniec kopiowania po INY\BNE (bez dodatkowych testów)
    sbc E_000E+1
    dey
    bne E_1B6B

    sta E_004D        ; obliczona wartość ofsetu

    lda E_0048
    bne E_1B92        ; skok do obsługi bitmap z duchami

    ldx E_004D        ; przepisujemy statyczną bitmapę
    ldy #$00
E_1B7B    mva    (E_0049),y    E_0400,x
    mva    (E_004B),y    E_0500,x
    iny
    inx
    bne E_1B7B
    beq bmpMirror        ; w tym wypadku zachowa się jak JMP

E_1B8B    pla
E_1B8C    lda #$FF
    sta E_0638,x
    rts


* ---    SPRITE ENGINE

E_1B92    lda E_0378,x        ; program dla ruchomych elementów gry (bohatera, przeszkadzajek i przedmiotów)
    eor E_0048
    cmp E_0048
    beq E_1B9E

    clc
    adc #$01
E_1B9E    sta E_0050        ; przesunięcie pozycji poziomej z duchem

    lda E_0046        ; szerokość bitmapy
    sta E_004E
    sta E_004F

    lda E_004D
    sec
    sbc E_000E+1
    sta E_004D
    tax
                ; skopiowanie bitmapy do bufora E_0400 i maski do bufora E_0500
    ldy #$00
E_1BB0    mva    (E_0049),y    E_0400,x
    mva    (E_004B),y    E_0500,x
    inx
    iny
    cpy E_004F
    bne E_1BB0

    mva    #$00    E_0400,x    ; wstawiamy pustą wartość $00 do bufora z bitmapą kształtu
    mva    #$FF    E_0500,x    ; wstawiamy pusta wartość $FF do bufora z bitmapą maski
    inx                ; puste wartości są potrzebne dla operacji przesuwania bitów

    lda E_004F
    clc
    adc E_004E
    sta E_004F

    dec E_001B+1
    bne E_1BB0


    ldy E_0050        ; przesunięcie pixli bitmapy kształtu i bitmapy maski

E_1BD8    ldx E_004D        ; liczba powtórzeń pętli w zmiennej E_0050
    clc
E_1BDB    ror E_0400,x    ; kształt
    inx
    bne E_1BDB

    ldx E_004D
    sec
E_1BE4    ror E_0500,x    ; maska
    inx
    bne E_1BE4
    dey
    bne E_1BD8

    inc E_0046


bmpMirror
    ldx E_0047

    ldy #+8
    lda E_0378,x
    beq E_1C1C

    ldy E_004D            ; dokonuje lustrzanego odbicia bitmapy z duchem
E_1BFA    ldx    E_0400,y
    mva    mirror,x    E_0400,y

    ldx    E_0500,y
    mva    mirror,x    E_0500,y
    iny
    bne E_1BFA

    ldx E_0046
    dex
    txa
    asl @
    asl @
    asl @
    adc E_0012+1
    sta E_0012+1

    ldy #-8
E_1C1C    sty E_0037+1

    mva    E_0012+1    E_001B+1
    mva    #$52        E_0000+1
    mva    E_004D        E_0004+1

    jsr    PUTShape

    ldx E_0047
    cpx E_0070
    bcs E_1C47

    mva    E_0008+1    E_0638,x
    mva    E_0012+2    E_0654,x
    mva    E_005A        E_0600,x
    mva    E_005B        E_061C,x

E_1C47    rts

jakieś propozycje ?

pamięci wolnej pod ROM-em i w RAM-ie trochę jest, tak że można rozpisywać i tablicować do woli

1,440

(26 odpowiedzi, napisanych Scena - 8bit)

a ja poproszę o demo gry Crysis

1,441

(25 odpowiedzi, napisanych Sprzęt - 8bit)

Pin napisał/a:

bez urazy - lecz mam nadzieję, iż znikoma ilość koderów "wpadnie" na tak dobry pomysł by ładować kod od $0000 :)

Knight Lore zajmuje m.in. obszar $0000..$2000 i pewnie inne konwersje XXL-a gier z BBC Micro także

XXL trochę się nagimnastykował aby to pociąć na kawałki, upchac do pamięci i potem poprzenosić w odpowiednie miejsca, dla kodera wygodniej jest gdy ma wgląd w kod jako ciągły obszar, kiedy program jest już skończony można go przystosować do innej mniej czytelnej formy

widocznie na innych platformach sprzętowych ładowanie od $0000 to nie problem :)

1,442

(25 odpowiedzi, napisanych Sprzęt - 8bit)

xxl napisał/a:

kart to jest swietny nosnik, loadera dla takiej gry mozna sobie napisac w doslownie kilkunastu bajtach. pierwsze co robimy to odlaczamy OS Atari :-) i cala pamiec dla nas, mozemy ladowac program od adresu $0000 a z dyskietki? pewnie $2000.

XXL mam taki loader który wykorzystuje dodatkowe banki pamięci aby załadować plik do pamięci podstawowej $0000..$CFFF, $d800..$ffff  -$100 bajtów na loader

1,443

(9 odpowiedzi, napisanych Fabryka - 8bit)

Knight Lore działa na znakach, nie jest to tryb bitmapy, stąd większa komplikacja, dla bitmapy nie trzeba się cackać z każdym znakiem, obliczać jego adres itp. można walić bajt po bajcie

ogólnie gdyby rozpisać pętle modyfikujące znaki wówczas byłoby to nieznacznie wolniejsze od bitmapy, jednak nie ma na to pamięci w podstawowym ramie

1,444

(25 odpowiedzi, napisanych Sprzęt - 8bit)

kod gry pisany pod karta jest tylko do odczytu, program nie może modyfikować sam siebie, jest ściślejszy podział na obszar kodu i danych

1,445

(81 odpowiedzi, napisanych Sprzęt - 8bit)

seban napisał/a:

Teraz sobie przypomniałem... dla turbo 2000F był programik który umożliwiał wczytywanie danych ze spectrum. i Faktycznie na giełdzie na Saskiej prosiłem spectrum-owców aby mi nagrywali mi fajne obrazki z gier ze spectrum na taśmę... w domu czytałem to przy pomocy turbo 2000F i oglądałem te obrazki na ATARI :)

rzeczywiście był taki programik, obrazki pozyskane w ten sposób zostały umieszczone w pierwszej część Happy Demo

1,446

(81 odpowiedzi, napisanych Sprzęt - 8bit)

dzięki za wyjaśnienie, idea w sumie prosta tylko podejście do tematu różne, ilość oprogramowania i jakość loaderów rzeczywiście wpływała na popularność danego roziwązania, ja przerzuciłem się z T6000 na T2000F właśnie ze względu na lepszy soft, więcej tytułów można było przenieść na turbo

a wiadomo kto pierwszy zapoczątkował sprzętowe modyfikacje magnetów na turbo, czy dużo więcej osób wpadło na ten sam pomysł w tym samym czasie

1,447

(81 odpowiedzi, napisanych Sprzęt - 8bit)

a tak z ciekawości mógłby ktoś nieuświadomionemu elektronicznie napisać na czym polega Turbo do magnetu Atari XE/XL

pozatym ciekawe dlaczego Atari oferowało tylko normal zamiast turbo jak na C64, czy Turbo do magnetu XE/XL sporo podrażało koszty sprzętu, pomijam marże elektroników którzy montowali systemy turbo

kiedyś specjalnie pojechałem do Warszawy aby zamontować T2000F, poprzednio miałem właśnie Turbo6000, goście z W-wy nie omieszkali skrytykować tego rozwiązania, czym się różniły od strony elektronicznej systemy turbo, z doświadczenia wiem że na T6000 nie udało przenieść się wszystkich rodzaji plików, wersje plikową carta T2000F można znaleźć na http://madteam.atari8.info (zrzut pamięci)

w sumie istniała swego rodzaju wojna zdaje się pomiędzy T2000 i Blizzard, który w końcu okazał się lepszy i dlaczego ?

1,448

(244 odpowiedzi, napisanych Fabryka - 8bit)

no to jeszcze tutaj można dowiedzieć się jak zapisane są informacje o komnatach w Knight Lore, Alien8, Pentagram, można pociągnąć edytor do silnika Filmation na którym działają te gry, można poczytać troche o historii tych gier jak i zmian jakie zaszły w ich kodzie

http://retrospec.sgn.net/users/nwalker/filmation/

p.s.
do edytora Filmation dołączone są wyripowane dane na temat komnat do Knight Lore i Alien8

1,449

(244 odpowiedzi, napisanych Fabryka - 8bit)

stąd można pociągnąć zdisasemblowany w jakimś stopniu Knight  Lore, Alien8 dla ZX Spectrum (dostępne są bitmapy z wyripowaną grafiką dla tych i jeszcze innych gier)

http://www.icemark.com/downloads/index.html

1,450

(244 odpowiedzi, napisanych Fabryka - 8bit)

tak zazdroszcze że na inne platformy można zrobić grywalną wersje tej gry a na Atari 8-bit nie, zamiast dopracować ten tytuł to XXL zaczyna następny, może kiedyś ktoś tą grę przeportował już na Atari 8-bit tyle że nikt nie odważył sie tego wydać, czyżby Atari było za wolne na tą grę

nie ujmuje XXL-owi zasług ale jak za coś się bierze to liczę że zrobi to do końca tak aby przypominało oryginał nie tylko od strony graficznej ale przede wszystkich od strony grywalności