Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
BigPEmu 1.12 Richard Whitehouse wydał BigPEmu 1.12
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
Witam,
Jest taka metoda kolorowania ekranu że w przerwaniu DLI w trakcie jak "plamka" biegnie poziomo
zmienia się kolor. (jest to chyba wykorzystywane np. w Graph2Font).
Pytanko takie mnie naszło: czy ta metoda (jeżeli użyta powiedzmy w 50% ekranu)
nie obciąży zbytnio procesora?
Czyli inaczej, czy starczy jeszcze czasu procesora na obsługę gry?
pozdrawiam
Różnie określają ten sposób zmiany kolorów, ale przerwanie DLI samo w sobie nie jest wystarczające, można wywołać program przerwania DLI ale dalej trzeba już sie synchronizować odpowiednią liczbą cykli CPU.
Uruchom G2F (Graph2Font), wybierz MODE=GED+ lub MODE=GED--, przejdź do EDIT RASTERS (ALT+R), zobaczysz okno z domyślną listą rozkazów CPU dla jednej linii ekranu, teraz możesz ją modyfikować co wpłynie na miejsce zmiany kolorów na ekranie, ale idealnej dowolności nie ma.
Podsumowując metoda o którą pytasz to dzielenie rastra "split raster", w tej metodzie nie uzywasz rejestru $D40A jak ma to miejsce w przerwaniu DLI, tylko musisz napisac swoj program którym idealnie co do cyklu zsynchronizujesz sie z tworzoną linia obrazu. Musisz jeszcze wiedzieć ile czasu (w cyklach CPU) zajmuje stworzenie liniii obrazu dla konkretnej szerokości obrazu. G2F obsługuje dzielenie rastra dla ekranu normalnego i wąskiego, dla szerokiego jest to mało opłacalne.
Innym programem wykorzystującym dzielenie rastra jest GED i pewien program FOX'a, którego nazwy zapomnialem, oba na małe ATARI.
Pytanko takie mnie naszło: czy ta metoda (jeżeli użyta powiedzmy w 50% ekranu)
nie obciąży zbytnio procesora?
Czyli inaczej, czy starczy jeszcze czasu procesora na obsługę gry?
Jeśli zostanie użyta w 50% ekranu to CPU w 50% ekranu będzie zmieniał kolory i na nic więcej nie będzie miał czasu.
Trzeba tak naprawdę pomieszać zmiany w rastrze ze zmianami na przerwaniu DLI jeśli to możliwe bo najczęściej są fragmenty ekranu które wymagają zmian koloru co linie i takie fragmenty które tego nie wymagają. Można wtedy wywoływać przerwanie DLI dla konkretnej linii ekranu, odpowiednio sie zsynchronizować i dalej kontynuować zmiany za pomocą dzielenia rastra. Ogólnie wymagana jest optymalizacja programu przerwania DLI, przykładem takiej optymalizacji jest zbliżająca sie gra GETRIS. Czyli jeśli jesteś dobrym koderem to dasz radę.
Ostatnio edytowany przez tebe (2006-02-07 18:53:14)
Podsumowując metoda o którą pytasz to dzielenie rastra "split raster", w tej metodzie nie uzywasz rejestru $D40A jak ma to miejsce w przerwaniu DLI
Jeśli zostanie użyta w 50% ekranu to CPU w 50% ekranu będzie zmieniał kolory i na nic więcej nie będzie miał czasu.
Mozna tak, a można i z $D40A z przerwaniem DLI tylko w 1szej linii obszaru splitowanego.
Grunt, aby pierwsze połowa kodu wykonywanego w 1 linii, (do tych 50%) byla wycyklowana,
nastepna (po zmianie koloru) juz nie musi być, byle trwała krócej niż do końca linii po czym
STA $D40A i następna linia.
A jak to sie ma do NTSC? Czy na NTSC kolory wypadną w innych miejscach, czy różnica jest pomijalna?
jesli w NTSC narysowanie linii ekranu zajmuje tyle samo czasu CPU to tak, jesli nie to nie
Coś się udało :-)
Tylko dlaczego plamka "szybciej biegnie" po lewej stronie ekranu?
Myślałem że to błąd emulatora, ale nie - jest to też opisane w instrukcji G2F.
Co swoją drogą potwierdza fakt że w demie "Bitter Reality"
duży scroll w części "Partyland" jest robiony tą techniką - (rispekt!)
Ponieważ też się tak wydłuża po lewej stronie.
Tylko jak zrobiono przesów poziomy (wstawiali nop'y w kodzie splitującym)? :-|
Ostatnio edytowany przez unicorn7 (2006-02-11 12:49:06)
w G2F i Edit Raster jest coś takiego jak GLOBAL OFSET przyjmuje zakres <-8..8> jest to opoznienie przed glownym programem realizujacym dzielenie rastra, jego zmiana powoduje przesuniecie zmian kolorow na calym ekranie
jesli w NTSC narysowanie linii ekranu zajmuje tyle samo czasu CPU to tak, jesli nie to nie
Chyba już niedługo będziesz wiedział, bo zdaje się, że Getris nie rusza pod NTSC...
Czy ktoś próbował Raster Split na 65c816 ?
Czy zmianę koloru w rastrze mozna na nim robić kilka razy szybciej?
Zależy od taktowania. Na 65c816 z 1,77 MHz raczej niewiele zyskasz. A dopałkę mało kto ma (laoo ma warpa, a pasiu ma f7 - i to na razie wszystko).
na 65816 mozna zrobic to szybciej jesli uzyjesz 16-bit rejestrow, tyle ze dotyczy to specyficznej kolejnosci wypelniania rejestrow kolorów
No to właśnie mam za ów niewielki zysk. W porównaniu z warpem nawet.
Ostatnio edytowany przez drac030 (2006-06-11 23:35:54)
Tylko dlaczego plamka "szybciej biegnie" po lewej stronie ekranu?
Myślałem że to błąd emulatora, ale nie - jest to też opisane w instrukcji G2F.Co swoją drogą potwierdza fakt że w demie "Bitter Reality"
duży scroll w części "Partyland" jest robiony tą techniką - (rispekt!)
Ponieważ też się tak wydłuża po lewej stronie.
Jest to spowodowane przez Antic, który w tym właśnie czasie, kiedy plamka biegnie po lewej stronie ekranu korzysta ze swoich praw do zatrzymywania CPU. Nie jestem w tej chwili pewien, ale chyba w celu pobrania danych z pamięci ekranu. Było to łądnie opisane w jakimś artykule Foxa w Syzygy. Artykuł polecam, jeśli chcesz się bawić w cyklowanie koloru.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.073 sekund, wykonano 20 zapytań ]