1

Mam pytanie:

Czy istnieje, a jeżeli nie to czy jest możliwe zrobienie filmu skladającego sie z klatek, które są tworzone poprzez szybkie rysowanie linii i wypełnianie kształtów fill'em. Czy ATARI się wyrobi?

Zakładamy, że mamy zmodyfikowany ekran(160x192), szybką procedure line i szybkie wypełnianie.

Ekran mógłby być mniejszy niekoniecznie 160x192.

2

A czemu nie. W zależności od tego co uważasz za film.

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

3

Filmik to by było min. z 25-30klatek/s.

4

Hmmm, "Look at our vector-film"...? Overmind chyba, albo Bitter Reality - już nie pamiętam, ale chyba o to mniej-więcej chodzi. Polecam!!! Jakby co - spytać Mikera lub Sebana w którym to demie było... ;)

Sikor umarł...

5 Ostatnio edytowany przez eru (2005-11-14 02:07:09)

Da sie, da sie, co prawda moze nie 25klatek/sec, ale z 10 na pewno :)
Tzn ofkorz przy pelnym ekranie.
Kiedys o tym nawet myslalem, ale padlo to na fazie wektoryzacji grafiki.
Najlepiej zrobic to wypelnianiem 'blitterowym', czyli

 
lda #0 ; dla pierwszej linii tylko
eor bufor_linii
stx bufor_linii ; w X 0, wyczysc
sta bufor_ekranu
eor bufor_linii+40 ;nastepna linia
stx bufor_linii ; w X 0, wyczysc
sta bufor_ekranu+40
...

Tylko potrzebujesz do tego odpowiednich danych i odpowiednie rysowanie linii.

: 404. Stopka not found

6 Ostatnio edytowany przez vega (2005-11-13 21:51:49)

eru napisał/a:

Da sie, da sie, co prawda moze nie 25klatek/sec, ale z 10 na pewno :)
Tzn ofkorz przy pelnym ekranie.
Kiedys o tym nawet myslalem, ale padlo to na fazie wektoryzacji grafiki.
[Tylko potrzebujesz do tego odpowiednich danych i odpowiednie rysowanie linii.

aha, a ekran miałeś jakoś zmodyfikowany?
10klatek/ a cały ekran to nie tak źle:)

Wlasciwie to nie chodzi mi o jakies przeksztalcenia wektorow tylko na żywca rysowanie linii prosto z pliku z danymi. A potem wypełnianie kształtów fill'em.

7 Ostatnio edytowany przez eru (2005-11-14 02:05:51)

uwazaj na bana za cytowanie bezposrednio poprzedzajacego listu :)
a powaznie, to samo rysowanie jest banalne, tak jak mowisz, tylko trzeba przygotowac dane. Wyobraz sobie np ze masz obrazek na PC, powiedzmy skrinszot z second reality. Musisz tak jakby 'odwrocic blitter' i wtedy wykryc linie. Ale nie jest to takie trywialne. Pewnie sa jakies algorytmy, ktore by to zrobily, ale to bylo dawno i nie pamietam :)
w rozdzielczosci 160x100 masz 4000 bajtow do uaktualnienia, wiec sam fill by zabral 12*4000 = 48000, czyli raptem 2 ramki, masz 3 ramki na narysowanie calkiem sporo linii... zeby przyspieszyc mozesz uzyc 80x50 lub 80x100 w 16 kolorach.
powodzenia, na pewno da sie to zrobic.
Aha, i ten blitter ofkorz jest trudniejszy do zrobienia linii, bo kazda roznica w przejsciach kolorow wywoluje nowa linie, wiec potencjalnie znaczaco zwieksza ilosc linii czyli rozmiar danych i predkosc rysowania. Mozna zrobic inny blitter, ale wtedy troche fill zwolni. Na przyklad dla 16-kolorowego trybu, jesli godzimy sie stracic 1 kolor (0), mozna zrobic cos takiego:

  ldy buf ; tam gdzie rysujemy linie, co wazne - nie potrafimy narysowac koloru 0
  beq nochange ; jesli nie ma zmiany, kontynuuj.
  and ands,y ; zgas czesc bitow
  ora buf ; zapal nowe bity
  stx buf ; wyczysc bufor linii, w X jest 0
nochange
  sta screen
  ... i tak dla kazdego bajtu. duuuzy kod :)

Wlasciwie nie musi to wcale byc znaczaco wolniejsze, bo masz 11 cykli dla bajtow, gdzie nie ma zmiany koloru i 22 dla bajtow ze zmiana. Ten poprzedni ma zawsze 12, wiec jesli jest niewiele linii, moze wcale tak duzo nie tracisz.
Jak znam zycie, ludzie wymyslili tez inne blitterki, moze ktos sie podzieli?

: 404. Stopka not found