ZX Spectrum > GRAFIKA
Tryb gigascreen
matofesi:
No ja rzuciłem. I albo czegoś nie rozumiem albo umyka mi subtelność koncepcji. Tak na szybko kod zajmuje się głównie odczekiwaniem aż raster wejdzie w ekran a potem przez kolejne 192 linie przełączaniem na przemian ekranów. Jak się zrobi zrzut ekranu z emulatora i obejrzy dokładnie to widać, że w pojedynczym cellu są max 4 kolory i max 2 w linii. Czyli mamy dwa ładnie dopasowane obrazki i kod, który co linię wyświetla na przemian raz jeden raz drugi. Jeśli nie ma tu nic bardziej sprytnego, co na szybko mógłbym przegapić to nie rozumiem dlaczego 128 miałoby tego efektu nie pociągnąć? A brak czasu na dźwięk jest łatwy do wyjaśnienia - najpierw musimy się wstrzelić dokładnie w początek ekranu - z braku przerwań trzeba po prostu odczekać czas od początku ramki a potem przez większość ekranu chodzą głównie dokładne pętle opóźniające. Na procedurę do dźwięku zostaje ten kawałek na dolnym borderze i (nie zastrzelcie jeśli się mylę - nie pamiętam w którym momencie wyzwalane jest przerwanie) powrót plamki.
No chyba, że zupełnie nie zrozumiałem koncepcji ;)
YERZMYEY/HOOY-PROGRAM:
MAT:
> No ja rzuciłem. I albo czegoś nie rozumiem albo umyka mi subtelność koncepcji. Tak na szybko kod zajmuje się głównie odczekiwaniem aż raster wejdzie w ekran a potem przez kolejne 192 linie przełączaniem na przemian ekranów. Jak się zrobi zrzut ekranu z emulatora i obejrzy dokładnie to widać, że w pojedynczym cellu są max 4 kolory i max 2 w linii. Czyli mamy dwa ładnie dopasowane obrazki i kod, który co linię wyświetla na przemian raz jeden raz drugi. Jeśli nie ma tu nic bardziej sprytnego, co na szybko mógłbym przegapić to nie rozumiem dlaczego 128 miałoby tego efektu nie pociągnąć?
---------------
Nie nie, no więc właśnie napisałem później, że jednak pociągnie, skoro Zilog (ten czeski scener) wypuścił engine w 2003 roku, czy coś koło tego, po prostu nigdy nie wzróciłem uwagi, że to właśnie jest takie wyświeltanie, jak piszesz - co linię.
Bardziej sprytne rzeczy to są w samym konwerterze na PC, a w procedurze wyświetlania to już mniej (chociaż i tak był to świetny pomysł).
Teraz się jeszcze zastanawialiśmy z Tygrysem, do jakieś rozdzielczości trzebaby zmniejszych obrazek, żeby to działało też na 48K (nad wymianą zawartości ekranu tu oczywiście trzebaby pomyśleć inaczej, niż na 128K, ale były dema w tym stylu robione, więc pamiętam, że się da).
Ot taka ciekawostka. Chociaż gdyby było, to zapewne prędzej czy później tego użyjemy.
> A brak czasu na dźwięk jest łatwy do wyjaśnienia - najpierw musimy się wstrzelić dokładnie w początek ekranu - z braku przerwań trzeba po prostu odczekać czas od początku ramki a potem przez większość ekranu chodzą głównie dokładne pętle opóźniające. Na procedurę do dźwięku zostaje ten kawałek na dolnym borderze i (nie zastrzelcie jeśli się mylę - nie pamiętam w którym momencie wyzwalane jest przerwanie) powrót plamki.
------------
Uuuuu, no to już dla mnie oczywiście czarna magia. :) :) :) :) Ale dobrze wiedzieć, jak będę kogoś o to męczył i otrzymam odpowiedź, że "się nie da", to powiem, że napewno się da, bo MAT tak powiedział. :) :) :) :) :) :) :) :) :) :) :) :) :)
No nic, chodzi o to, że zapewne Joulo nie będzie chciał pixelować na Spectrum, tylko na PC (rozumiem go), a skoro na PC, to mógłbym mu udostępnić większą paletę, skoro w tym trybie Spectrum wyświetli ok. 112 kolorów. Przynajmniej się chłopaczyna rozrusza, przypominając sobie dawne czasy, haha.
Pzdr.
matofesi:
Swoją drogą jeśli faktycznie cały efekt polega na interlace'owym przełączaniu ekranów i jedynym problemem jest wstrzelenie się w odpowiedni punkt w czasie to przy założeniu, że robimy ten efekt dla konkretnego urządzenia (albo jesteśmy w stanie zrobić detekcję i wygenerować kod opóźniający dla dowolnej maszyny) to moim zdaniem powinno się tam dać puścić jakiegoś chiptune'a - trzeba by tylko zrobić custom playera tak, żeby go podzielić na dwie części - pierwsza musiałaby się liczyć zawsze w tym samym czasie i byłaby częścią pierwszej pętli opóźniającej, druga - grająca musiałaby się zmieścić na końcu ekranu.
Można też zaryzykować coś innego - w prawdziwymy 128 (nie wiem jak w innych wersjach/klonach) można się było "wtaktować" w konkretną linię czytając coś z któregoś portu - nie pamiętam dokładnie jak to szło, ale robiłem kiedyś w ramach testów prostego scrollera skaczącego po sinusoidzie (FLIP?) z normalnym obrazkiem w tle. Całość działała tak, że najpierw robił się scroller w konkretnym punkcie ekranu bez żadnego czyszczenia poprzedniej wersji itp. Potem wyświetlany był ekran z tłem i pętla czekała na konkretną linię, włączała ekran ze scrollerem i czekała jeszcze parę linii a potem z powrotem włączała tło. Efekt był prosty, ale pokazywał, że da się wstrzelić w konkretny punkt ekranu. Można by więc zrobić część playera na górnym borderze tak, żeby na pewno nie wlazło na ekran a potem się wstrzelić w początek ekranu ścinając na przykład pierwsza linię grafiki i dalej już normalny interlace z borderem jako buforem na te parę taktów niedokładności na procedurę czekającą na początek ekranu. I na koniec druga część playera. I w zasadzie przy poprawnym rozwiązaniu kwestii całość mogłaby chodzić z wyłączonymi przerwaniami ;)
Uff... Sorry za teoretyczne dywagacje i off-topic ;)
matofesi:
Na 48 to za wiele nie pociągniesz. Czytałem ostatnio analizę Simona Owena (http://simonowen.com/blog/2011/09/29/zxodus-engine/) ile się da zmienić atrybutów na 48 - w kontekście ZXodus Engine'a. Wynika z niej, że to, co ZXodus robi czyli 144 piksele szerokości (18 kolumn) z pełną kontrolą atrybutów z dokładnością do linii to jest max tego, co można zrobić. A to oznacza, że być może max tego, co dałoby się z 48 wycisnąć to połowa tego - do zrobienia pełnego interlace'u trzeba podmienić zarówno atrybuty jak i samą bitmapę. Tyle, że tych 9 kolumn też się nie da zrobić bo 18 atrybutów to jest już totalny wyścig z rastrem i na pewno obraz by się ciął. Pewnie jakby pogłówkować to jakiś kawałek dałoby się wymodzić, ale tak na prawdę zrobienie takiego efektu to znacznie więcej niż prosty multicolor.
Ja bym się w każdym razie nie podjął dłubaniny - podejrzewam, że efekt byłby niewart włożonej roboty.
Tygrys:
Dzięki MAT za analizę. Tam, ponad to co napisałeś więcej nie ma.
Dla 48ki można zrobić procedurę generującą gotowy kod dla konkretnego obrazka. Taki kod by zajmował kilka kilo, a przy odrobinie wysiłku mógłby obsługiwać dowolny model ZXa (opóżnienia itp).
Co do muzyki to powinna się jeszcze odegrać po skończeniu podmiany atrybutów. Jeżeli chce się to zrobić przed narysowaniem pierwszego koloru, to ma sie do dyspozycji okolo 14000T. Mi to wystarczyło do przerzucenia 768bajtów atrybutów i odebraniu muzyki.
A jeżeli to byłoby problematyczne to nie widzę problemu przeliczenia muzyki już poza rastrem, a wysłanie danych do rejestrów AY już w przerwaniu.
Nawigacja
[#] Następna strona
Idź do wersji pełnej