Nie no, wyypas. Mam nadzieje, ze uzyjesz swoich doswiadczen piszac jakas kiler gre :)

>Moglbys napisac w jaki sposob wydajnie animujesz duszki? Tzn domyslam sie ze za pomoca buforow, ale 10kB? Kazda klatka animacji to osobny bufor?

Metoda jest prosta, wręcz banalna ale pamięciożerna i niesie pewne ograniczenia.
Postaram się pokrótce opisać.

Komodorowcy mają banki na sprajty. Trzymają w pamięci w odpowiedni sposób w blokach co 64 bajty.
Potem tylko wskazują który sprajt ma skąd pobierać dane z tych bloków.
Pomyślałem a jakby coś takiego zrobić u nas.
I wyszło nawet nieźle. Dla obiektów poruszających się tylko w osi X jest to super rozwiązanie.
A więc:

Bank duszków na Atari (to wiadomo)
0-2ff puste
300-3ff pociski
400-7ff gracze 1-4

tworzymy 8 takich banków
zabiera nam to 16kb pamieci
ale jeśli nie używamy pocisków to adresy 0-3ff mamy wolne (na np fonty czy dane jakieś)
czyli faktycznie zużywamy 8 kb rozrzucone w obszarze 16kb (niestety adresy banków muszą być na granicy 2 kb więc nie da się tego ścieśnić)
Dla uproszczenia przykładu powiedzmy że mamy sprajta o szerokości 16 cykli koloru czyli używamy wszystkich czterech graczy.
Normalnie byśmy przepisali do adresu $400+pozycja Y,$500+pozycjaY,etc
ale możemy zrobić to dla każdego z ośmiu zarezerwowanych na to banków wpisując do każdego gotową fazę animacji
Bank0 - 1faza prawo
Bank1 -2faza prawo
Bank2 -3 faza prawo
Bank3 -4faza prawo
Bank4 -1faza lewo
Bank5 -2faza lewo
Bank6 -3faza lewo
Bank7 -4faza lewo

i możemy prosto animować zmieniając tylko $d407
lda #> tutaj adres banku
sta $d407

po prostu animujemy sprajta
ale co z następnymi?
robimy to samo kopiujemy je do banków w odpowiednie adresy odpowiadajace pozycji Y
i na DLI zmieniamy $d407 na numer fazy animacji jaką potrzebujemy
Ja mam zrobioną tablicę adresów faz, i na niej operuję na VB ustalając jaka faza animacji będzie wyświetlana.
A na DLI pobieram z niej bezpośrednio i przepisuję bank, czyli

DLI1
...
...
 lda TabSprite
 sta $d407
...
...
 rti

DLI2
...
...
 lda TabSprite+1
 sta $d407
...
...
rti

Ograniczenia:
Jeśli to jest jeden sprajt w lini czyli np 16 pixelowy złożony z czterech graczy to nie ma ograniczeń.
Jeśli są dwa to wtedy pierwszym (grac 0+1) można swobodnie animować ale drugi będzie miał ograniczenia.
Bo np. jeśli pierwszy bedzie szedł w lewo a drugi będzie chciał iść w prawo to nie da rady. :) Fazy się nie zgrają.
Trzeba wtedy do drugiego sprajta (gracz2+3) wrzucić animację która będzie niezależna od kierunku.
Mogą to być monety, gwiazdki (jak w Crowland), latające kule, itp
Można też użyć pocisków ale znika nam extra 2kb. Za to można zrobić z nich w połączeniu z graczem (0 i 1) sprajty jak na komodzie 12 pixelowe.

Prace nad Cybem w toku.
Ale jestem na skraju załamania nerwowego. :)
Zacząłem w poniedziałek, myślę sobie do środy skończę. hehe optymista
Zaplanowałem sobie "specjalny" tryb graficzny.
No i zaczęło się konwersje, zamiany bitów, rozszerzanie ekranu, znowu konwertowanie, cyklowanie, znowu zmienianie :)
Skończyło się że teraz u mnie $200=$FFFA ;) te jedenaście cykli było jak zbawienie.
Bo przy szerokim ekranie to się nic nie da przepisać na DLI a co dopiero 6 rejestrów. O WSYNC to można pomarzyć.
Preview jest w dużej mierze skończone. Zostało tylko sceny narysować.
Dopóki to były pojedyncze obiekty żeby tylko zobaczyć jak to się prezentuje to było wszystko ok.
Ale zrobić klika, co ja mówię.... jedną scenę przy dwóch generatorach to ja już wymiękłem.
EnvisionPC się to tego nie nadaje, do tego robi różne dziwne numery. Jak przed chwilą zgubił mi drugi generator znaków.
Na przyszłość i tak trzeba będzie coś takiego sobie napisać ale na tą chwilę zostało mi tylko narysować sceny więc potrzebuję czegoś gotowego.
Wszystko chyba będzie lepsze od tego czym dysponuję teraz.
Może słyszeliście o jakimś edytorze który pozwala na tworzenie obrazu w tym a'la Avalon trybie (JGP 2x2).
Będę wdzięczny za wskazanie, a ja tym czasem w trosce o swoje zdrowie dzisiaj zrobię sobie już wolne.

Druga część z c64
Kod całkowicie mój.
W trybie tekstowym + 26 DLI
Jest to raczej próba generalna tego trybu, który wymyśliłem sobie na potrzeby innej gry.
Oraz chęć sprawdzenia jak by cyb mógł  wyglądać na JIL gdyby ktoś miał dużo samozaparcia i się do tego przyłożył.
No a dla mnie jest to idealna okazja do przypomnienia sobie kodowania.
Tak jak w przypadku Flimbo będzie miało to więcej wspólnego z demem niż z grą.
Jeszcze nie czuje się na siłach pociągnąć taki projekt do końca.

Nie no, miodzio :) Keep working!
A paleta atari wcale nie jest do bani. Jest tyle kolorow, ze czasami z nadmiaru bogactwa ciezko cos dobrac. W przeciwienstwie do c64 - 16 kolorow i nie ma wyjscia. Trzeba packac tym co jest :)

Na tą chwilę jest wolne prawie połowa generatorów znaków.
Ekran jest w trybie podobnym do 4+ są używane 2 zestawy.
Jak wygląda ten tryb w bbc?

Są pewne ograniczenia które mnie nie puszczają.
No niestety jak się nie da czegoś zrobić tak samo to trzeba to zrobić inaczej (lepiej albo gorzej)
Wybuchanie przeciwników na pół ekranu nie wchodzi w grę. Atrybuty mi się posypią jak domino. :)
Dla tego trybu przewiduje zrobić "dynamiczne" generatory.
Z zasady góra są 2 większe obiekty naraz na ekranie.
Generator dzielę na elementy stałe (podłoża, ściany itp.) powiedzmy pierwsze 32 znaki (razy 2)
I elementy zmienne (potwory, działa, itp) które alokuje w generatorze przy zmianie sceny - 48 znaków (razy 2)
Dane sceny nie zawierają wtedy tych obiektów przez co są łatwiejsze w kompresji. Potem tylko narzucam taki obiekt na ekran.
No i na końcu na obiekty ruchome - 48 znaków (razy 2) - myślę że powinno wystarczyć.
No ale to są tylko testy graficzne do gry daleka droga.
Cybernoid bardzo mi pasował do tych testów i tylko dla tego się za niego zabrałem.

ps. Czekam na jedynkę, bo głupio by było żeby się dwójka pierwsza pokazała :)

>mozesz dlugo czekac ;-)

Ja mam sporo czasu :)

A teraz parę szczegółów.
4 podstawowe kolory dla ekranu są stałe. (Czarny, biały, brązowy, jasno brązowy)
Nie są zmieniane na DLI.
Za to co linie zmieniam to:

DLIexample
    sta dl_a
    sta dl_a    ;powtórzone bo potrzebowałem przesunąć o 3 cykle :)
    lda #$00 
    sta $d012
    lda #$00
    sta $d013
    lda #$00
    sta $d014
    lda #$00 
    sta $d409
    lda #$00
    sta $d019
    lda #$00
    sta $d015
    lda #<NextDLI
    sta $FFFA
    lda #>NextDLI
    sta $FFFB
    lda dl_a
    rti

Kolejność przepisywania rejestrów musi być tak jak jest.
Ekran jest 48 znakowy, przy aktywnych wszystkich DMA ciężko zdążyć przed BadLinem.
Wbiłem się z DLI prosto w $FFFA. Na początku odpalam procedurę synchronizującą DLI z VBLKI.
Krótko mówiąc VBLKI jest odpalane jakby to było DLI ale na wszelki wypadek potem jest sprawdzany bit NMI.
I w razie jakby się wywaliło znowu odpali procedurę synchronizacji. (ale mi się to nie zdarzyło, jeszcze)

"Atrybuty" są zrobione z PM poczwórnej szerokości oraz znaku inversu.
Przed przerysowaniem ekranu kolory PM z tablicy 80 bajtowej przepisywane są prosto w DLI
Potem z tablicy 20 bajtowej przepisywane są kolory inversu prosto w DLI
Potem z tablicy 100 bajtowej generowane są dane w bankach PM (kwadraciki o wielkości znaku 4x8- moze byc 4x1 ale tablica będzie miała 800 bajtów)

Poniżej parę obrazków poglądowych. Na pierwszych dwóch nie widać zmiany inversu bo ekran jest pusty :)

Ekstra :) Szkoda, że na forum nie ma takiego buttona z literą "F" i podpisem "Lubię to" ;)

@Eagle. EnvisionPC Reborn (w porównaniu do bazowego programu - EnvisionPC) jest mocnym rozszerzeniem. Dodaję na zawołanie nowe funkcje. Poprawiam stare. Jeśli coś nie działa, nie narzekaj, tylko pisz, że nie działa, poprawimy :)

Jest na to przeznaczony wątek na atarionline.pl

Tutaj też wrzucę bo nie wszyscy zaglądają na AAge
W nocy mnie naszło żeby sprawdzić Emkay mode :) (antic 13+digi)
Z drugiej strony zawsze zastanawiało mnie jakby to było odpalać sample na DLI.
Do tego użyłem metody z cyba.
Jest jedno DLI wpięte w $FFFA uruchamiane 60 razy (3kHz)
VBLK nie używam.
Konwersja jakiegoś sampla z netu przy pomocy goldwave i zapis do 8bit unsigned potem przerobione na 4bit przez zwykłe przesunięcie.
Charczy strasznie, ale chyba w dużej mierze wina konwersji. Nie ma to jak ze samplować na JIL.
Program pisany z "marszu" więc o jakiejkolwiek optymalizacji kodu można zapomnieć.
Ale ogólnie daje rade ten tryb. Pure 50fps :)