26

nie co znak tylko co 2 pixele, obroty sa co znak. chodzilo o przyklad - masz 9 ruchomych obiekow, popierdzielaja sobie zrowo, niech bedzie 2 razy wolniej po 1 pixelku... da sie?

http://atari.pl/hsc/ad.php?i=1.

27

Zybex jest na znakach, 50 fps. choc 2x2 pixle, ale ladny i szybki engine (tlo + sprity).

28

vega napisał/a:

mnie interesuje tylko tryb znakowy, ze względu na 5-ty kolor.

Jeśli interesuje Cię 5-ty kolor i dlatego uparłeś się na tryb znakowy (z którym będziesz miał raczej same problemy), to spieszę oznajmić, że są inne metody uzyskania 5-go koloru. Np. możesz podłożyć sprzętowe sprite-y pod cały ekran, ustawiając je "pod" zwykłą grafiką. Zdaje się, że gra "Robbo" tak robi, używając w dodatku trybu znakowego, w związku z czym jest tam 6 kolorów (ale sprajtów programowych nie ma).

https://www.youtube.com/watch?v=jofNR_WkoCE

29 Ostatnio edytowany przez tebe (2006-08-13 16:21:58)

w Nibbly zrealizowane zostało to podobnie, ekran o szerokosci 40 bajtow podbarwiany jest dwoma duchami o maksymalnej szerokosci, dwoma bo rozmnażane sa one w linii, dodatkowo co 8 linii zmieniany jest ich kolor, przez co Nibbly jest bardzo kolorowe jak na tryb znakowy, pozatym do dyspozycji zostaja jeszcze 2 duchy i 4 pociski

podobnie realizowany jest panel na dole ekranu, z tym ze sa tam uzyte duchy 4 kolorowe ktore sa rozmnazane w linii

p.s.
nie wykluczam ze ekran o szerokosci 32 bajtow udaloby sie podbarwic tylko 1 duchem

p.s.
zaleta trybow tekstowych jest mniejsze zuzycie pamieci

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

30

tez sie dolacze ;-) flowers mania rowniez podbarwia kwiatki plajerami dlatego jest tam 6 klorow, gdyby pov nie uparl sie na kwiatka szerokosci 4 znakow byloby 8 kolorow ;-)

http://atari.pl/hsc/ad.php?i=1.

31

na chwile obecna moj silnik dla spritow na znakach potrzebuje 12..17 linii obrazu (wartosc z $D40B) na przepisanie i modyfikacje 16 znakow z 4 zestawow, predkosc uzalezniona od linii w ktorej startuje procka

a ile zajmuje :), dwie procedury dla dwóch buforów inicjalizujace zmienne i bufory to 2 banki pamieci

8 klatek animacji ducha z przesunieciem o 1 pixel w prawo to 4 banki pamieci

ogolnie wszystko rozpisane i rozpetlone

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

32 Ostatnio edytowany przez vega (2006-08-14 01:07:50)

Fox napisał/a:

....Np. możesz podłożyć sprzętowe sprite-y pod cały ekran, ustawiając je "pod" zwykłą grafiką. ...

no wiem o tym, ale wtedy tracę te sprzętowe sprajty...a jak widać w moim załączonym przykładzie one są nakładane na sprity programowe, żeby dodatkowy kolor uzyskać (a to aż 4 dodatkowe kolory).

Tebe napisał/a:

na chwile obecna moj silnik dla spritow na znakach potrzebuje 12..17 linii obrazu (wartosc z $D40B) na przepisanie i modyfikacje 16 znakow z 4 zestawow, predkosc uzalezniona od linii w ktorej startuje procka

a ile zajmuje , dwie procedury dla dwóch buforów inicjalizujace zmienne i bufory to 2 banki pamieci

8 klatek animacji ducha z przesunieciem o 1 pixel w prawo to 4 banki pamieci

ogolnie wszystko rozpisane i rozpetlone

Jak skończysz to załącz do MADS-a, albo mi podeślij ten silnik. Chętnie go potestuje:)

33

Hej!

solo/ng napisał/a:

Zybex jest na znakach, 50 fps. choc 2x2 pixle, ale ladny i szybki engine (tlo + sprity).

hmmm... wydaje mi się iż zarówno Zybex jak i draconus były w trybie graficznym (tryb $0D ANTICA). Zawsze mnie zastanawiało czemu te gdy były robione w trybie $0D a nie $0E i kiedyś doszedłem do wniosku iż było to spowodowane ilościa dostepnej pamięci, gry musiały działać na gołym ATARI (64KB RAM), a podwójne buforowanie takich ekranów zajmowało trochę RAMu. Dlatego sadzę iż zarówno Draconus jak i Zybex miały grafikę w trybie $0D.

pozdrawiam
Seban

34

hmm... w sumie jakby na ten tryb przerobić, to by chyba też tragedii nie było...

Ale gierka się przyda. :)


Aha - a jak się czuje Yie Ar...? Znalazłeś już może tego buga?

I Ty zostaniesz big endianem...

35 Ostatnio edytowany przez vega (2006-08-14 13:22:37)

miker napisał/a:

Aha - a jak się czuje Yie Ar...? Znalazłeś już może tego buga?

Szukałem i nie znalazłem....i mi się odechciało wkońcu. Poza tym sypaniem się nie wiem dlaczego są jeszcze pewne mniejsze błedy.

Wogóle to myślę, że najpierw to trzeba napisać raz, a dobrze super szybką prockę rysującą na znakach sprite'y takie jak na C64 dla jakiegoś sensownego układu ekranu (wg. mnie najlepiej 4 zestawy znaków zmieniane co wiersz). I wtedy łatwo będzie się konwertować gry. (muzę można odtwarzać SID2Pokey, grafę zripować ACTIONReplay, tylko logikę gry napisać trzeba od nowa).

Oczywiście procka ta będzie musiała być rozpętlona i rozpisana maksymalnie. Do tego wszystkie klatki animacji sprite'ów muszą być pomnożone przez 4 z przesunięciem o 1 pixel. Podejrzewam więc, że gierki na C64 mieszczące się w 64KB na ATARI będą musiały być na 192KB, albo i 256KB.

36

Kurczę, no szkoda, bo w sumie gierka już w zasadzie kompletna... :(

I Ty zostaniesz big endianem...

37 Ostatnio edytowany przez tebe (2006-08-15 11:04:20)

przyklad dzialania nowego silnika http://mads.atari8.info/softsprt.zip

duchy o rozmiarze 12x24 pixle

5 duchow = 1 ramka
11 duchow = 2 ramki
19 duchow = 3 ramki

w zalaczonym przykladzie wyswietlanych jest 16 duchow, znaki tła maja kody 0..63, wiecej duchow oznacza ze tlo będzie składać sie z mniejszej liczby znaków

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

38

Niezłe, dokładnie o to mi chodziło:)

A dodasz jeszcze opcje wykorzystania sprzętowych sprite'ów? Mam na myśli "podkładanie" lub "nakładanie" grafiki PM/G na wybrane sprite'y.

Chętnie też podejrzałbym kod źródłowy:)

39 Ostatnio edytowany przez tebe (2006-08-15 10:36:28)

mozna dodac taka opcje, oczywiscie max 8 duchow byloby w ten sposob podbarwione, bo multiplexera tutaj nie ma

pozatym mozna wykorzystac piorytet 0 duchow, przez co duch podbarwi (rozjasni) danym kolorem wszystkie pixle grafiki ducha programowego

p.s.
usprawiony mads http://mads.atari8.info/asembler.exe  podczas pisania zauwazylem pare mozliwych udogodnien i uaktualnilem mads'a przez co tylko ta wersja poprawnie asembluje kod silnika duchow

http://mads.atari8.info/softsprt.zip  - wersja silnika z kodem źródłowym

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

40

No fajny silniczek.

Tak z ciekawości - ile to pamięci zabiera?

I Ty zostaniesz big endianem...

41 Ostatnio edytowany przez tebe (2006-08-15 14:31:10)

2 banki na procedury inicjujace BUF2, BUF3 i kazde nastepne 4 banki na nowy kształt (animacje) ducha

zalaczony przyklad zajmuje 2+4+4 = 10 bankow pamieci  - 1 = 9, bo jednym z bankow pamieci jest tak naprawde bank $FE a ten miesci sie przeciez w podstawowej pamieci RAM :)

pamiec podstawowa (plik GLOBAL.HEA) $A000..$CFFF:

B1scr    = $a000        ; dane obrazu dla BUFOR #1 (ten obszar jest kopiowany do BUFOR #2, BUFOR #3)
B1inv    = B1scr+$400    ; dane inversu dla BUFOR #1 (stale wartosci, jesli modyfikujemy B1SCR to tutaj musimy uaktualnic invers)
B2scr    = B1inv+$400    ; dane obrazu dla BUFOR #2 (ulega modyfikacji podczas nakladania duchow)
B3scr    = B2scr+$400    ; dane obrazu dla BUFOR #3 (ulega modyfikacji podczas nakladania duchow)

B2fnt0    = B3scr+$400    ; zestawy znakow dla BUFOR #2
B2fnt1    = B2fnt0+$400
B2fnt2    = B2fnt1+$400
B2fnt3    = B2fnt2+$400

B3fnt0    = B2fnt3+$400    ; zestawy znakow dla BUFOR #3
B3fnt1    = B3fnt0+$400
B3fnt2    = B3fnt1+$400
B3fnt3    = B3fnt2+$400

program obslugi $2000..$2FFF

p.s.
Vega Ty chyba nie chcesz uzywac duchow sprzetowych do wykrywania kolizji ? bo to da sie zrealizowac programowo, obliczyc odległość srodka jednego ducha od drugiego, wartosc z odpowiedniego przedzialu bedzie oznaczac kolizje

p.s.#2
podbarwic na calej szerokosci mozna tylko duchami o podwojnej szerokosci, pociski nawet najszersze podbarwia tylko 8 pixli

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

42

tebe napisał/a:

2 banki na procedury inicjujace BUF2, BUF3 i kazde nastepne 4 banki na nowy kształt (animacje) ducha

widzę, że ok.10 klatek animacji ducha pochłania 4 banki?...a w Bubble Bobble mamy takich klatek 127...trzeba by z ok. 820KB pamięci ATARI na wszystkie klatki. Trochę dużo:P

tebe napisał/a:

Vega Ty chyba nie chcesz uzywac duchow sprzetowych do wykrywania kolizji ? bo to da sie zrealizowac programowo, obliczyc odległość srodka jednego ducha od drugiego, wartosc z odpowiedniego przedzialu bedzie oznaczac kolizje

Nie. Chce po prostu na maxa wykorzystać dostępne kolory. Programowe sprity podkolorowane sprzętowymi to dałoby efekt taki jak na C64 praktycznie.

43

Pytanie tylko takie czy wszystkie te klatki będą naraz potrzebne. Bo może by je trzymać gdzieś w postaci spakowanej i rozpakowywać tylko te niezbędne w danej chwili.

Ewentualnie może zmniejszyć ilość tych klatek...

I Ty zostaniesz big endianem...

44 Ostatnio edytowany przez tebe (2006-08-15 15:57:28)

Vega nie wiem skad Ci wyszlo to 820kb

4 banki zawieraja np. 10 klatek animacji dla ducha + te same klatki animacji z przesunieciem o pixel w prawo, i to wszystko jesli chodzi o animacje jednego ducha, potem mozemy wykorzystywac ta jedna animacje do tworzenia innych duchow, to nie zajmuje juz wiecej pamieci

w Bubble masz powiedzmy na dana chwile 4 rodzaje przeszkadzajek (duchow), czyli:

- 10 klatek animacji ducha #1 ruch w prawo = 4
- 10 klatek animacji ducha #2 ruch w prawo = 4
- 10 klatek animacji ducha #3 ruch w prawo = 4
- 10 klatek animacji ducha #4 ruch w prawo = 4

- 10 klatek animacji ducha #1 ruch w lewo = 4
- 10 klatek animacji ducha #2 ruch w lewo = 4
- 10 klatek animacji ducha #3 ruch w lewo = 4
- 10 klatek animacji ducha #4 ruch w lewo = 4

to wszystko zajmie 512kb, na tej podstawie mozesz stworzyc np. 16 (albo wiecej) roznych duchow o maksymalnie 4 rodzajach ksztaltow i 2-och kierunkach poruszania sie

p.s.
nowsza wersja uwzglednia programy obslugi dla kazdego ducha, w programie obslugi mozna zmieniac pozycje x,y, dodac podbarwienie duchem sprzetowym, wykrywac kolizje, reagowac na kolizje itp itd.

p.s.#2
mozna skrocic 4 banki do 1 banku jesli skorzystac z adresowania indeksowego, obecnie jest tak:

 lda (src),y
 and msk,x
 ora shp,x
 sta (dst),y

wersja krotsza ale dluzsza w cyklach:

 lda (src),y
 and (msk),y
 ora (shp),y
 sta (dst),y

z pobieznych testow wynika ze tym sposobem tracimy tylko jednego ducha, czyli zamiast 5 duchow w 1 ramce, bedziemy mieli 4 duchy w 1 ramce

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

45 Ostatnio edytowany przez vega (2006-08-15 16:34:55)

tebe napisał/a:

10 klatek animacji ducha #1 ruch w prawo = 4
- 10 klatek animacji ducha #2 ruch w prawo = 4
- 10 klatek animacji ducha #3 ruch w prawo = 4
- 10 klatek animacji ducha #4 ruch w prawo = 4

- 10 klatek animacji ducha #1 ruch w lewo = 4
- 10 klatek animacji ducha #2 ruch w lewo = 4
- 10 klatek animacji ducha #3 ruch w lewo = 4
- 10 klatek animacji ducha #4 ruch w lewo = 4

to wszystko zajmie 512kb, na tej podstawie mozesz stworzyc np. 16 (albo wiecej) roznych duchow o maksymalnie 4 rodzajach ksztaltow i 2-och kierunkach poruszania sie

No to jak widzę mamy 80klatek w 512KB,a dla 127klatek? (mi wychodzi ok. 820KB)


tebe napisał/a:

.....z pobieznych testow wynika ze tym sposobem tracimy tylko jednego ducha, czyli zamiast 5 duchow w 1 ramce, bedziemy mieli 4 duchy w 1 ramce....

No to w sumie jeżeli to tylko taka prosta zmiana to można by przed asemblacją kodu ustalić, która wersja nam odpowiada np. w jakiejś stałej. Możnaby w ten prostu sposób dostosować ją do włąsnych potrzeb:)

46

BTC scena nie zna ograniczeń

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

47 Ostatnio edytowany przez tebe (2006-08-15 21:35:01)

wersja zajmujaca mniej pamieci, wszystkie klatki animacji ducha w 1 banku

http://mads.atari8.info/softsprt_slow.zip

nie jest to wersja finalna, jeszcze cos sie "kaszani", ogolnie po dodaniu potrzebnych obliczen itp engin zwolnil dla 3 ramek aż o 5 duchow (mozna jeszcze dokonac malej optymalizacji wtedy strata bedzie może rzędu 3 duchow)

na chwile obecna 14 duchow = 3 ramki (wersja pamieciozerna 3 ramki = 19 duchow)

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

48

BTC: a carty 8MB...? Teoretycznie do takiej pojemności obsłuży zwykłe Atari...

Sikor umarł...

49

wlasnie wpadlem na pomysł trzeciego sposobu, który bylby połączeniem obu wcześniejszych, szybkości i małej zajetości banków pamieci, kosztem pamięci podstawowej

musimy z gory założyc jaka może być maksymalna liczba klatek animacji ducha, np. 8 i nie więcej
dla tych 8 klatek rozpisujemy procedure modyfikujaca zestaw znakow, zajmuje ona dokładnie $516 (1302) bajtów, wersja dla ducha na pozycji PIXEL=0 zajmuje $456 (1110) bajtów (modyfikujemy 12 a nie 16  znakow)

dane wszystkich klatek animacji lacznie z przesunieciem o pixel w prawo beda pod stalymi adresami w obszarze $4000..$7FFF czyli w banku pamieci

wystarczy przelaczyc bank, aby procedury modyfikujace z pamieci podstawowej zaczely czytac dane opisujace innego ducha :)

wersja najszybsza zajmie 8*1302+8*1110=19296 ($4B60) bajtow pamieci podstawowej, wersja wolniejsza 8*1302=10416 ($28B0) bajtow pamieci podstawowej

oczywiscie jesli przyjmiemy wieksza liczbe dopuszczalnych klatek animacji np. 10,12 bedzie potrzeba wiecej pamieci podstawowej, tak ze moze jej nie starczyc do innych celow (obszar $4000..$7FFF jest uzywany przez banki, wiec niewiele z niego skorzystamy)

ogolnie ta wersja wydaje sie najbardziej atrakcyjna, mimo tego że narzuca ograniczenie co do ilosci maksymalnej liczby klatek animacji i jest mało gospodarna w wykorzystaniu pamieci bankow, bo 8 klatek zajmie niecałe 9kB banku

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

50 Ostatnio edytowany przez vega (2006-08-16 12:10:03)

A engine mógłby przewidywać również rysowanie spritów nie tylko 12x24 ale i 8x24? Bo w BB np: te balony czy fruwające litery takiej są wielkości. Teoretycznie możnaby to wszystko robić jako 12x24, ale wtedy zabraknie znaków na stworzenie wszystkich sprite'ów na ekranie:(

Jak rozumiem istnieje już podkładanie albo nakładanie grafiki PM/G pod sprity programowe. Jak to mniej więcej działa?