Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Tydzień na oddanie głosu w FUJICUP! Głosowanie potrwa tylko do 22 lutego 2025...
TURGEN 9.3.1 Najnowsza wersja oprogramowania TURGEN wprowadza kilka istotnych ulepszeń.
FujiCup 2024 - głosowanie Wystartowało głosowanie w tegorocznej edycji konkursu FujiCup.
IX. Basque Tournament of Atari 2600 31 stycznia Euskal Retro Association zorganizowało IX. Baskijski Turniej Atari 2600.
Rogul 1.0f Poprawki i nowe funkcje
atari.area forum » Posty przez Marek Konopka
Zapytam kierowcę. :>
Jeżeli dostarczysz mi poprawny plik .JED ściągnięty z GAL'a, to jestem w stanie porównać oba i wyciągnąć jakiś wniosek.
Spróbuj GALBlast'em. Dokonuje on weryfikacji sumy kontrolnej. http://www.geocities.com/mwinterhoff/galblast.htm
Polecam napisanie do tych celów krótkiego programu. Implementacja nie powinna nastręczać problemów. Algorytm byłby dwuetapowy i polegałby na przeglądaniu wierszy raz w poziomie, drugi raz w pionie.
Pomysł b. dobry, ale optowałbym wyłącznie za 3,5'' wariantem, ze względu na rozmiary.
zrodelko od Garrego
Not Found.
No właśnie cała zabawa w tym iż możesz poinformować monitor/TV który aktualnie półobraz leci. Typ półobrazu (parzysty lub nieparzysty) monitor czy TV określa sobie na podstawie imp. synchronizacji pionowej w którym znajdują się informacje o typie aktualnie nadawanego półorazu.
Ok, to w takim razie trochę zamieszałem. Przepraszam za to.
Jeżeli jest tak, jak piszesz, to ten nowy tryb interlace będzie nieprzydatny w uzyskiwaniu nowych trybów programowych z udziałem GR9, GR10. Możnaby za to uzyskać płynniejszy scrolling obrazu w pionie.
Przy wyświetlaniu obrazu z przeplotem obrazów statycznych nie uzyskujemy żadnych efektów ubocznych ...
Obraz bardziej migocze. Dana linia obrazu jest rzadziej pobudzana.
Zastanawia mnie jednak to, czy czasem Atari nie zmienia częstotliwości wyświetlania obrazów, stosując taki myk i jak to ma się to do stabilnego wyświetlania obrazu na różnych odbiornikach telewizycjnych.
zawartość również jest taka sama chyba że robisz softwarowy interlace, czyli co ramkę zmieniasz zawartość wyświetlaną na ekranie.
Mieszanie znaczy się, nie interlace? Interlace to formalnie wybieranie międzyliniowe...
Jednak zawsze jest ona wyświetlana w tych samych liniach skaningowych monitora. Rybags dokłada dodatkowe imp. synchronizujące tak że układ ich detekcji w monitorze czy karcie TV interpretuje to jako klatki np. nieparzyste (zakładam iż domyślnie GTIA oznacza klatki jako parzyste).
Fragmenty książki, które zacytowałem zasugerowały mi, że typu kolejnego półobrazu nie można zmieniać swobodnie. Być może jestem w błędzie.
Pogrzebę jeszcze głębiej w literaturze...
Z tego co zrozumiałem to chciałeś powiedzieć iż zawsze lecą klatki naprzemiennie jedne niżej, drugie wyżej... a tak nie jest w przypadku standardowego obrazu generowanego przez ATARI czy nawet C64.
Czyli Atari/C64 standardowo generuje na sekundę 50 półobrazów o różnej zawartości, ale każdą "stempluje" jako nieparzystą (bądź parzystą), skutkiem czego są one WSZYSTKIE (50) wyświetlane zawsze w tym samym miejscu (w pionie)?
Jeżelibyśmy "szturchnęli" w schemacie opisanym przeze mnie w powyższym wpisie obraz w klatce parzystej o połowę wysokości lini skaningowej, to uzyskalibyśmy właśnie rozdzielczość "rozłącznych" 480 lini w pionie. Oczywiście, w pojedynczym półobrazie nadal rysowalibyśmy połowę liń (240), co drugą linię, ale w kolejnym półobrazie te luki zostałyby wypełnione. Być może właśnie to robi Rybags. Tylko tutaj powstałoby pytanie. Dlaczego standardowy obraz w TV nie jest tak wyświetlany?
Istotna uwaga do dyskusji w tym wątku...
Zajrzałem do książki "Telewizja - Poradnik" autorstwa Otto Limanna oraz Horsta Pelki.
Otóż, klatki nieparzyste (chwilowo określając je jako (i mod 2) == 0) są wyświetlane od początku lini (od lewej krawędzi), ale klatki parzyste ((i mod 2) == 1) za to od centrum poziomej linii. Biorąc pod uwagę fakt, że cewki odchylania pionowego nie przytrzymują napięcia na okres kreślenia poziomej linii tylko stale przesuwają wiązkę elektronów w doł, to początkowa pozycja w pionie wcale nie jest taka sama jak w klatce nieparzystej, tylko leży dokładnie w połowie trasy promienia pokonującego linię poziomą. Linia "pozioma" de facto nie jest linią poziomą na ekranie, a lekko pochylającą się w dół, patrząc od lewej strony.
eru nie miał racji pisząc, że Atari wyświetla obraz o linię niżej w klatkach parzystych, ale także nie miał racji Fox pisząc, że Atari wyświetla dwie klatki kolejne w tym samym miejscu. Ja również nie miałem świadomości tego faktu.
To przesunięcie o 1/2 lini skaningowej jest naturalną konsekwencją procesu wyświetlania obrazu w TV.
Tryby typu HIP działają zapewne dlatego, że odpowiadające sobie linie w dwóch kolejnych klatkach obrazu posiadają część wspólną (~0,5 lini skaningowej, a może i więcej). W takim wariancie mamy pustą przestrzeń (połowa lini skaningowej), jeżeli założymy że wysokość promienia rozciąga się na grubość jednej lini skaninowej, co wcale tak być nie musi.
Powstaje zatem pytanie - co uzyskał Rybags tak na prawdę?
chodzi Tobie o moment kiedy program nie wyrabia w jednej ramce?
Tego nie jestem w stanie wychwycić. Wydaje mi się jednak, że nie i jest to spowodowane złym pozycjonowaniem sprite'ów (HPOS), jakimiś drobnymi błędami. Wygląda to tak, jakby podzielony w linii sprite fizyczny był źle przyporządkowywany - nie do tego sprite'a logicznego, co trzeba. Skutek tego jest taki, że mając dwa sprite'y obok siebie ten drugi przejmuje w jednej linii wzór tego z prawej.
jesli tak to czy te "smieci" zachowuja sie podobnie jak na emulaotrze?
Tak, te śmieci wyglądają podobnie, z tym, że na real hardware są przesunięte odrobinę na prawo (sprite'a) - są przy jego prawej krawędzi. Na emulatorze występują centrycznie.
hmm.., bardziej chce miec pewnosc, ze przerwania DLI wyrabiaja sie w lini zanim zaczne cokolwiek dalej z tym multiplexerem robic...
Mam pewną sugestię co do możliwości uzyskiwania wielu wielo-kolorowych sprite'ów, ale z multipleksingiem nie ma to wiele wspólnego. Być może warto pociągnąć ten temat w innym miejscu.
Dzięki za odpowiedzi - jeżeli dobrze rozumiem, jeżeli podepnę się pod przerwanie VBL i rozpocznę od zmiany koloru $D01A, to mogę co 16 pixeli zmieniać kolor tła, czyli teoretycznie 3200 razy ???
Lepiej takie rzeczy robić na DLI, a nie na VBL. Z tego co pamiętam VBL ma ograniczenie na długość wykonywania i wcale nie jest to limit związany z częstotliwością odświeżania ekranu tylko krótszy. Po tym czasie następuje bum. Zmiany możesz wykonywać nawet co 12 pikseli GR 15.
//EDIT: chodzi mi o to, czy mogę użyć w miarę sensownego podkolorowania fontów, a na dodatek mieć jeszcze czas na obsługę sprite'ów...
Sprite'y dodatkowo kradną cykle CPU w każdej lini, bodajże po cyklu/sprite. Nie pamiętam dokładnie w którym miejscu to zachodzi, ale weź to również pod uwagę.
Ten program w ogóle nie odpala, ani pod emulatorem ani na real hardware.
EDIT. Jest już ok. Coś kiepsko ssało z serwera i używałem częściowo ściągniętego pliku.
Sprite'y migają momentami, coś na kształt interlace'u można na nich zaobserwować. Czasami pokazują się jakieś drobne śmieci w ich górnej części, ale nie wiem czy to jest kwestia faz animacji, czy jakiegoś innego problemu.
Btw. Sprawdzasz, czy wyrabia sortowanie?
jeden cykl procesora (to o ile dobrze pamietam) jeden pixel w gr.15.
Dwa.
ale dekoder pal nie czeka na kolejna klatke polobrazu zeby dekodowac sygnal chrominacji i uzywa do tego po prostu kolejnej linii jaka przyjdzie, wiec mieszanie gr9/11 niewiele raczej wniesie
Chwilowo pominąłem sygnał chrominancji. Założyłem, że barwy są ustawione na stałe.
W alternatywnym podejściu można uzyskać zwiększoną rozdzielczość luminancji oraz pomniejszoną chrominancji.
O coś takiego mi chodziło. Przepraszam za jakość.
Alternatywnie można rozważyć wyświetlanie co drugą linię w danej klatce. W takim wariancie tracimy część luminancji obrazu (1/4 lini będzie pusta).
Konop: Rozumiem, że chodziło o klatkę parzystą i nieparzystą.
Tak.
W zamyśle chodziło o wyświetlanie w klatce parzystej GR9, linia za linią (atarowską), oraz GR10 w nieparzystej. Takie połączenie przesunięć "podpikslowych" w obu wymiarach.
E1a i E1b to dwie sąsiadujące linie fizyczne na ekranie monitora, a H1a i H1b to 1 linia HIPa, którą interejsujemy GR9/10. Niestety, pokazać jesteśmy w stanie tylko 1 linię z nich na pół obraz, zatem nie możemy za bardzo tutaj coś poprawić. Ofkorz, przy pełnej kontroli, można by teraz skrolować HIP o pół linii Atari, ale nie zwiększymy chyba rozdziałk interlejsem pionowych, bo już i tak mruga.
Chyba, że zrobimy cross'a - w klatce parzystej GR9, bez przesunięcia cząstkowego w pionie, a w parzystej GR10 z przesunięciem cząstkowym.
Dzięki za zorganizowanie fajnej imprezy. Szkoda, że zdrowie nie pozwoliło na dłuższy pobyt.
Sprobowalem i z floatami i z offsetem do zz i nadal to samo:
(obrot kola wokol osi y)
http://img35.imageshack.us/img35/7440/wekt.png
Jeżeli pod pojęciem rozjeżdzania masz na myśli rosnące przerwy między punktami wzdłuż osi X, to wszystko jest w porządku. To skutek zaaplikowania perspektywy.
Ustaw offset z'ta na 150, a k na 554. Perspektywa będzie mniej "agresywna".
1) Funkcje sin(), cos() przyjmują argumenty w radianach. Przyrosty kątowe 0.3 mogą być zbyt duże i dawać wrażenie chaotyczności.
2) Wsp. k powinien być pochodną rozmiarów okna obrazu oraz perspektywy. Tymczasowo powinieneś go zwiększyć.
3) Będą działy się różne paskudne rzeczy, jeżeli nie wykluczysz dzielenia przez 0, które jak najbardziej jest możliwe w tej sytuacji. Proponuję dodać odpowiednio duży offset do zz.
Transport już jest załatwiony. Dzięki za zainteresowanie.
Ktoś będzie jechał przez Katowice/Sosnowiec? Chętnie bym się zabrał.
Z zasilaczem miałem to samo. Szczęśliwie dało się to naprawić - zwykłe zmęczenie materiału tuż przed wejściem do zasilacza.
Moje doświadczenie mówi, że dyski HD nie nadają się do CA2001 (pewnie innych modeli również). Chyba kiedyś tutaj lub na Atariki wspomniano o merytorycznej przyczynie takiego stanu rzeczy.
atari.area forum » Posty przez Marek Konopka
Wygenerowano w 0.014 sekund, wykonano 56 zapytań
