26.07.2019 13:02
[#1]
UNIT_VBLANK
Czy mógłby mi ktoś rozjaśnić pewną wątpliwość odnośnie timera w amigowym API?
Jeżeli zrobię timer request mając ustawiony UNIT_VBLANK to zgodnie z RKRM dostanę sygnał po pierwszym “vertical blank” następującym po zadanym w zapytaniu czasie. Jest to niby zależne od częstotliwości odświeżania ekranu wybranego trybu graficznego. No i jest to zrozumiałe… ale... chyba nie bardzo tak jest.
W PowerBooku pod MorphOS mam odświeżanie 60Hz, a sygnał dostaję najczęściej 50 razy na sekundę. Czy nie powinno być 60 razy na sekundę skoro jest to zależne od częstotliwości odświeżania ekranu? ReadEClock() też zwraca wartość wskazującą na to, że jest to 50 razy na sekundę.
Czy to faktycznie zależy od częstotliwości czy jest to po prostu historyczny opis dotyczący różnic między PAL (50Hz) i NTSC (60Hz), a na wszystkich innych trybach czy układach graficznych jest po prostu zawsze 50Hz?
Jeżeli jest to zawsze 50Hz to chyba jednak nie będę używał UNIT_VBLANK tylko użyję UNIT_MICROHZ albo UNIT_ECLOCK. Ale do tego będę potrzebował prawdziwej wartości częstotliwości odświeżania ekranu (ile razy na sekundę czy coś takiego) żeby sobie te requesty wysyłać z odpowiednim czasem.
Skąd wziąć częstotliwość odświeżania ekranu tak żeby była prawdziwa, a nie jakieś “zafixowane” 50Hz?
Ostatnia aktualizacja: 26.07.2019 13:02:29 przez MDW
Jeżeli zrobię timer request mając ustawiony UNIT_VBLANK to zgodnie z RKRM dostanę sygnał po pierwszym “vertical blank” następującym po zadanym w zapytaniu czasie. Jest to niby zależne od częstotliwości odświeżania ekranu wybranego trybu graficznego. No i jest to zrozumiałe… ale... chyba nie bardzo tak jest.
W PowerBooku pod MorphOS mam odświeżanie 60Hz, a sygnał dostaję najczęściej 50 razy na sekundę. Czy nie powinno być 60 razy na sekundę skoro jest to zależne od częstotliwości odświeżania ekranu? ReadEClock() też zwraca wartość wskazującą na to, że jest to 50 razy na sekundę.Czy to faktycznie zależy od częstotliwości czy jest to po prostu historyczny opis dotyczący różnic między PAL (50Hz) i NTSC (60Hz), a na wszystkich innych trybach czy układach graficznych jest po prostu zawsze 50Hz?
Jeżeli jest to zawsze 50Hz to chyba jednak nie będę używał UNIT_VBLANK tylko użyję UNIT_MICROHZ albo UNIT_ECLOCK. Ale do tego będę potrzebował prawdziwej wartości częstotliwości odświeżania ekranu (ile razy na sekundę czy coś takiego) żeby sobie te requesty wysyłać z odpowiednim czasem.
Skąd wziąć częstotliwość odświeżania ekranu tak żeby była prawdziwa, a nie jakieś “zafixowane” 50Hz?
Ostatnia aktualizacja: 26.07.2019 13:02:29 przez MDW
26.07.2019 14:23
[#2]
Re: UNIT_VBLANK
@MDW, post #1
Jeżeli zrobię timer request mając ustawiony UNIT_VBLANK to zgodnie z RKRM dostanę sygnał po pierwszym “vertical blank” następującym po zadanym w zapytaniu czasie. Jest to niby zależne od częstotliwości odświeżania ekranu wybranego trybu graficznego. No i jest to zrozumiałe… ale... chyba nie bardzo tak jest.
Pod Amiga unit VBLANK jest na sztywno podpiety pod przerwanie synchronizacji pionowej. Dlatego czestotliwosc tego przerwania ma dosc spora rozpietosc - popatrz na tryby PAL/NTSC/DBLPAL/DBLNTSC/VGA/SUPER36/SUPER72. W przypadku trybow dla egzotyczniego monitora A2024 nie wiem jak jest z czestotliwoscia vblank, tak samo jak nie wiem co sie dzieje w przypadku trybow super hires na Indivision.
W PowerBooku pod MorphOS mam odświeżanie 60Hz, a sygnał dostaję najczęściej 50 razy na sekundę. Czy nie powinno być 60 razy na sekundę skoro jest to zależne od częstotliwości odświeżania ekranu?
Powinno tak byc jezeli MorphOS obsluguje przerwanie synchronizacji pionowej ukladu graficznego. Jezeli nie, to zapewne MOS tylko emuluje UNIT_VBLANK uzywajac arbitrarnie wybranej stalej, na przyklad 50Hz, niezaleznie od wyswietlanego trybu graficznego.
Czy to faktycznie zależy od częstotliwości czy jest to po prostu historyczny opis dotyczący różnic między PAL (50Hz) i NTSC (60Hz), a na wszystkich innych trybach czy układach graficznych jest po prostu zawsze 50Hz?
Na klasycznej amidze jest to zawsze przerwanie Vertical Blank, jego czestotliwosc to juz sprawa drugorzedna.
Jeżeli jest to zawsze 50Hz to chyba jednak nie będę używał UNIT_VBLANK tylko użyję UNIT_MICROHZ albo UNIT_ECLOCK. Ale do tego będę potrzebował prawdziwej wartości częstotliwości odświeżania ekranu (ile razy na sekundę czy coś takiego) żeby sobie te requesty wysyłać z odpowiednim czasem.
To jeszcze powiedz do czego ci potrzebny taki timer, bo nawet majac dokladna czestotliwosc odswierzania pionowego niekoniecznie sie za pomoca timer.device poprawnie zsynchronizujesz z obrazem. Prawie na pewno bedziesz mial przesuniecie fazowe (event z timer.device odpalony np. gdzies w polowie rysowania ekranu) i na pewno oba zegary (obraz i twoj timer) nie beda pracowac z absolutnie identyczna czestotliwoscia.
26.07.2019 14:36
[#3]
Re: UNIT_VBLANK
@MDW, post #1
Chciałbym dodać, że UNIT_VBLANK oraz UNIT_MICROHZ opisują dokładność czasową w jakich timer.device ma pracować.
UNIT_VBLANK ma małą dokładność, ale ma niesamowicie mały narzut.
Z kolei UNIT_MICROHZ ma bardzo dużą dokładność, ale większy narzut.
To nie jest tak, że UNIT_VBLANK czeka na ramkę, tylko odmierza czas w podanej dokładności. Do odmierzania ramek służy przerwanie VBlank.
UNIT_VBLANK ma małą dokładność, ale ma niesamowicie mały narzut.
Z kolei UNIT_MICROHZ ma bardzo dużą dokładność, ale większy narzut.
To nie jest tak, że UNIT_VBLANK czeka na ramkę, tylko odmierza czas w podanej dokładności. Do odmierzania ramek służy przerwanie VBlank.
26.07.2019 15:05
[#4]
Re: UNIT_VBLANK
@MDW, post #1
W PowerBooku pod MorphOS mam odświeżanie 60Hz, a sygnał dostaję najczęściej 50 razy na sekundę. Czy nie powinno być 60 razy na sekundę skoro jest to zależne od częstotliwości odświeżania ekranu?W MorphOS-ie wszystkie unity timer.device są emulowane za pomocą UNIT_CPU (wewnętrzny timer procesora) i częstotliwość ticków UNIT_VBLANK ma się nijak do odświeżania obrazu.
26.07.2019 15:17
[#5]
Re: UNIT_VBLANK
@Hexmage960, post #3
UNIT_VBLANK ma małą dokładność, ale ma niesamowicie mały narzut.
Dosc mala rozdzielczosc (nie dokladnosc), za to duza stabilnosc.
Z kolei UNIT_MICROHZ ma bardzo dużą dokładność, ale większy narzut.
Dosc duza rozdzielczosc, ale stabilnosc moze byc gorsza niz VBLANK.
To nie jest tak, że UNIT_VBLANK czeka na ramkę, tylko odmierza czas w podanej dokładności. Do odmierzania ramek służy przerwanie VBlank.
W praktyce, o ile mnie pamiec nie myli, UNIT_VBLANK pod amiga klasyczna jest jednym z handlerow wiszacych wlasnie na przerwaniu VBLANK. Mozesz skorygowac jezeli jest inaczej, chociaz watpie, bo takie zachowanie sugeruje nie tylko moja pamiec ale tez autodoc.
26.07.2019 15:18
[#6]
Re: UNIT_VBLANK
@mschulz, post #2
Potrzebuję tego w takiej typowej pętli głównej programu, który coś tam sobie rysuje OpenGLem. Zrezygowałem z SDL i kilka rzeczy muszę sobie zaimplementować samemu. 
Rysuję klatkę i chcę wysłać sobie time request żeby kolejne rysowanie było najszybciej jak się da ale nie wcześniej niż w kolejnym odświeżaniu ekranu. Chodzi mi o to żebym nie rysował ekranu częściej niż 60 razy na sekundę jeżeli ekran jest odświeżany 60 razy na sekundę, bo to nie ma sensu, szkoda męczyć wiatraka na procesorze.
To jest wszystko proste tylko muszę wiedzieć jak często jest odświeżany ekran żeby potrafić zmontować time request i dostać sygnał w kolejnej klatce (albo najszybciej jak się da jeżeli rysowanie klatki trwało dłużej niż jedno odświeżanie ekranu).
Zwykle gdzieś tam w innych API robiło się to tak, że po rysowaniu wywoływało się jakieś WaitVbl(). A np. API macOS podaje się wskaźnik na funkcję, która będzie wywoływana po każdym VBLANK zgodnym z częstotliwością odświeżania ekranu.
Ostatnia aktualizacja: 26.07.2019 15:23:50 przez MDW
Rysuję klatkę i chcę wysłać sobie time request żeby kolejne rysowanie było najszybciej jak się da ale nie wcześniej niż w kolejnym odświeżaniu ekranu. Chodzi mi o to żebym nie rysował ekranu częściej niż 60 razy na sekundę jeżeli ekran jest odświeżany 60 razy na sekundę, bo to nie ma sensu, szkoda męczyć wiatraka na procesorze.
To jest wszystko proste tylko muszę wiedzieć jak często jest odświeżany ekran żeby potrafić zmontować time request i dostać sygnał w kolejnej klatce (albo najszybciej jak się da jeżeli rysowanie klatki trwało dłużej niż jedno odświeżanie ekranu).
Zwykle gdzieś tam w innych API robiło się to tak, że po rysowaniu wywoływało się jakieś WaitVbl(). A np. API macOS podaje się wskaźnik na funkcję, która będzie wywoływana po każdym VBLANK zgodnym z częstotliwością odświeżania ekranu.
Ostatnia aktualizacja: 26.07.2019 15:23:50 przez MDW
26.07.2019 15:20
[#7]
Re: UNIT_VBLANK
@Krashan, post #4
W MorphOS-ie wszystkie unity timer.device są emulowane za pomocą UNIT_CPU (wewnętrzny timer procesora) i częstotliwość ticków UNIT_VBLANK ma się nijak do odświeżania obrazu.
Aaa widzisz. Dzięki za wyjaśnienie.
No to faktycznie nie można się na tym opierać. Zmyliła mnie trochę ta historyczna nazwa VBLANK. No ale to jest cena za kompatybilność wsteczną...
26.07.2019 15:31
[#8]
Re: UNIT_VBLANK
@Hexmage960, post #3
To nie jest tak, że UNIT_VBLANK czeka na ramkę, tylko odmierza czas w podanej dokładności. Do odmierzania ramek służy przerwanie VBlank.
Dzięki za wyjaśnienie. Mi nawet nie zależy na czekaniu na koniec ramki. Ja po prostu nie chcę przerysowywać ekranu częściej niż jest on odświeżany. A w jakim to jest momencie rysowania ramki to nie ma znaczenia.
Nie chcę też przyjmować żadnym sztywnych wartości typu max. 50 czy 60 FPS. Ma być maksymalnie tyle ile wyciąga obraz. Oczywiście wszystko jest uzależnione od deltaTime i będzie z taką samą prędkością działało na każdej maszynie. Najwyżej będzie 1 FPS czy 0.01 FPS...
Każdy element obrazu przesuwa się, obraca, skaluje, itp... o taką samą wartość w takiej samej jednostce czasu niezależanie od możliwości sprzętu. Różnica jest tylko w płynności. Dolnej granicy płynności nie ma - może być skok raz na godzinę czy dobę. Ale to jest raczej banalny temat, który ogarnąłem 20 lat temu. Ostatnia aktualizacja: 26.07.2019 15:33:00 przez MDW
26.07.2019 15:46
[#10]
Re: UNIT_VBLANK
@MDW, post #8
@MSchulz
Chciałem napisać w tamtej wypowiedzi "rozdzielczość", ale uznałem że bardziej naturalny będzie termin "dokładność" jeśli chodzi o czas.
@MDW
Proponuję koledze użyć UNIT_VBLANK jeśli nie zależy na częstotliwości, a zależy na małym narzucie, np. dla dużych okresów, zaś UNIT_MICROHZ, jeśli jednak są to niewielkie okresy. Ale należy liczyć się z tym, że UNIT_MICROHZ bardziej obciąży system.
Jeśli kolega będzie czekać na sygnał o długości np. kilku lub kilkunastu sekund wówczas słaba dokładność/rozdzielczość czasowa nie będzie stanowiła problemu.
Zaś do rysowania i odświeżania ekranu to UNIT_MICROHZ podejrzewam, że będzie stanowczo zbyt dokładny.
Ciekaw jestem na jakiej zasadzie działa ten UNIT_CPU, o którym wspomina kolega Krashan.
P.S. Pod systemem Amigi (exec.library) podobnie można zainstalować funkcję, która będzie wywoływana co każde wygaszanie pionowe. Mogą być różnice pod MorphOSem, nie mam w tej kwestii rozeznania.
Chciałem napisać w tamtej wypowiedzi "rozdzielczość", ale uznałem że bardziej naturalny będzie termin "dokładność" jeśli chodzi o czas.
@MDW
Proponuję koledze użyć UNIT_VBLANK jeśli nie zależy na częstotliwości, a zależy na małym narzucie, np. dla dużych okresów, zaś UNIT_MICROHZ, jeśli jednak są to niewielkie okresy. Ale należy liczyć się z tym, że UNIT_MICROHZ bardziej obciąży system.
Jeśli kolega będzie czekać na sygnał o długości np. kilku lub kilkunastu sekund wówczas słaba dokładność/rozdzielczość czasowa nie będzie stanowiła problemu.
Zaś do rysowania i odświeżania ekranu to UNIT_MICROHZ podejrzewam, że będzie stanowczo zbyt dokładny.
Ciekaw jestem na jakiej zasadzie działa ten UNIT_CPU, o którym wspomina kolega Krashan.
P.S. Pod systemem Amigi (exec.library) podobnie można zainstalować funkcję, która będzie wywoływana co każde wygaszanie pionowe. Mogą być różnice pod MorphOSem, nie mam w tej kwestii rozeznania.
26.07.2019 16:03
[#11]
Re: UNIT_VBLANK
@Hexmage960, post #10
Chciałem napisać w tamtej wypowiedzi "rozdzielczość", ale uznałem że bardziej naturalny będzie termin "dokładność" jeśli chodzi o czas.
Rozdzielczosc i dokladnosc to sa dwa rozne terminy. Zegar o duzej rozdzielczosci powala odmierzac bardzo male fragmenty czasu, przy czym nie wplywa to w zaden sposob na dokladnosc odmierzanego czasu. Moze na przyklad odmierzac interwaly mikrosekundowe ale jego dokladnosc jest mierzona w dziesiatkach albo setkach ppm.
Zegar dokladny czy tez o wysokiej precyzji pozwala odmierzyc bardzo dokladne fragmenty czasu, przy czym slowo "dokladny" nie okresla rozdzielczosci takiego zegara. Byc moze potrafi odmierzac np. interwaly jednosekundowe, ale za to z dokladnoscia rzedu 1E-6 ppm.
Ciekaw jestem na jakiej zasadzie działa ten UNIT_CPU, o którym wspomina kolega Krashan.
Procesory PowerPC maja na pokladzie wewnetrzny timer, taktowany zegarem szyny (ew. z wbudowanym na sztywno preskalerem) i 64-bitowy rejestr ktory jest inkrementowany z kazdym cyklem timera - time base register, TBU (gorne 32 bity) i TBL (dolne 32 bity). Dodatkowo, procesor posiada jeszcze rejestr DEC - decrementer, ktory jest zmniejszany o 1 z kazdym cyklem timera i generuje przerwanie kiedy najstarszy bit rejestru zmienia wartosc z 0 na 1, czyli kiedy rejestr DEC zmniejsza sie z 0x00000000 na 0xffffffff.
Za pomoca tych dwoch rejestrow mozna zrobic bardzo fajny UNIT_CPU. Rejestru DEC uzywasz jak "budzika" do wyzwolenia przerwania kiedy przyjdzie pora na obsluge kolejnego timerequest-a.
P.S. Pod systemem Amigi (exec.library) podobnie można zainstalować funkcję, która będzie wywoływana co każde wygaszanie pionowe. Mogą być różnice pod MorphOSem, nie mam w tej kwestii rozeznania.
Jezeli UNIT_VBLANK jest pod MorphOS-em emulowany, to zapewne przerwanie VERTB tez bedzie tylko emulowane.
26.07.2019 17:03
[#15]
Re: UNIT_VBLANK
@MDW, post #8
Ale żeście namieszali... Przecież timer.device nie służy do synchronizowania się z odświeżaniem ekranu, tylko do pomiarów czasu. Tak jak napisał mschulz, MorphOS korzysta z rejestru TimeBase procesora, który zlicza preskalowany zegar szyny, czyli jego stabilność jest taka jak zegara procesora. Jeżeli chodzi o rozdzielczość – częstotliwość "ticków" zwraca funkcja ReadCPUClock(), będąca analogiem starej ReadEClock(). Na różnych maszynach jest to najczęściej 25 albo 33 MHz. Jest ona znacznie lepsza od EClocka, nie mówiąc o VBlank, więc nic dziwnego, że wszystkie jednostki timer.device w MorphOS-ie bazują na TimeBase.
To, że na Amidze UNIT_VBLANK pozwalał na takie synchro, było efektem ubocznym.
To, że na Amidze UNIT_VBLANK pozwalał na takie synchro, było efektem ubocznym.
26.07.2019 17:26
[#16]
Re: UNIT_VBLANK
@Krashan, post #15
Ale zwrócona przez ReadCPUClock() wartość nie ma chyba nic wspólnego z częstotliwością odświeżania ekranu w wybranym trybie graficznym?
Nie sądziłem, że pobranie takiej wartości jest takim problemem. Zerknę jeszcze w źródła SDL, a potem po prostu ograniczę prędkość do 60 FPS i tyle. Najwyżej gdy ktoś będzie miał jakiś dziwny tryb o mniejszym odświeżaniu to będzie się częściej rysowało. A jak się znajdzie rozwiązanie to to zmienię.
Nie sądziłem, że pobranie takiej wartości jest takim problemem. Zerknę jeszcze w źródła SDL, a potem po prostu ograniczę prędkość do 60 FPS i tyle. Najwyżej gdy ktoś będzie miał jakiś dziwny tryb o mniejszym odświeżaniu to będzie się częściej rysowało.
A jak się znajdzie rozwiązanie to to zmienię. 26.07.2019 20:44
[#18]
Re: UNIT_VBLANK
@Krashan, post #15
Przecież timer.device nie służy do synchronizowania się z odświeżaniem ekranu, tylko do pomiarów czasu.
Ja na to zwróciłem uwagę w poście #3.
Napisałem tam, że rozdzielczość czasowa UNIT_VBLANK to jest własność, która decyduje o dokładności pomiaru czasu.
Więc nieważne czy VBLANK jest 50Hz czy 60Hz - timer.device powinien odczekać poprawnie minutę.
Z pomocą UNIT_MICROHZ można odczekać poprawnie np. 0,0001 sekundy. A to już mało przydatne w animacji ekranu, tylko w jakichś skomplikowanych obliczeniach, bo nie potrzeba w animacji takiej rozdzielczości czasowej.
Dodałem później w post-scriptum, że jeśli kolega MDW chce synchronizację jak w macOS, pozostaje serwer wygaszania pionowego, który jest obecny w klasycznym Amiga OS i zapewne też w MorphOS.
Amiga.lib (biblioteka linkowalna) zawiera funkcje do łatwego dodawania serwerów tego przerwania.
Podsumowując: do pomiaru czasu timer.device, zaś do synchronizacji animacji z ramką - exec.library lub amiga.lib.
Wydaje mi się, że kolega MDW potrzebuje trochę tego i trochę tego.
Problem polega tylko na tym, z jakiego odpowiednika rozwiązań z klasycznego systemu Amigi skorzystać pod MorphOS.To tak dla pełnej jasności chciałem dodać.
Ostatnia aktualizacja: 26.07.2019 20:52:22 przez Hexmage960
26.07.2019 20:55
[#19]
Re: UNIT_VBLANK
@Hexmage960, post #18
Dzięki za wyjaśnienie.
Chcę zwrócić uwagę na to, że ja nie chciałem nic za bardzo synchronizować tylko nie przerysowywać klatki częściej niż jest odświeżony obraz. Takie klasyczne WaitVbl() dostępne właściwie wszędzie.
No ale luz, jakoś sobie poradzę. Dzięki wszystkim za bardzo cenne uwagi.
Chcę zwrócić uwagę na to, że ja nie chciałem nic za bardzo synchronizować tylko nie przerysowywać klatki częściej niż jest odświeżony obraz. Takie klasyczne WaitVbl() dostępne właściwie wszędzie.
No ale luz, jakoś sobie poradzę. Dzięki wszystkim za bardzo cenne uwagi.
27.07.2019 12:55
[#22]
Re: UNIT_VBLANK
@pisklak, post #21
Mimo wszystko to trochę dziwne że na MOSie UNIT_VBLANK "nie tyka" razem z VBL - jak sama nazwa unitu wskazuje. Ale podejrzewam że po prostu dużo łatwiej jest zrobić taką emulację niż bebrać się z VBL dla każdej możliwej karty graficznej.
W AROS-ie tez nie tyka z vbl-em. Ale tez nie taki byl jego cel ;)
27.07.2019 12:59
[#23]
Re: UNIT_VBLANK
@pisklak, post #21
Mimo wszystko to trochę dziwne że na MOSie UNIT_VBLANK "nie tyka" razem z VBLNie widzę w tym nic dziwnego. Zauważ, że na klasyku żądania do urządzenia i tak podawałeś w sekundach, a nie w ramkach obrazu. System przeliczał te sekundy na ticki w zależności od tego jaki tryb graficzny był uruchomiony. A ponieważ timer może odliczyć tylko całkowitą ilość ticków, to interwał czasowy zmieniał się nieco w zależności od częstotliwości odchylania. Niezbyt pożądane zjawisko.
27.07.2019 13:21
[#24]
Re: UNIT_VBLANK
@Krashan, post #23
Czy ja wiem czy niepożdane. W końcu użytkownik chce dostawać "ticki" z definicji unita z częstotliwością VBLANK- jakakolwiek by nie była. Zakładanie przez programistę że to zawsze będzie 50 czy 60 Hz jest po prostu błędne (lepiej wtedy użyć po prostu innej jednostki i mieć na sztywno te 50 Hz).
27.07.2019 13:52
[#26]
Re: UNIT_VBLANK
@pisklak, post #24
Czy ja wiem czy niepożdane. W końcu użytkownik chce dostawać "ticki" z definicji unita z częstotliwością VBLANK- jakakolwiek by nie była.
Nie. Uzywajac UNIT_VBLANK programista nie chce dostawac ticka z czestotliwoscia VBLANK. Jezeli bylo by to wymagane powinien podpiac sie n.p. pod przerwanie VERTB albo korzystac z graphics.library zeby czekac na koniec ramki obrazu.
W przypadku timer.device jezeli chce korzystac z UNIT_VBLANK to znaczy ze chce odmierzac dosc dlugie interwaly czasowe (sekunda, dwie, dzieciec, godzina...) i korzystam z unita ktory ma co prawda kiepska rozdzielczosc (rzedu kilkudziesieciu milisekund) ale za to jest dosc stabilny. To, w ktorym momencie moj timerequest sie zakonczy jest w tym wypadku sprawa drugorzedna. Tym bardziej ze nazwa UNIT_VBLANK nie jest obietnica synchronizacji z przerwaniem synchronizacji pionowej, a tylko informacja o rozdzielczosci konkretnego urzadzenia (rozdzielczosc porownywalna z VBLANK, rozdzielczosc MICROHZ).
Uzywanie timer.device do robienia czegokolwiek w takcie z obrazem mija sie z celem nawet na klasyku - wystarczy do niego wlozyc karte graficzna. Zgadnij z jakim taktem pracuje VBLANK kiedy uzywasz np. trybu 640x480 @ 72Hz na karcie graficznej - bedzie to 72Hz z CGX-a czy moze 50/60Hz z przerwania VBLANK od chipsetu?
27.07.2019 17:28
[#27]
Re: UNIT_VBLANK
@mschulz, post #26
Jeśli cgfx/p96 patchuje UNIT_VBLANK zgodnie z ustawieniami trybu graficznego to będzie to te 72Hz. Zgadłem ? Wątpię 
O.K przyjmuje do wiadomości że ten unit bardziej służy do wskazania potrzebnej rozdzielczości zegara niż faktycznego odniesienia do VBlank, przynajmniej 'poza chipsetem' że się tak ogólnie wyrażę.
Ostatnia aktualizacja: 27.07.2019 17:36:29 przez pisklak
O.K przyjmuje do wiadomości że ten unit bardziej służy do wskazania potrzebnej rozdzielczości zegara niż faktycznego odniesienia do VBlank, przynajmniej 'poza chipsetem' że się tak ogólnie wyrażę.
Ostatnia aktualizacja: 27.07.2019 17:36:29 przez pisklak
27.07.2019 18:12
[#28]
Re: UNIT_VBLANK
@pisklak, post #27
UNIT_VBLANK ma dlatego tę nazwę, bo używa "zegara" VBlank zamiast np. CIA w Amidze. Dzięki temu ma też bardzo mały narzut, czyli nie obciąża za wiele systemu.
Powiązania VBLANK z kartą graficzną w Amidze, konkretnym tempem odświeżania ekranu są bardzo dalekie. Liczy się to, że komputer może liczyć czas na dwa sposoby - mniej lub bardziej obciążające system i posiadające mniejszą lub dokładniejszą precyzję.
Celem unita timer.device jest stworzyć wybór pomiędzy tymi dwoma sposobami.
Zastosowanie timer.device jednak nie ma związku z kartą graficzną, bądź synchronizacją animacji!
Timer.device może oczywiście czekać 1/50 sekundy. Co więcej - timer.device może wywoływać przerwania co 1/50 sekundy (korzystając z możliwości Portów komunikacyjnych Amigi). Ale po co - skoro takie przerwania udostępnia exec lub amiga.lib - i to one powinny być używane do synchronizacji.
Timer.device korzysta z VBlank bazującego jak było mówione najpewniej na przerwaniu VBlank, kiedy czeka przy użyciu UNIT_VBLANK. Ale służy do odmierzania czasu.
Żeby synchronizacja animacji była dobra, programista powinien zainstalować własny serwer obsługi tego przerwania, który będzie służył specjalnie do takiej synchronizacji. Wówczas otrzyma wiadomości precyzyjnie co jeden VBlank - i dlatego taka synchronizacja będzie dobra.
Amiga udostępnia jeszcze jedno narzędzie synchronizacji wideo/grafiki - jest nią Copper. Ale to temat na odrębny wątek.
Podsumowując - timer.device nie ma związku z grafiką, nie do takich zastosowań według mnie został przeznaczony.
Dla karty graficznej dobrą funkcją do synchronizacji jest ChangeScreenBuffer() z biblioteki graficznej. Otrzymuje się wtedy wiadomości, kiedy można rysować do bufora i kiedy można ten bufor wyświetlić.
Ostatnia aktualizacja: 27.07.2019 18:21:06 przez Hexmage960
Powiązania VBLANK z kartą graficzną w Amidze, konkretnym tempem odświeżania ekranu są bardzo dalekie. Liczy się to, że komputer może liczyć czas na dwa sposoby - mniej lub bardziej obciążające system i posiadające mniejszą lub dokładniejszą precyzję.
Celem unita timer.device jest stworzyć wybór pomiędzy tymi dwoma sposobami.
Zastosowanie timer.device jednak nie ma związku z kartą graficzną, bądź synchronizacją animacji!
Timer.device może oczywiście czekać 1/50 sekundy. Co więcej - timer.device może wywoływać przerwania co 1/50 sekundy (korzystając z możliwości Portów komunikacyjnych Amigi). Ale po co - skoro takie przerwania udostępnia exec lub amiga.lib - i to one powinny być używane do synchronizacji.
Timer.device korzysta z VBlank bazującego jak było mówione najpewniej na przerwaniu VBlank, kiedy czeka przy użyciu UNIT_VBLANK. Ale służy do odmierzania czasu.
Żeby synchronizacja animacji była dobra, programista powinien zainstalować własny serwer obsługi tego przerwania, który będzie służył specjalnie do takiej synchronizacji. Wówczas otrzyma wiadomości precyzyjnie co jeden VBlank - i dlatego taka synchronizacja będzie dobra.
Amiga udostępnia jeszcze jedno narzędzie synchronizacji wideo/grafiki - jest nią Copper. Ale to temat na odrębny wątek.
Podsumowując - timer.device nie ma związku z grafiką, nie do takich zastosowań według mnie został przeznaczony.
Dla karty graficznej dobrą funkcją do synchronizacji jest ChangeScreenBuffer() z biblioteki graficznej. Otrzymuje się wtedy wiadomości, kiedy można rysować do bufora i kiedy można ten bufor wyświetlić.
Ostatnia aktualizacja: 27.07.2019 18:21:06 przez Hexmage960
28.07.2019 15:27
[#29]
Re: UNIT_VBLANK
@Hexmage960, post #28
UNIT_VBLANK ma dlatego tę nazwę, bo używa "zegara" VBlank zamiast np. CIA w Amidze. Dzięki temu ma też bardzo mały narzut, czyli nie obciąża za wiele systemu.
To nie do konca prawda - UNIT_VBLANK uzywa strobe z zasilacza a jesli go nie ma, to eclock, tyle ze pomiar jest wykonywany na przerwaniu vertical blank timer.device, wiec ma minimalna rozdzielczosc rowna czasowi pomiedzy dwoma takimi przerwaniami.
Dla karty graficznej dobrą funkcją do synchronizacji jest ChangeScreenBuffer() z biblioteki graficznej. Otrzymuje się wtedy wiadomości, kiedy można rysować do bufora i kiedy można ten bufor wyświetlić.
ChangeScreenBuffer jest funkcja z intuition.library a nie z graphics.library i nie wysyla zadnej wiadomosci, po prostu przelacza bitmape podanego w parametrach wejsciowych screenu na inna, podana w parametrach.
28.07.2019 15:55
[#30]
Re: UNIT_VBLANK
@docent, post #29
To nie do konca prawda - UNIT_VBLANK uzywa strobe z zasilacza a jesli go nie ma, to eclock, tyle ze pomiar jest wykonywany na przerwaniu vertical blank timer.device, wiec ma minimalna rozdzielczosc rowna czasowi pomiedzy dwoma takimi przerwaniami.
O, to jest ciekawostka! Warto wspomniec ze strobe jest dostepne tylko w duzych amigach, A500/A1200 nie otrzymuje tego sygnalu z zasilacza. Z ciekawosci zajrzalem do schematow A2000 i faktycznie, jest! Sygnal TICK poprowadzony z zasilacza m.in. do jumpera J300 obok ukladu CIA. Za pomoca tego jumpera mozna wybrac zrodlo przerwan dla CIA-A, albo jest to wlasnie TICK (jumper na pozycji "normal"), albo VSYNC (jumper na pozycji "A500").
To tlumaczy dlaczego autodoc tak chwali dokladnosc UNIT_VBLANK. Czestotliwosc sieci jest dosc stabilna jezeli mierzony czas jest odpowiednio dlugi :)
Ostatnia aktualizacja: 28.07.2019 15:58:11 przez mschulz