@docent, post #29

• Odpowiedz

@mschulz, post #30

• Odpowiedz

@mschulz, post #32

• Odpowiedz

@docent, post #33

• Odpowiedz

@mschulz, post #34

• Odpowiedz

@Korni, post #20

Hm, przecież jak rysujesz openglem, to pod morphosem tinygl ma domyślnie ustawiony sync na 1 (env TGLSYNC). Softwarowo (glowo też) dać najlepiej opcję ustawiająca max FPS.

Słuszna uwaga. Faktycznie nie ma się co przejmować częstotliwością rysowania. Ale to tylko rysowanie. Całego liczenia, logiki też nie chcę aktualizować częściej niż jest rysowany ekran, bo to nie ma sensu. Dlatego zawsze to synchronizuję z częstotliwością odświeżania ekranu.

Ale spoko, poradzę sobie. Będzie dobrze.

• Odpowiedz

@MDW, post #36

Będzie pan zadowolony?

• Odpowiedz

@recedent, post #37

Taaa. Uznałem, że nie ma sensu z tym walczyć skoro w innych trybach niż PAL/NTSC VBLANK to nie jest VBLANK i zapis z dokumentacji to jest po prostu zaszłość historyczna.

• Odpowiedz

@MDW, post #38

Nie rozumiem z czym kolega miał problem.

Co chciał kolega wpisać do pól struktury timerequest?

Przecież podaje się tam czas w mikrosekundach i sekundach.

TimerIO->tr_node.io_Command = TR_ADDREQUEST;
TimerIO->tr_time.tv_secs  = 60;        /* Delay a minute */
TimerIO->tr_time.tv_micro = 500000;    /* and a half     */
DoIO(TimerIO);

Nie da się tam wpisać "czekaj jedną ramkę". Trzeba konkretnie podać np. 0,02 sekundy.

Nie używa się timer.device do czekania na ramkę. Z timer.device można ładnie zsynchronizować program z prawdziwym czasem niezależnym od prędkości komputera.

Rozumiem, że Amiga klasyczna posiada inne "liczniki" aniżeli sprzęt pod systemy NG. W Amidze klasycznej UNIT_VBLANK sprawdza czy upłynął żądany czas co ramkę.

Najnowszy RKRM jest poświęcony systemowi w wersji 2.04 więc nie dziwota że nie znalazły się tam informacje dot. nowszych wersji.

Dokumentacja programistyczna do systemów NG jest chyba niekompletna. Jak ktoś zadaje takie pytanie jak kolega, często nie dostaje jednoznacznej i szczegółowej odpowiedzi.

Do takiej synchronizacji ja ostatnio używam ChangeScreenBuffer() i jestem całkiem zadowolony. Nawet kolega Kiero z tego co się orientuję używa tej funkcji w swoich demach, które działają i na Amidze i na MorphOSie.

Z relacji wiem, że moja gra też jakoś sobie radzi na systemach NG w tym Amiga OS4 i MorphOS. A piszę ją na Amidze 1200 z AGA nie mając innych sprzętów do testowania.

Po prostu stosuję natywne API Amiga OS. Bardzo to zresztą lubię. Gdyby systemy NG rozszerzyły możliwości datatypów o odtwarzanie muzyki (np. poprzez moduły w formacie IFF SMUS) byłoby bardzo wygodnie adaptować gry.

Ostatnia aktualizacja: 29.07.2019 17:43:38 przez Hexmage960

• Odpowiedz

@Hexmage960, post #39

Co chciał kolega wpisać do pól struktury timerequest?
Przecież podaje się tam czas w mikrosekundach i sekundach.

Tak właśnie chciałem wpisać. Chciałem podać czas mikrosekundach jaki mija między jednym a drugim odświeżaniem ekranu. W czasach monitorów LCD to prawie zawsze jest 1/60 sekundy. Ale nie lubię ustawiania na stałe takich wartości. To ma być wartość pobrana z systemu, bo istnieje szansa, że ktoś będzie miał jednak inaczej. A nie chcę robić obliczeń (których mam sporo) częściej niż ekran jest wyświetlany. Ani też rzadziej żeby sztucznie nie "skakało".

Oczywiście mogę zrobić tak jak cały dzisiejszy świat "poważnego" gamedevu, czyli ustawić sobie jakąś maksymalną częstotliwość odświeżania i mieć w nosie wszystko co działa szybciej. Ale nie lubię takich prymitywnych rozwiązań. Zresztą w źródłach SDL też widzę podobne "lamerskie" rozwiązanie, jakieś stałe MAX_FPS=200 i MIN_FPS=1. Okropieństwo. Tak to sobie można robić w pracy, a nie w poważnym hobby.

Gdyby systemy NG rozszerzyły możliwości datatypów o odtwarzanie muzyki (np. poprzez moduły w formacie IFF SMUS) byłoby bardzo wygodnie adaptować gry.

A co, nie ma dźwiękowych datatypów? Ja w SYS:Devs/Datatypes mam np. Protracker i w SYS:Classes/Datatypes mam protracker.datatype. A w analogicznych katalogach MOSSYS: mam datatypy: 8SVX, 16SV, MP3, AIFF. Poza tym MorphOS znacznie rozszerzył możliwości w tym zakresie przez Raggae, które jest integralną częścią systemu.

Ostatnia aktualizacja: 02.08.2019 11:33:25 przez MDW

• Odpowiedz

@MDW, post #40

• Odpowiedz

@michal_zukowski, post #41

No właśnie, choćby nawet sam Ambient odgrywa różne dźwiękowe formaty. Chociaż akurat o DBM nie wiedziałem.

• Odpowiedz

@MDW, post #42

• Odpowiedz

@MDW, post #40

• Odpowiedz

@Hexmage960, post #44

Prawdę mówiąc nie chcę mieć unormowanego i wymyślonego czasu tylko taki jaki faktycznie jest w danym trybie graficznym. Jeżeli ktoś podłączy monitor CRT i tam na przykład użyje trybu z odświeżaniem 100Hz to bez sensu wszystko będzie przeliczane 60 razy na sekundę, a mogłoby 100 razy na sekundę. Wszystko ma działać w dowolnym deltaTime, także zmiennym. Na takich stałych to się robiło w czasach komputerów 8-bitowych. Oczywiście

Cały czas mówię o obliczeniach, nie wyświetlaniu/rysowaniu (które będzie robione tyle razy ile trzeba w danym trybie). Obliczenia to sprawa odrębna od rysowania ale jednak fajnie gdy każda rysowana klatka ma aktualne wartości, a jednocześnie te obliczenia nie wykonują się częściej niż jest przerysowywany ekran, bo szkoda grzać maszynę.

Ale spoko, już mam to ogarnięte. Dzięki poradzie na MorphZone mam częstotliwość odświeżania ekranu dla dowolnego wybranego ScreenModeID. Sposób nieco pokręcony ale okazuje się, że tak to się robiło w wielu programach, które potrzebowały tej wartości do jakiegoś celu.

• Odpowiedz