atarionline.pl RSHIMC - czy możliwa taka mieszanka? - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1:
       
      CommentAuthorsikor
    • CommentTime8 Aug 2009
     
    Założyłem identyczny wątek na atariarea, ale ponieważ część zagląda tam, a część tu (a część i tam i tu), powtórzę, bo temat mnie nurtuje:
    Tak mnie to zaczęło z czysto-teoretycznego punktu widzenia zastanawiać... Rybags odkrył tryb 480 linii, interlejsowany sprzętowo. Z kolei (za atariki: ->link<- SHIMC nam daje przeplot rionowy, nie poziomy - co dale nam 640 pikseli w poziomie.
    Czy w takim razie (oczywiście dla obrazków statycznych, przynajmniej na razie) byłoby możliwe wykonanie tryby RSHIMC (tag go sobie nazwałem, od Rybags-SHIMC), gdyż tam teoretycznie można by uzyskać 640x480 pikseli. Ze specyfikacji formatu SHIMC wnoszę, że 256 kolorów też nie byłoby wtedy wielkim problemem.
    Czy mogą się na ten temat wypowiedzieć znawcy assemblera? Bo ze mnie jest laik, niestety...

    Dodatkowo spytam - jak się da, jaka jest szansa na konwertowanie grafiki z VGA?
    • 2:
       
      CommentAuthorKaz
    • CommentTime8 Aug 2009
     
    Nawet TeBe nie wie, jak dziala tryb SHIMC :)
    • 3:
       
      CommentAuthorDracon
    • CommentTime8 Aug 2009
     
    SHIMC sie nie przyjal, bo:

    - kulalo jego rozprowadzanie (Internet nie byl wtedy tak wielki i szybki jak teraz)

    - migalo to jak jasna cholera (znacznie bardziej niz interlejs z XL-Paint i podobnych)

    - sam program nie byl najwygodniejszy w obsludze i jakby troche zamieszana jest procedura wyswietlania takiej grafiki


    W sumie jednak ten RSHIMC moze bylby lepszy gdyby dzialal na typowym sprzecie (i monitorze :)) ?
    • 4: CommentAuthortebe
    • CommentTime9 Aug 2009 zmieniony
     
    SHIMC może miga bo nie ma przeplotu kolumny parzyste/nieparzyste, tak jak ma XLPaint i jemu podobne (przeplot zmniejsza mruganie)

    z tymi 256 kolorami to gruba przesada, SHIMC udostępnia udawaną mapę kolorów realizowaną w sposób podobny do GED-a, G2F (zmiana kolorów w linii, gonienie plamki, Edit Raster w G2F), specyfikacja SHIMC-a ma się nijak do rzeczywistości

    P.S.
    niedługo coś wyjdzie do interlacu dla PC (INP, MAX, CIN)

    P.S. #2
    jedyne czego nie rozumiem to jak działa interlace Rybagsa
    • 5:
       
      CommentAuthorKaz
    • CommentTime9 Aug 2009
     
    ad PS1)

    A spod czyich rak wyjdzie to cos do interlace?
    • 6: CommentAuthorirwin
    • CommentTime9 Aug 2009
     
    I jeszcze trzeba mieć na uwadze zajętość ramu takiego mózgotrzepu ;) (interlace do kwadratu) - wszak 640x480 trochę zajmuje.
    • 7: CommentAuthorpavros
    • CommentTime9 Aug 2009
     
    Tebe: Oto przykladowy obrazek wyswietlany normalnie
    • 8: CommentAuthorpavros
    • CommentTime9 Aug 2009
     
    A to ten sam obrazek w interlace
    • 9: CommentAuthortebe
    • CommentTime9 Aug 2009
     
    to ma być żart ?
    • 10: CommentAuthorpavros
    • CommentTime9 Aug 2009 zmieniony
     
    Żart?
    Tebe, pisales, ze nie rozumiesz jak dziala interlace Rybagsa. Ten przyklad powinien wyjasnic jak to sie przedstawiqa wizualnie. Chyba ze chodzilo Ci o samo dzialanie kodu, ktory generuje sygnal synchronizacji? Jezeli tak, to dzialanie kodu tez moge dokladnie wyjasnic, gdyby byla potrzeba.
    P.S. W ktorym momencie odniosles wrazenie, ze to zart? Pytam, bo twoja reakcja jest dosc zdumiewajaca, a ja odbieram ja jako nieuprzejma.
    • 11:
       
      CommentAuthorsikor
    • CommentTime9 Aug 2009 zmieniony
     
    Reasumując, RSHIMC powinien sobie poradzić z formatami:
    640x400x2 - ST High, jak sądzę bezproblemowo
    640x480x4 - czyli SHIMC 640xXx2 plus dodatkowy bit z przeplotu Rybagsa
    640x480x16 - gdy podbije się interlejs (to chyba rzeczywisty max by był, który można śmiało wykorzystać)
    320x480x8 - SHIMC, 4 kolory z dwu standardowych obrazków plus dodatkowy z Rybagsa
    Oraz wszelkie pochodne (w tym 320x400x128 - jakoś tak mi dziwnie wychodzi). Pozostałe "mieszanie" wymaga już niezłego miąchania w kodzie. Niech ktoś obeznany z assemblerem mi powie, czy moje przypuszczenia są słuszne.
    Aha, jeszcze jedno - przez rastrowanie njak na ST-ku w obrazie 2 kolorowym przy rozdzielczości 640x400 możemy także otrzymać niezłe szarości ;)
    • 12: CommentAuthorirwin
    • CommentTime9 Aug 2009
     
    Wg mnie jedynie co możemy otrzymać to ... skierowanie do okulisty. ;)
    • 13:
       
      CommentAuthormiker
    • CommentTime9 Aug 2009
     
    Irwin, zamiast bezpodstawnie krytykować, lepiej pomyśł nad przerobieniem trybów typu FLI na atarkę. Niemożliwe? Po mojej (fakt, że może krótkiej) zabawie g2f-em stwierdziłem, że kwestia tylko w umiejętnym gospodarowaniu sprajtami i ściganiem plamki w linii. I może nie każdą taką grafę da się bezbłędnie wyświetlić, ale przynajmniej z dużym przybliżeniem.
    Btw. dla mnie to możesz łazić w podwójnych denkach od alpag, przemysł komediowy, zdaje się, takich poszukuje. ;D
    • 14:
       
      CommentAuthorsikor
    • CommentTime9 Aug 2009
     
    @irwin, no właśnie. Póki nie spróbujesz - nie zobaczysz. Według mnie nie będzie bardziej oczopędne niż inne tryby interlejsowane - do niedawna każdy uważał, że mamy max 240 linie skaningowe. Okazało się, że jest ich dwa razy tyle. Więc czemu nie spróbować czegoś nowego? W najgorszym wypadku powstaną ze dwa-trzy obrazki, w najlepszym - podstawa do nowych dem/planszy tytułowych/końcowych w programach. A poza tym - chodzi o sam fakt, czy się da? A jak się da, to jakim kosztem?
    Ale cóż, niektórzy wolą tylko narzekać i być malkontentami - wielka szkoda. Jak napisał Miker - trzeba próbować przełamywać bariery. Bo - jak wskazuje praktyka - większość z nich jest tylko iluzoryczna. Oczywiście, do takich trybów wskazany real hardware, bo pod emulcem połowa "takich" trików nie chodzi wogle lub się wykrzacza. Ale jak dla mnie - ważny jest real hardware, bo dopiero tam widać, czy coś jest o.k., czy do bani...
    • 15:
       
      CommentAuthorDracon
    • CommentTime9 Aug 2009 zmieniony
     
    Pavros, dzieki za wstawke.

    Przyznam, ze to niezle miga ale czy oddaje w miare wiernie realny hardware?
    OK, rozumiem, ze podstawa to prawdziwe Atari, ale jesli coraz bardziej bedzie sie to rozmijac, tzn. nie bedzie mozna zobaczyc danego efektu na emu, to tym mniej ludzi sie o tym dowie i (d)oceni. ;( W kazdym razie ja juz nie mam mozliwosci (luksusu) odpalania nowinek na Atarynie (nie przeskocze ciasnoty lokalowej i innych zmian w ostatnich latach) :|


    Myslalem, ze ten wynalazem Rybagsa przyda sie najbardziej
    do jakis caloekranowych obrazkow w hires, ktory mialby ew. dodatkowe kolory (w ilosci wiekszej niz 3 albo 4 bo to juz bylo).
    • 16: CommentAuthorirwin
    • CommentTime9 Aug 2009
     
    @Miker @Sikor - przepraszam jeśli mój żart wydał się wam nieodpowiedni, a ogólnie to: jak najbardziej macie rację.
    • 17: CommentAuthorpavros
    • CommentTime9 Aug 2009 zmieniony
     
    Dracon: Tak. Ten drugi przyklad w interlace dziala poprawnie tylko i wylacznie na prawdziwym sprzecie. Mysle, ze tego typu wlasciwosci Atari, chocby nie wiem jak rzadko wykorzystywane, powinny byc zaimplementowane w emulatorach. Dzis mozliwosci takich komputerow postrzegane sa przez pryzmat mozliwosci ich emulatorow. Nie powinno byc tak, ze niedokonczone emulatory zawezaja obraz mozliwosci danej platformy tylko do tych najbardziej znanych i najczesciej wykorzystywanych. Dodam jeszcze, ze niedawno odkrylem kilka nowych ciekawostek zwiazanych z grafika Atari. W tym m. in. z bugiem Antica rozgryzionym przez Rybagsa. Szczegoly wkrotce.
    • 18:
       
      CommentAuthorKaz
    • CommentTime10 Aug 2009
     
    Brzmi intrygujaco, pale sie do czytania.
    • 19: CommentAuthorpavros
    • CommentTime10 Aug 2009 zmieniony
     
    Podrzucam moja pierwsza probe miksu RSHIMC. Na razie nie jest to "przeplot do kwadratu", ktory powinien skrocic wysokosc obrazka o polowe, tylko "zwykly przeplot". Niemniej miga to gorzej niz w zwyklym SHIMC. Czyli ogolnie porazka. "Przeplot do kwadratu" z pewnoscia migania nie zminiejszy.
    • 20:
       
      CommentAuthorKaz
    • CommentTime10 Aug 2009
     
    Sprawdzales na prawdziwym sprzecie?
    • 21: CommentAuthorpavros
    • CommentTime10 Aug 2009 zmieniony
     
    Oczywiscie. Sprawdzanie na emulatorze nie ma sensu. Teraz podmienilem plik na minimalnie zmieniony. Rozni sie 1 bitem w DL. Bylo nie tak jak chcialem, choc to nie mialo znaczenia dla efektu.

    Oto jak wyswietlany jest obrazek w trybie SHIMC i RSHIMC1:
    SHIMC RSHIMC1
    klatka1 klatka2 klatka1 klatka2

    -- patrz plik tekstowy ponizej --

    Jak widac, w RSHIMC1 upraszczaja sie DisplayListy, bo linie danej klatki ida po kolei. Jednak wydaje mi sie, ze dla prawidlowego efektu przeplotu pionowego konieczne jest sasiedztwo czasowe (w jednej klatce) linii z obu polobrazow. Dlatego sadze, ze taki miks przeplotow nie da pozadanego efektu.
    Koniecznie trzeba jeszcze sprawdzic "przeplot do kwadratu". Wygladalby on tak:
    klatka1 klatka2 klatka3 klatka4

    -- patrz plik tekstowy ponizej --

    P.S. Oooops. Wycielo spacje. Zalaczam plik z tekstem powyzej, zeby mozna zobaczyc kolejnosc wyswietlanych linii.
    • 22:
       
      CommentAuthorsikor
    • CommentTime10 Aug 2009 zmieniony
     
    Pavros, nie wiem, czy zrobiłeś dobre założenie, bo jak masz przeplot A1, a pod spodem B1 - to wydaje mi się, że w ten spozób otrzymujesz zwykły interlejs. Tu raczej potrzebne są odpowiednio dłuższe półobrazy i przeplot jak w SHIMC (mogę się mylić).

    A1 B1
    A2 b2

    względnie

    A1 B1
    B2 A2

    Przynajmniej tak mi się wydaje, choć mogę się mylić...
    • 23: CommentAuthorpavros
    • CommentTime10 Aug 2009 zmieniony
     
    Sikor, dotykasz sedna sprawy. W tym sek wlasnie jaka ma byc kolejnosc linii. Ja nic na sztywno nie zakladam. Zrobilem pierwsza probe z takim ukladem linii, ktory bylo najlatwiej uzyskac i tak jak pisalem tez wydaje mi sie ze ten uklad jest nieprawidlowy z punktu widzenia zjawiska przeplotu pionowego. Najlepiej jakbys swoje propozycje rozpisal tak jak ja to zrobilem RSHIMC1 (dla klatek parzystych i nieparzystych) i koniecznie w pliku tekstowym, bo tu w komentarzach wycinane sa spacje i ja nie wiem czy widze dokladnie to, co ty chciales pokazac.
    • 24:
       
      CommentAuthorKaz
    • CommentTime10 Aug 2009
     
    Uzyj znacznikow [ code ] [ /code ] i nie powinno usuwac spacji.
    • 25:
       
      CommentAuthorsikor
    • CommentTime10 Aug 2009
     
    Hej! Akurat jest tak, jak chciałem napisać. Co do słuszności moich wywodów - nie wiem, czy potrafię je rozpisać, bo się na interlejsie nie znam na tyle, ale wydaje mi się, że właśnie w tym tkwi problem.
    Zasadniczo - wydaje mi się, że w metodzie Rybagsa nie masz dwu półobrazów, a jeden obraz, tyle, że linie parzyste są wyświetlane dzięki błędowi Antica - czyli obraz ma faktycznie max 480 linii, a nie składa się z dwu półobrazów. W tym tkwi metoda. Inna sprawa, że co druga linia jest "wymuszona" - wchodzi w "puste linie", które są standardowo wyświetlane na ekranie. Przez to powstaje efekt mrygania, ale jest za to podwójna rozdzielczość w pionie (dwa razy tyle wyświetlanych linii).
    Czyli, zasadniczo rzecz biorąc - w RSHIMCu powinniśmy mieć dwa półobrazy (a nie cztery), o max. rozdzielczości 320x480 każdy. Czyli - wyświetlamy zwykły SHIMC na dwa razy "dłuższych" obrazach, dbając przy okazji o to, aby zapełnić "puste" linie scanningowe metodą Rybagsa.
    Ja tego niestety nie potrafię zaimplementować - za cienki jestem w te klocki. Ale uważam, że właśnie w ten sposób to się z grubsza powinno odbywać. Aha, nie należy sobie zawracać głowy (przynajmniej na razie) teoretyczną mapą kolorów w SHIMC-u, na razie chodzi o sprawdzenie rozdzielczości (640x480x4 powinno wyjść bez większego problemu, przynajmniej teoretycznie. Większa ilość kolorów będzie wymagała pewnie bardziej skomplikowanych zabiegów). W najbliższych dniach ma też spróbować Pajero (na atariarea przynajmniej tak napisał), więc zobaczymy, co się z tego urodzi.
    • 26: CommentAuthorpavros
    • CommentTime10 Aug 2009
     
    Sikor, teraz rozumiem o co ci chodzilo. Byloby super, gdyby bylo tak jak piszesz czyli pojedyncza klatka wyswietlana 50 razy na sekunde ma 480 linii widocznych (625 wszystkich). Mielibysmy niemal VGA w Atarce. Niestety tak nie jest. To co odkryl Rybags, to tylko mozliwosc wyswietlania obrazu zgodnie (prawie) z trybem interlace w standardzie PAL, czyli tak jak robi to telewizja, magnetowidy, dvd czy taka Amiga, jak sie wlaczy ten tryb. W systemie PAL sa (dla uproszczenia) dwie mozliwosci wyswietlania. 1. 50 razy na sekunde ramka zawierajaca 312,5 linii. 2. 25 razy na sekunde 2 ramki stanowiace jedna klatke - kazda z nich nadal po 312,5 linii ale lacznie 625, z tym ze linii jednej ramki sa "wcisniete" pomiedzy linie drugiej, czyli jest dwa razy gesciej. Czyli ilosc informacji zawartej w sygnale sie nie zmienia. Zmienia sie tylko pozycja na ekranie co drugiej ramki. Z Atarka jest tylko taka roznica, ze mamy 312 linii na ramke, czyli dwu-ramkowa klatka w interlacie ma 624 linie, ale to telewizorom nie przeszkadza.
    • 27:
       
      CommentAuthorsikor
    • CommentTime10 Aug 2009
     
    Zasadniczo w tym trybie jest 25 razy na sekundę, są dwie "półramki", ale sprzętowe. Napisałem w uproszczeniu, jak widzę tą zasadę działania - jak wyjdzie (wychodzi) w praniu - okaże się...
    • 28:
       
      CommentAuthorKaz
    • CommentTime12 Aug 2009
     
    Czy da sie tez zastosowac ten trick z interlacem do innych "dziwnych" trybow jak TIP, RIP, etc?
    • 29: CommentAuthortebe
    • CommentTime12 Aug 2009
     
    Fox i Eru już się wypowiedzieli na ten temat, ten interlace nic nie zmieni
    • 30:
       
      CommentAuthorDracon
    • CommentTime12 Aug 2009
     
    Najlepiej to byłoby w ogóle bez, jak to mówił Konop, "ciepania" ekranu. Może jakaś atarowska odpowiedź na tryb NuFLI z commody??? :)