Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
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.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
TONY na małe Atari Nowa gra na małe Atari, w Hiresie, produkcja Rafała Dudka (brat XXL-a), Popmilo i Caruso.
Zaloguj się lub zarejestruj by napisać odpowiedź
Znalazłem w końcu coś, co łączy w sobie oryginalne układy wideo z wyjściem HDMI :)
Może już było, ale jak dla mnie bomba. NIe potrzeba żadnych zdechłych scandoublerów i innych przeróbek. Rozwiązanie proste i rewelacyjne w swojej prostocie.
https://github.com/c0pperdragon/LumaCod … ode-signal
https://github.com/hoglet67/RGBtoHDMI/wiki
https://youtu.be/prNM38bC1zM?si=xzBy1xyE8w2YbRMu
Pod koniec wygląda bardzo ciekawie, overscrean i jazda.
https://youtu.be/prNM38bC1zM?t=980
Dzięki RZóG-owi mam to w rękach od jakiegoś czasu. Obraz wygląda super, ale są niewielkie błędy w emulacji GTIA (bo FPGA na płytce "GTIA Digitizer" emuluje GTIA. Miałem pisać o tym wcześniej, ale nie miałem zgranych jeszcze filmów aby pokazać jak to wygląda. Postaram się nagrać video aby było można ocenić samemu, dodam tylko że samo RGB2HMI oparte na PiZero z wyjściem HDMI generuje idealny obraz, w dodatku pixel perfect i ultra smooth. Cały pomysł z LumaCode jest świetny. Mam w rękach kilka rozwiązań:
1) S-Video + RetroTink 2x
2) GBS-8200 + VBXE + GBS Control
3) OSSC + VBXE 1.x
4) RGB2HDMI + GTIADigitizer
W chwili obecnej mogę powiedzieć tyle że jeżeli autor rozwiązania poprawi emulację GTIA to będzie to najbardziej odpowiadające mi rozwiązanie.
pozostałe rozwiązania preferuję w następującej kolejności:
1) S-Video + RetroTink 2x
2) VBXE + OSSC
3) VBXE + GBS-8200 z GBS control
poniżej fotki zarówno płytki GTIA digitizer jak RGB2HDMI wraz z Pi-Zero:
Ciekawe jak w demach się to zachowuje gdzie jest scroll np. w takim Near
(https://www.pouet.net/prod.php?which=64930)
Near co prawda nie sprawdzałem, ale jeżeli chodzi o scrolling to wszystko jest ultra płynne. Są pewne problemy z grafiką Player-Missile, ale to są drobnostki do poprawienia, na pewno autor rozwiązania dostanie dokładny raport aby mógł poprawić co trzeba.
Zaprezentowałbym wyniki działania już dawno, ale na YT nie da się obecnie wrzucić tego materiały tak aby nie psuł on jakości, zapewne udostępnię pliki .mkv na pigwie abyście mogli sami ocenić jak to wygląda. W dodatku mój tani chiński grabber przy 50fps pozawala tylko na przesyłanie obrazu do komputera z kompresją MJPEG o też powoduje pewne pogorszenie jakości.
Jesteś pewien, że to jest 100% emulacja GTIA?
Z opisów niejako wynika, że to tylko encoder sygnału. Po co by było potrzebne prawdziwe GTIA?
Wrzucę filmy to sam zobaczysz (ew. wpadnij do mnie i sam się przekonaj). Dlaczego sądzę że to emulacja GTIA? Bo np. kolory które wychodzą z nałożenia się grafiki PMG na "playfield" (w bardzo konkretnych przypadkach) wychodzą inaczej niż w przypadku bezpośredniego wyjścia z GITA, albo pozycje obiektów PMG np. w przypadku pierwszej części "Revenge of Magnus" (sinus scroll w hi-res + tło na PMG w górnej połowie ekranu) potrafią być inne niż w przypadku wyjścia z GTIA... efekt jest taki że obraz gwiazdek w tle jest poprzesuwany albo wręcz pozycje obiektów drżą o jedną linię skaningową.
Sądzę że autorowi prościej było wykonać emulację GTIA niż bawić się z precyzyjnym dekodowaniem sygnału "COLOR" z czym jak widać problem ma również autor projektu GTIA2DVI.
C0pperdragon ma doświadczenie w te klocki, a świadczą o tym chociażby jego pozostałe projekty (chociażby pełna emulacja VIC-II z wyjściem RGB, etc.). Mam również VIC-II digitizer, ale przyznaję że jeszcze nie zdążyłem go przetestować.
Samego RGB2HDMI używałem również z innymi maszynami i byłem bardzo zadowolony z rezultatów, jak tylko zobaczyłem że
c0pperdragon wypuścił pierwsze wersje swoich digitizerów z "lumacode" to od razu postanowiłem to przetestować. Czekam jeszcze na TIA digitizer i na pewno nie omieszkam zamieścić tutaj swoich doświadczeń z tymże również.
Jeden myk jest fajny z tym lumacode, tak jak pisał autor używa on 2-bitów do opisania stanu wyjścia/linii transmisyjnej... a więc mamy 4 możliwe stany do zakodowania na jednym drucie, całość protokołu pomyślana jest tak że tworzy on sygnał zbliżony do analogowego sygnału video (jeden ze stanów ma poziom "sync", pozostałe 3 stany służą do enkodowania transmitowanych bitów luminancji i chrominancji... a to powoduje że jak taki sygnał lumacode podepniesz do czegoś dekodującego composite video to widać obraz, co prawda nie jest to odwzorowanie właściwe, ale możesz dzięki temu zobaczyć że "digitizer" działa, oto przykład wyjścia z digitizera podpięty do "RetroTink 2x":
ekran Atari BASIC:
intro do gry Ballblazer:
a tutaj przykładowy "atari control picture", wyjście z GTIA_digitizera podpięte do RGB2HDMI:
screen z dema "Equation of Time / Our 5oft", w odpalonym menu RGB2HDMI:
Ostatnio edytowany przez seban (2024-01-30 11:11:11)
Hmm... Ale w menu jest "video sampling" :) A może będzie można sobie wybrać wersję układu? Jakoś nie chce mi się wierzyć, że gniazdko na GTIA zrobił dla picu :D
Alex... przecież RGB2HDMI i jego "pokładowy" soft obsługuję masę maszyn, rozwiązań... to nie jest tylko do GTIA digitizera wersja. Tam ustawisz wszystko... i są profile dla wielu maszyn (np/ Amiga, Atari ST, Acorn, Amstrad) ... to naprawdę wspiera wiele maszyn. LumaCode jest jedną z opcji i pojawiła się niedawno (w sofcie w wersji BETA). GTIA jest potrzebna chociażby po to aby generować kolizje i video na standardowym wyjściu monitorowym. Moim zdaniem GTIA digitizer tylko sobie słucha tego co nadchodzi do GTIA i tego co generuje GTIA na wyjściach ANx, także słucha sobie magistrali danych aby pobrać informację o grafice PMG (kiedy ANTIC wystawia odpowiednie adresy) ... no ale skoro mi nie dowierzasz ... po prostu napisz do autora rozwiązania.
A co do tego że GTIA digitizer tylko słucha i że był już wcześniej problem z nazwijmy to "emulacja GTIA" zacytuję samego autora rozwiązania;
The board should work with all variants of the Atari 8-bit machines that have a CTIA/GTIA video chip. Boards shipped since 29.9.2023 have the firmware version 1.1 that fixes a display issue with the "Atari Control Picture" program. I know of no other program that did not work with the previous version already.
Należy tylko dodać że projekt GTIA digitizera nie jest otwarty (i nie wiem czy będzie) i na razie można go jedynie kupić na w sklepie Tindie u CopperDragon.
a co do:
I know of no other program that did not work with the previous version already
Jestem w trakcie formułowania opisu problemów które zauważyłem, więc liczę że autor dokona poprawek i będzie to rozwiązanie idealne :D
Ostatnio edytowany przez seban (2024-01-30 13:55:42)
Z ciekawostek - niejaki Rosjanin pod pseudonimem AleksEKB opracował swoje RGB2HDMI na potrzeby ZX Spectrum 128. Oparł je.... na RPI Pico. Ciekawe na ile to jest używalne z innymi maszynami
Dla znających cyrlicę:
https://boosty.to/alexekb/posts/f4d7d8a … ab5faf1da3
PS: mam nadzieję, że to nie za duży offtopic
@grzybson: ależ to żaden offtopic! dzięki za info!
Ja mogę dodać tylko że c0opperDragon zrobił również "ULA Digitizer", można go znaleźć również w jego sklepie Tindie. Nie podaję linków aby nie było że coś reklamuję i promuje, każdy możne znaleźć na własną rękę. Jeżeli chodzi o "ULAdigitizer" to nie testowałem tego i za mało znam się na ZX spectrum więc trudno mi się nawet na ten temat wypowiedzieć.
Ale nawiązując do tematu który poruszyłeś, to podobny projekt (w sensie użycia RPi Pico) o nazwie GTIA2DVI powstaje dla Atari: https://github.com/maaakit/GTIA2DVI. Człowiek o pseudonimie "markit" zaprezentował go na AoL w tym wątku: GTIA2DVI.
Ja się bardzo cieszę że jest tyle możliwości do wyboru i w dodatku że MarkIt zrobił ten projekt w pełni otwarty! (Open Hardware/Software). Takich projektów nam potrzeba na scenie! :)
@seban - Ja wiem, że RGB2HDMI jest uniwersalne na wiele urządzeń. Po prostu się zastanawiam :) A samo rozwiązanie jest dostępne tutaj - https://github.com/c0pperdragon/D-Video (schematy, płytki, wsady)
Wygląda jakby to był piewotny projekt. Tak czy inaczej chętnie wpadnę zobaczyć :)
Ostatnio edytowany przez alex (2024-01-30 17:11:45)
@seban czytam AOL, tamten projekt wygląda obiecująco, przynajmniej w kategorii "low-cost" :)
Moim skromnym zdaniem projekt a właściwie idea jest z D***.
Wprowadza jakiś nowy dziwny chory standard, zamiast generować coś normalnego, np RGB. Przecież wszystkie dane i tak ma ..., chyba ze ten 2 bitowy sygnał to jest "regenerowane" CHROMA co i tak nie ma większego sensu.
Ps. Przypomniało mi się ze kiedyś (dokładnie 10 lat temu) popracowałem trochę nad podobnym projektem ale wtedy nie było to jeszcze modne.
http://www.atari.org.pl/forum/viewtopic.php?id=10892
@willy ... dla mnie wprost przeciwnie. Idea pomysłu (lumacode) jest taka że taki sygnał połączasz sobie zamiast sygnału RF z modulatora i nie wiercąc żadnej dziury w obudowie masz z danej maszyny wyprowadzony sygnał który potem podpinasz sobie jednym kablem ze złączem RCA do RGB2HDMI. Montaż w komputerze też może obyć się bez lutowania (o ile masz podstawkę pod GTIA). Tylko tyle i aż tyle. Dla mnie pomysł zacny i zamierzam niektóre swoje maszyny (GTIA/TIA/VIC-II/ULA) przerobić tak aby zamiast RF miały lumacode. Jednym HDMI2RGB obskoczę wszystko w dodatku dzięki profilom w RGB2HDMI mogę mieć pixel perfect odwzorowanie obrazy z tych maszyn na dowolnym monitorze czy TV z HMDI. Ustawione raz w taki sposób jaki mi odpowiada.
Ale zgadzam się... każdy może mieć swoją opinię o tym projekcie. Ja zaprezentowałem swoją, dość entuzjastyczną ale przedstawiłem też pewne niedociągnięcia i wady o których napisałem wyżej, mimo wszystko cieszę że ten projekt powstał i mogę sobie wybierać z wielu rozwiązań dostępnych obecnie dla różnych maszyn. Jeżeli preferujesz inne rozwiązania to ja doskonale to rozumiem i w żaden sposób nie zabraniam korzystania z nich.
LumaCode nie jest żadnym regenerowanym chroma... możesz porównać to do kodowania np. sygnałów LUMA i CHROMA za pomocą 2-bitowych sekwencji [chroma, luma, luma], to wszystko po to aby cały ten sygnał w formie cyfrowej transmitować jedno-przewodową linię transmisyjną. Wszystko to wyjaśniono na stronie projektu (github): GTIAdigitizer (for Atari 8bit).
cytat z powyższego linku:
Details on color encoding:
The Atari 8-bit computers can generate at total 256 colors: 16 hues, each of which can be shown in one of 16 luminosities. This would require a total of 8 bits of information needed for every pixel. But because of the way the colors are generated by the Atari internally, every two consecutive pixels share the same hue. So only a total of 12 bit is needed for every pair of pixels. These 12 bit will be encoded in the LumaCode signal with 6 samples (each transferring 2 bits). Grouping always two samples together (high bits first) to form a 4-bit number, three such numbers encode the data for a pixel pair in the following order: HUE, LUM1, LUM2.
Ostatnio edytowany przez seban (2024-01-30 17:53:42)
@seban Przeglądałem stronę projektu ze 3 razy i przeoczyłem ten akapit.
Nie pozostaje mi nic innego jak przeprosić i przyznać racje.
Faktycznie bardzo dobry pomysł.
@willy: spoko nic się przecież nie stało! nie ma za co przepraszać! Przecież spokojnie sobie wymieniamy poglądy i dyskutujemy. Mi też chwilę zajęło zanim zrozumiałem po co i dlaczego c0pperDragon wymyślił sobie owe "lumacode", jak już załapałem i wiedziałem jaki obraz potrafi generować RGB2HDMI to nie mogłem się doczekać aż zobaczę to na własne oczy. Na szczęście RZóG-owi udało się to kupić gdy tylko się pojawiło w sklepie i miałem możliwość przetestowania tego rozwiązania.
A co do Twojego rozwiązania, faktycznie teraz pamiętam jak o tym pisałeś... ale przyznam szczerze, wtedy sądziłem że używając FIQ będzie ciężko to samplować precyzyjnie beż żadnego dodatkowego sprzętowego FIFO... chyba koniec końców doszedłeś do podobnych wniosków i porzuciłeś projekt?
W przypadku RGB2HDMI mają dodatkowe CPLD które umożliwia samplowanie z rozdzielczością chyba coś około 10ns. Nie dokopałem się chyba nigdy (nie miałem potrzeby) jak dalej przenoszą ten sygnał, ale gdzieś coś mi mignęło w użwają do tego celu GPU z maliny... nie wiem tylko jak, ew. źle zrozumiałem co co kiedyś przeczytałem i mogę bredzić :)
@alex: ale wiesz że link do repo który zapodałeś to tylko taki dev-board z MAX10 (od Altera/Intel) + transceiver HDMI i nic poza tym? tam nie nic poza upscalerem na FPGA, to jest platforma testowa na której c0pperdragon sobie robił development i test dla danej platformy. Albo jestem ślepy albo nie widzę nic poza tym co zostało napisane w readme: D-Video board - Read Me. Reasumując nie ma tam żadnego kodu HDL-owego który by cokolwiek czytał z GTIA czy magistrali danych JIL. Ale może jestem ślepy i nie widzę?
@seban - Nie wiem, bo tylko pobieżnie przejrzałem repozytorium, ale napewno jest to podstawa obecnego rozwiązania :) Tak czy inaczej, dla mnie super! Martwi mnie tylko ta emulacja GTIA. Jak wiemy po SOPHII czasem są pewne ograniczenia takiego rozwiązania. Ja w każdym razie czekam na postępy :)
Ostatnio edytowany przez alex (2024-01-30 20:03:28)
@seban Mniejwiecej tak było.
FIQ są wystarczająco szybkie i bez problemu da się samplować naprawdę szybko. Problemem było to ze układ graficzny odłączał procesor od szyny na czas dostępu do pamięci. Wyłączając ekran nie gubiłem ani jednego bitu. 3,5MHz to w sumie niewiele. Po kilku próbach jakoś nie chciało mi się tego ciągnąc. Moze dało by się to np przez DMA zrobić lub jakoś inaczej angażując hardware typu SPI. Rozważałem tez zastosowanie rejestru z szeregowym wejściem i równoległym wyjściem (jakby nie patrzeć to jest FIFO) i jeszcze kilka innych pomysłów. Sporo się wtedy nauczyłem o architekturze ARM, wszystko pisałem w asemblerze.
Super sprawa, ale powiedzcie mi, czy można gdzieś kupić Analog RGB2HDMI? Pytałem kiedyś Zaxona to mi napisał, że nie ma układów, sam chciałem złożyć i faktycznie był problem.
Więc pytanie podstawowe czy można kupić gdzieś gotowca LumaCode GTIA-digitizer + RGB to HDMI ?
@lopez - Na przykład tutaj - https://www.tindie.com/products/c0pperd … digitizer/
Hej!
Chwilę mi to zajęło aby to dobrze zgrać, ale się udało. Z tym że aby to obejrzeć w płynności są wymagane pewne wymagania, których pewnie nie spałełni większa część forumowiczów. Skracając i upraszczając wszystko:
1) Poniższe filmy nagrane są z częstotliwością 49.86Hz (dokładnie taką jaką generuje Atari 8-bit)
2) Aby uzyskać w 100% płynne odtwarzanie trzeba mieć monitor refresh rate ustawiony na 50Hz (lub mieć monitor z freesync i player który to ogarnie)
3) pliki są umieszczone w kontenerze .MKV w środku kontenera video w formacie h.264
4) niektóre pliki mają na początku zniekształcone audio, spowodowane jest to faktem iż zapomniałem wyłączyć AGC (ARW) w graberze i ten starał się wyciągnąć coś z ciszy która panowała przy wczytywaniu/dekompresji niektórych produkcji (nie chciało mi się tego ponownie zgrywać)
do pobrania:
"boldem" zaznaczyłem te produkcje w których występują wizualne artefakty.
a) Out 5oft - Unity Part - błędne kolory przy nałożeniu się PMG na grafikę w trybie GTIA
b) Revenge of Magnus - tło z grafiki PMG nad wszystkim sinus scroll w Hi-Res, ale jak widać na załączonym filmie grafika PMG drży (zły timing przy zmienianiu X-POS obiektów PMG)
c) Visdom II demo - w przypadku efektu przesuwających się prostokątów w trybach 9/10 widać że w trybie 10 brak przesunięcia o cykl koloru pomiędzy trybem 9/10.
Zapewne będzie problem z trymami HIP/TIP/RIP (nie sprawdzałem tego jeszcze). Ale sądzę że autor rozwiązania poprawi to. Muszę tylko jeszcze zgrać referencyjne materiały z użyciem RetroTink 2x z wyjścia normalnego GTIA.
ps) pliki leżą na pigwie, na YT nie da się tego wrzucić tak aby YT nie zrobił z tego sieczki (YT robi konwersję/rekompresję materiału przy wrzucaniu materiałów na ich serwery). Wszystkie te pliki zajmują około ~1GB, mogą się pojawić jakieś artefakty kompresji h.264, ale starałem się aby bitrate materiału był dość wysoki.
Ostatnio edytowany przez seban (2024-02-11 20:00:06)
Jak przeskalujesz na FullHD i zakodujesz H.265 to YT nie powinien za wiele mieszać. Jeśli używasz OBS i masz w miarę współczesną kartę nVidii to polecam sprzętowy kodek H.265 oferowany przez karty serii GTX i RTX.
Hej!
Co to YT, to w chwili obecnej FullHD (1920x1080p) to za mało aby YT zechciał Ci wygenerować potem 50fps stream. Obecnie minimalny rozmiar obrazu aby YT zechciał umieścić strumień 50/60fps to 2048x1152, ale to najmniejszy problem. YT i tak zrobi sieczkę przy enkodowaniu takiego strumienia... będzie z 49.86Hz robił sobie 50Hz (wiem po sprawdziłem wrzucając i ściągając potem testowy materiał) co spowoduje co jakiś czas wnerwiające "szarpnięcia" na scrollach i wszystkich efektach które mają 50fps, ale to też jest do obejścia, bo mogę z tego strumienia 49.86Hz zrobić strumień 50Hz z "przesuniętym w widmie" strumieniem audio tak aby nie zmieniła się częstotliwość dźwięku przy przyspieszonej ścieżce video (49.86Hz --> 50Hz) ... niestety tutaj pojawiają się kolejne problemy... większość ludzi ma monitory które nie potrafią 50Hz a przynajmniej nie potrafią pod Windows.
YT robi wszystko aby wyświetlić strumień 60fps, a nawet jak wyświetli 50fps przy odświeżaniu monitora 60Hz czy więcej to nie muszę mówić jak to tragicznie wygląda (wstawionych 10 dodatkowych interpolowanych/powtórzonych klatek). W dodatku tak namieszali przy swoich playerach (np. chromecast), że teraz za nic chce przełączyć się na 50Hz gdy taki strumień jest dostępny. Do niedawna mój chromecast podpięty do TV przy odtwarzaniu streamu @50fps przełączał się taki tryb wyświetlania o czym TV mnie informował, od jakiegoś czasu (po aktualizacjach) chromecast trzyma 60fps jaki strumień nie byłby odtwarzany, no kicha totalna. Wszystkie dema wrzucone na YT @50fps po prostu szarpią i wyglądają teraz źle ;/
Mogę oczywiście przygotować strumienie przyspieszone do 60fps z przesuniętym w widmie dźwiękiem, ale po co? Szkoda waszego i mojego czasu chyba na taką zabawę. Te materiały które udostępniłem mają na celu pokazanie jakości jaką generuje tandem GTIADigitizer+RGB2HDMI, a to można ocenić sobie oglądając pliki .MKV które zamieściłem (nawet pojedyncze klatki) ... obraz jest po prostu pixel perfect, a RGB2HDMI podpięte do monitora czy TV który umie 50Hz generuje obraz idealnie płynny i nie przeszkadza mu to że jest to video 49.86Hz, sync jest idealny.
Teraz co do reszty zagadnień które poruszyłeś; OBS nie mogę używać ponieważ nie daje mi on pełnej kontroli nad moim graberem, więcej kontroli nad procesem zgrywania materiału mogę osiągnąć używając ffmpeg niż używając OBS i jego GUI. OBS mimo tego że miał ustawione aby nie ruszał frame-rate materiału wejściowego i tak koniec końców robił 50fps z okazyjnymi szarpnięciami w scrollach.
Co do kodeków to dla YT nie ma znaczenia w jakiej formie mu wrzucę materiał, testowo kodowałem nawet materiał w ultra jakości używając kodeka AV1 ale YT uznawał że jestem zbyt małym "pikusiem" (nawet linków nie mogę obecnie umieszczać w opisach na pod materiałami na YT które wrzucam) i koniec końców zostawał mi przydzielony tylko i wyłącznie stream kodowany kodekiem VP9. Tylko duże i popularne kanały dostają streamy AV1.
Mam jakąś starą kartę NV (Quadro P600) na której nvenc potrafi niby generować stream H265, ale ogólnie unikam produktów tejże firmy, więc karta jest obecnie "on the shelf". To co mam w kompie obecnie potrafi sprzętowo robić H265 i AV1, ale jak pisałem wyżej na YT nie ma to znaczenia... on i tak robi re-encoding wszystkiego co mu wrzucasz, wpływu na to co zrobi z Twojego materiału masz niewiele. Zresztą jest masa różnych materiałów i analiz tego jak należy przygotować materiał video dla YT aby ten był "łaskawy" przy enkodowaniu Twojego video... ale to są problemy którymi zajmują się o wiele więksi i poważniejsi ludzie niż ja, ja jestem tylko amatorem w tej dziedzinie i mogę się jedynie "pobawić" nieco aby zgłębić temat i przetestować rozwiązania które mi się w głowie uroiły :)
I parę słów na koniec abym nie został źle zrozumiany... ten mój cały wywód nie ma na celu mądrzenia się, albo negowania Twoich rad... ja po prostu opisałem swoje doświadczenia przy walce z kodowaniem rozsądnej jakości materiałów video pochodzących z naszej 8-bit maszyny... o ile te materiały da się jakoś sensownie "grabować" to niestety 50fps zarówno dla samego YT jak i dla większości sprzętu u ludzi jest problemem... a płynność generowanego obrazu (wszystkie efekty wyciągające 50fps oraz scrolle) i czas odpowiedzi monitorów kineskopowych jest obecnie problemem dla nowoczesnego sprzętu. Nawet jak mi się udaje wyświetlić stream 49.86Hz na monitorze z freesync to powiem Ci że matryce LCD mogą się schować (przynajmniej te w monitorach którymi dysponuje) w porównaniu z CRT. Nie testowałem jeszcze żadnego OLED-a, być może tam jest lepiej... ale na razie nie mam w planach takich wydatków. Technologia LCD jest jaka jest... dużo jej brakuje do ideału jeżeli chodzi o czasy reakcji matryc. Natomiast jeżeli chodzi o geometrię i jakość wyświetlanego obrazu tutaj nie mam zastrzeżeń :D
Reasumując, fajnie że chciało Ci się napisać parę słów o Twoich doświadczeniach z YT, bo to spowodowało że w sumie zainspirowałeś mnie do opisania swoich doświadczeń z YT. Kiedyś chciałem zgrywać wszystkie demka z JIL w bardzo dobrej jakości i wrzucić je na YT, jednak YT nie lubi takich materiałów ... ową mistyczną "płynność" YT ma głęboko w poważaniu i z aktualizacji na aktualizację jest coraz gorzej. Kiedyś wrzuciłem 50fps video paru dem ze stajni "Slight" (to były czasy gdy popularne było windows7) ... miałem wtedy monitor LCD który podpięty przez HDMI do komputera pozwalał na ustawienie odświeżania na 50Hz... wtedy materiały 50fps odtwarzane przez YT via przeglądarka wyglądały płynnie, dziś ten sam materiał odtwarzany na monitorze z ustawionym 50Hz nie odtwarza się tak płynnie jak kiedyś (widać przycięcia). Co YT popsuł? nie wiem. Wiem że sprzęt coraz lepszy, monitory coraz lepsze a software coraz gorszy :D
Ostatnio edytowany przez seban (2024-02-12 16:04:51)
Obecnie minimalny rozmiar obrazu aby YT zechciał umieścić strumień 50/60fps to 2048x1152,
Hm, ja oglądam zapisy streamów ze Starcrafta i tam jest 1080p @ 60 fps. Może kodek tu ma znaczenie?
Przykładowy screen, a także ten sam ze statystykami filmu.
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.099 sekund, wykonano 14 zapytań ]