1,401

(59 odpowiedzi, napisanych Scena - 8bit)

ogólnie rzecz biorąc jeśli na najbliższym party będzie ktoś wystawiał jakieś demo to powinien rozpoznać teren i upewnić się że nie będzie konkurował ze "śmieszną konkurencją" bo może nie mieć szans, wtedy sugeruje przenieść prezentacje dema na następne party

p.s.
dawno temu w Elblągu (Orneta-Elbląg) pamiętam jak jakiś komodorowiec stwierdził że "p*.* to" i dema nie wystawia bo kasa z nagrody zbyt niska w stosunku do nakładu pracy jaki włożył w produkcje, chciałbym zobaczyć mine gościa gdyby kasa była wystarczająca a przegrałby z taką produkcja w stylu JZB, pewnie miałby zawał

p.s. #2
jeśli marzysz o #1 miejscu upewnij się że w danej konkurencji prac nie wystawia Eru albo Fox

1,402

(74 odpowiedzi, napisanych Fabryka - 8bit)

w najnowszym konkursie Sikora będzie nagroda w postaci VBXE :) i dzięki temu wszyscy będą mieli VBXE

1,403

(74 odpowiedzi, napisanych Fabryka - 8bit)

spójrzcie na takie C64 DTV, zamiast iść małymi kroczkami można zrobić 1 porządny krok naprzód

1,404

(74 odpowiedzi, napisanych Fabryka - 8bit)

widzisz ikplus jak to jest gdy się pytasz o opinie, należy ich postawić przed faktem dokonanym

1,405

(4 odpowiedzi, napisanych Programowanie - 8 bit)

przecież jest dokumentacja do ANTIC-a, tam jest to rozrysowane, a u Ciebie brakuje jeszcze PMG

1,406

(26 odpowiedzi, napisanych Scena - 8bit)

Fenek, masz doświadczenie w pisaniu dem na C64, miałbym pytanie z tym związane, ile czasu zajmuje średnio napisanie dema na C64, ile czasu zajmuje dopracowanie designu do takiego dema, czy jest na początku jakiś projekt całości czy wszystko wychodzi "w praniu", msx powstaje przed stworzeniem dema, w trakcie czy po ?

1,407

(709 odpowiedzi, napisanych Fabryka - 8bit)

wow, ktoś tu ma refleks szachisty ;)

1,408

(158 odpowiedzi, napisanych Bałagan)

gdy po raz pierwszy zobaczyłem któryś tam odcinek pierwszej serii emitowany w TVP BSG niespecjalnie się spodobał bo nierozumiałem o co w tym chodzi, dopiero gdy zacząłem oglądać od początku wtedy rzeczywiście wciągnął :) zostały jeszcze do obejrzenia dwa ostatnie odcinki 3 sezonu Crossroads Part 1..2, no i Razor

ostatni 4-y sezon ma liczyć 13 odcinków, czyli będzie krótki ale pewnie treściwy pod względem akcji, 3 sezon zwolnił tempo, dużo wypełniaczy, pobocznych wątków

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,413

(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,423

(26 odpowiedzi, napisanych Scena - 8bit)

a ja poproszę o demo gry Crysis

1,424

(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,425

(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