🚀 go-pugleaf

Wyjątkowo zostawię całość pod spodem.

a) ilość danych przesłanych, a nie ilość danych przesłanych gdyby to
były skompresowane np. 0.
b) dekompresja ekranu do wyświetlenia, a nie (de)kompresja danych
przesyłanych (na potrzeby upchania w założonej ilości pamięci)
c) nie chodzi o wyliczenie ilości bajtow zajmowanych w Atari tylko o
ilość możliwych permutacji kolorów przy danej rozdzielczości
wyświetlanych na ekranie (ocerscan w Atari to dodanie permutacji
wynikającej ze zmiany kolorów spritami na ramce).
d) Pan już odpadł bo totalnie rozminął się z pytaniem, a powtórek nie
przewiduję jeśli nie są dopytaniem o nie zrozumiane aspekty sprawy.
Wszystkie odpowiedzi przechowuję wraz z opisem kto konkretnie w nich
maczał palce.
e) po co? a po co robić dekoder "mpeg" do Amigi oparty o okolice tego
pomysłu?

Dam przykład pytania po co:
Można wtedy np. zmodyfikować część platformówek tak żeby zachowując
dynamikę oryginału na pewnych modelach telewizorów pokazywały grę o
zupełnie zmienionym obliczu.

Jak mógłby wyglądać taki program po stronie telewizora:
* aktywacja trybu boost
* odebranie np. wyglądu ekranu ze zwiększoną ilością szczegółów
* wyciemnienie komnaty i zostawienie tylko obiektów ruchomych z
boostem po stronie TV

Wtedy np. Atari pełniłby rolę sterownika I/O, mechaniki rozgrywki, a
de fakto za wizualizację odpowiadałby telewizor.

Na pewno w komputerze mogę sobie z użyciem tunera TV w miarę prosto
takie coś zaimplementować ale w dzisiejszych czasach i TV przynajmniej
teoretycznie mogłyby pozwolić na odkurzenie zabawek typu Atari.

Co więcej teoretycznie możnaby wtedy i z Atari 2600 zrobić całkiem
przyjemną konsolkę do grania, a gry implementować jako rekompilowany
strumień informacji dla danej konsoli zapisany na kartridżu do użytku
w zasadzie z dowolnym starym gratem.
Acz oczywiście zdaję sobie sprawę, że te wszystkie stare graty to już
dawno śmietnik gryzą i nikogo nie zainteresuje nie sprzedawanie
kolejnych zabawek osobom, które mają potwierdzone, że konsolami nie
wzgardzą.

Zresztą jak już wspominałem kartridże o pojemnościach MB nie są wcale
dziś tanie, a do grania w gry flashopodobne o jedynie nieco lepszej
dynamice nikogo ceną się nie skusi.

Artur Górniak


On 22 Gru, 15:53, Konrad Stepien <kon...@sekator.interdata.net.pl>
wrote:
> On 2011-12-22, ArchieIl <ag-s...@argo.pl.eu.org> wrote:
>
> > Dam Wam polę do porównywania się z innymi komputerami.
>
> > Zakładając, że zamiast monitora/TV do 8bitów podłączymy pudełko, które
> > traktuje zapis wyjścia video jako skompresowany strumień danych, który
> > można użyć np. do oglądania filmów (patrz stosowna przystawka do
> > amigi).
>
> > Ile maksymalnie bajtów na sekundę można przesłać korzystając z danego
> > 8bitowca poprzez strumień video (gołych danych bez kompresji, korekcji
> > itp.).
>
> Tyle ile jest punktów na ekranie razy ilość bitów koloru podzielić przez 8.
>
> > Odpowiedzi prosiłbym segregować jako:
> > * bare konkretny model np. Atari 400, 130XE itp.
> > * opis użytej metodologii: tryb, sprity, "overscan"
>
> W Atari nie ma potrzeby "overscanów", wystarczy DL inne napisać.
>
> > * turbodoładowania czyli rozszerzenia pamięci,
>
> Jak dobrze rozumię zagadnienie, to nie ma to najmniejszego znaczenia.
>
> > I musiałoby to zostać sprawdzone stosownymi wyliczeniami czy cykli
> > starczy w przypadku intensywnego podkolorywania/dekompresowania kodu
> > ramki w locie.
>
> Ale miało być bez kompresji.
>
> > A wynik wprost to:
> > ilość danych na ramkę, sekundę, maksimum przesłane z użyciem warunkow
> > początkowych.
>
> 48 bajtów na linię, 248 linii, do tego 5x228 w spritach daje 13144 bajtów.
> W trybie NTSC masz 60 ekranów na sekundę co daje 788640 bajtów/sek.
> Coś tam by się dało wsadzić zmieniając kolor w trakcie, minimim 248 bajtów
> na ekren na samych przerwaniach linii, ale raczej do megbajta na sekundę
> się nie dobije.
>
> > Termin realizacji: myślę, że z 10 lat powinno być interesującą ilością
> > czasu żebyście się zainteresowali oraz wykonali stosowne prace.
>
> Ale po co?
>
> --
> Konrad Stępień