atarionline.pl VBXE oczami programisty - 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:
       
      CommentAuthorlarek
    • CommentTime17 Jan 2015 zmieniony
     
    Dla mnie to zupełna nowość, więc proszę się nie śmiać :D
    Mam pytanie, na które odpowiedź zapewne wszyscy znają i z pewnością rozwiązanie zagadki jest banalnie proste... Do rzeczy!

    Chcę sobie wyświetlić jakąś grafikę w trybie graficznym SR OVERLAY, czyli np. 320x192 w 256 kolorach. Obrazek mogę narysować sobie w jakimś programie graficznym - np. w MS Paincie. No i teraz najciekawsze. Cytuję z podręcznika programisty VBXE FX v1.26:

    "Za każdy piksel w tym trybie odpowiada jeden bajt w pamięci VBXE. Bajt o wartości zero (0) powoduje, że piksel nie jest wyświetlany (jest przeźroczysty - chyba, że ustawiony jest bit no_trans w rejestrze VIDEO_CONTROL). Pozostałe wartości wybierają z aktywnej palety OVERLAY kolor o numerze C = wartość bajtu."

    To jest zrozumiałe :)

    Powiedzcie mi, za pomocą jakiego narzędzia mogę przygotować takie dane, które będą poprawnie interpretowane przez VBXE? Jak mam zapisać grafikę, którą sobie stworzyłem w programie graficznym, żebym mógł ją wrzucić do pamięci VBXE?

    Z góry dziękuję za jakiekolwiek wskazówki, które naprowadzą mnie na rozwiązanie tego problemu.
    • 2:
       
      CommentAuthorEnder
    • CommentTime17 Jan 2015
     
    O nareszcie temat dla mnie:)
    • 3: CommentAuthorgreblus
    • CommentTime17 Jan 2015
     
    Larek, zobacz tutaj:
    ->link<-

    Jest tam też link do wątku na tym forum, gdzie pytałem o to samo ;)

    Grafikę robiłem w Grafx2, palety JASC przez niego generowane konwertowałem pal2bin (stąd ->link<- w załączniku binarka dla Linuksa) a obraz eksportowałem w Gimpie do raw data (chyba płaski RRR,GGG,BBB nie pamiętam już).
    • 4: CommentAuthorbob_er
    • CommentTime17 Jan 2015
     
    Ja napisałem sobie Toola, który konwertuje tga na rawowe formaty małego i dużego atari. Różnej rozdzielczości i w różnej liczbie kolorow.
    • 5: CommentAuthorpin
    • CommentTime17 Jan 2015
     
    Można też i tak:

    ->link<-
    • 6: CommentAuthorRocky
    • CommentTime17 Jan 2015
     
    proponuję użyć Amigi (np. WinUAE) i Deluxe Painta.
    Tam można też łatwo wymusić kolor zero i zremapować paletę..
    • 7: CommentAuthor0xF
    • CommentTime17 Jan 2015
     
    Zapisać *.tga z paletą, wstawić odpowiednią część pliku.
    • 8: CommentAuthormono
    • CommentTime17 Jan 2015
     
    Tru. Generalnie zapisuj po prostu nieskompresowany obrazek 8-bit indexed (palette). Żadnych trukolorów i innych hajkolorów bo będziesz miał miliony kolorów i sam będziesz musiał sobie to przerabiać na paletę. Przez sąsiednie forum podesłałem Ci maila - odezwij się do to dostaniesz źródło do "Ni z gruchy, ni z pietruchy" :D
    • 9:
       
      CommentAuthorjhusak
    • CommentTime17 Jan 2015 zmieniony
     
    Kiedyś na Amidzie robiło się floydem steinbergiem 16-kolorowe gify wyglądające jak true color w wysokiej rozdzielczości. Tak więc mono ma rację - należy wykorzystać moc gimpa przy przekształcaniu obrazków do indexed.

    Eksport jako RawData Indexed zapisuje w dwóch plikach: paleta i obrazek z indeksami kolorów bajt po bajcie. Można to łatwo obsłużyć w czym się chce.
    • 10:
       
      CommentAuthorxeen
    • CommentTime17 Jan 2015
     
    @Mono - jeżeli chodzi o VBXE to Ty już wiesz co ;)
    • 11:
       
      CommentAuthorlarek
    • CommentTime17 Jan 2015
     
    Dzięki Panowie. Widzę jednak, że to nie takie hop-siup. Szkoda, że tyle lat po pojawieniu vbxe nie powstały jakieś programy wspomagające. No cóż, trzeba będzie się temu wszystkiemu, co tu opisaliście przyjrzeć z bliska.

    @Pin, można i tak, ale nie chcę ograniczać się do oglądania obrazków... No, ale o tym później.

    @Mono, dzięki za maila. Spróbuję to przetrawić ;)

    @Greblus, coś tam kiedyś robiłem w Action!, ale obecnie nic z tego nie pojmuję... eee, no może prawie nic

    @Bob_er, a nie chcesz się podzielić swoim programem?
    • 12: CommentAuthorgreblus
    • CommentTime18 Jan 2015 zmieniony
     
    Larek, co do samej grafiki, da się to też zrobić w całości w Gimpie, jak pisał Kuba.

    Ja to robię tak:

    1. Otwieram plik w Gimpie.
    2. Obraz -> Skaluj obraz -> np. 320x200
    3. Obraz -> Tryb -> Indeksowany (Optymalna paleta 256 kolorów), można sobie ditherowanie włączyć -> Konwertuj.
    4. Z menu Okna, Dokowalne okna... -> Paleta kolorów (tu możemy sobie ją zobaczyć i pozmieniać).
    5. Okna -> Dokowalne okna... -> Palety. Rozwijamy dziubek Konfiguruje tą kartę -> Menu palet -> Zaimportuj paletę -> Obraz.
    6. Prawy przycisk na zaimportowanej palecie -> Export As > Text file.

    7. Zapisuje plik i konwertuje do postaci binarnej załączonym skryptem w Pythonie (można też przeparsować plik tekstowy, ale w Action! mi się nie chce ;)). Binarny się łatwiej wczytuje.

    8. Obraz eksportuje jako Raw data.

    W starszym Gimpie było to chyba lepiej zrobione. Zapewne da się prościej, jak się zna specyfikację bitmapy, czy tam innych formatów indeksowanych z paletą w nagłówku.
    • 13: CommentAuthormono
    • CommentTime18 Jan 2015
     
    @xeen: Wiem :) Póki co mam nawał zajęć we firmie, ale jak się obrobię z tym wszystkim to dostaniesz, com obiecał.
    • 14:
       
      CommentAuthorlarek
    • CommentTime19 Jan 2015 zmieniony
     
    Chyba w końcu udało mi się w miarę opanować ładowanie i wyświetlanie grafiki. Dzięki za wskazówki i pomoc.

    • 15: CommentAuthormono
    • CommentTime19 Jan 2015 zmieniony
     
    Po zaaplikowaniu:
    201a: ldx #$00
    2051: lda #$05
    2056: lda #$22

    Widać piękny obrazek :) Brawo! Pierwsze koty za płoty.
    • 16:
       
      CommentAuthorlarek
    • CommentTime19 Jan 2015 zmieniony
     
    Ja pierniczę, Mono, jak Ty to wychwyciłeś? Szok! :D
    Siedziałem prawie całą noc, no i to są efekty...
    Poprawiam natychmiast.


    edit:
    Poprawione. W moim poście też dałem już plik z poprawką.
    Jeszcze raz dziękuję :)
    • 17:
       
      CommentAuthorlarek
    • CommentTime19 Jan 2015 zmieniony
     
    W ramach ćwiczenia jeszcze jeden. Wiem, że konwertery BMP->VBXE_XEX istnieją i każdy sobie może wygenerować takie obrazki w dowolnej ilości, więc ten z mojej strony będzie już raczej ostatnim. Teraz wezmę się za grafikę do gry :)

  1.  
    Hehe, fajne te obrazki :) Znaczy się, fajna gra będzie :)
    • 19: CommentAuthormono
    • CommentTime19 Jan 2015
     
    @larek: późno było i zapomniałeś tylko # :)
    • 20:
       
      CommentAuthorjhusak
    • CommentTime20 Jan 2015
     
    Fajne selfie, tylko ktoś fona wyrwał z... ręki :D
    • 21: CommentAuthorgreblus
    • CommentTime20 Jan 2015
     
    To jest Renatka, ona nie ma nerki ;). Larek, zrób jeszcze Staszka! (chyba za dużo Fox-a oglądam).
    • 22:
       
      CommentAuthorlarek
    • CommentTime10 Feb 2015
     
    Dojrzałem właśnie do zadanie kolejnego pytania :)

    Wstęp:
    Chcę wyświetlać róże ruchome obiekty na jakimś tle-grafice. Wszystko oczywiście w trybie graficznym vbxe 320x192.
    Robię to tak:
    - kopiuję do bufora całe tło
    - wstawiam na to tło w buforze moje obiekty (docelowo sporo)
    - jak już mam wszystkie obiekty na miejscu...
    - ...przenoszę cały obraz narysowany w buforze w miejsce pamięci ekranu - no i pojawia nam się wszystko na ekranie.
    Oczywiście zaprzęgam do tego blitter vbxe.

    Sedno sprawy:
    Gdybym podobne rzeczy robił na klasycznym Atari, to wszelkie rysownie po ekranie raczej próbowałbym (w miarę możliwości) robić podczas przerwania pionowego, bo wówczas mógłbym uniknąć migotania, które może pojawić się przy rysowaniu bez synchronizacji.

    Pytanie:
    Czy w trybach VBXE i przy wyświetlaniu tych trybów takie działanie, tj. synchronizacja z przerwaniem pionowym, a w zasadzie rysownie podczas przerwania ma sens? A może vbxe ze swoim blitterem rysuje obraz na tyle szybko, że żadnych zakłóceń nie zobaczymy?

    Z góry przepraszam, jeśli moje pytanie jest bez sensu ;)
    • 23: CommentAuthormono
    • CommentTime10 Feb 2015 zmieniony
     
    Uniknąć blitowania wyniku na ekran docelowy możesz za pomocą dwubuforowania i zmiany xdlisty.
    Blitter też ma swoją wydajność (ok 130kb na ramkę), więc jeśli zapuścisz go na rysowanym przez monitor ekranie, to możesz obserwować efkt przegonienia plamki. Jeśli blitter będzie odpalany w tym samym momencie w ramce, to przeganianie plamki może się dziać zawsze w tym samym momencie i przy animacjach w tym punkcie będziesz widział kawałek starej klatki i kawałek nowej. Jeśli blitter nie będzie synchronizowany, to albo efektu nie zobaczysz, albo ze względu na rzadkość i różne miejsca w których występuje będzie praktycznie nieuchwytny dla oka. VIDEO_CONTROL i XDL_ADR odczytywane są przez VBXE po zgłoszeniu synchronizacji pionowej (ramki) więc możes je dowolnie zapisywać bez potrzeby synchronizacji. BL_ADR zdaje się jest przepisywany w momencie uruchomienia blittera. Blitter możesz oczywiście uruchomić w dowolnej chwili.

    Edit: A efekt przeganiania plamki możesz obejrzeć w Tomek8-VBXE "demo". No i ile w całej ramce zajmuje blitowanie prawie 60 obiektów o różnych rozmiarach (obiektow i masek).

    Edit 2: Jeśli odpalisz blitter zanim obraz, który jest wyświetlany zostanie narysowany to pamka może go nigdy nie dogonić. Pomierz sobie czas malowania blittera i po prostu odpalaj go w odpowiedniej chwili. Pomocny tu będzie VCOUNT.
    • 24:
       
      CommentAuthorlarek
    • CommentTime10 Feb 2015
     
    Mono, dzięki za - jak zawsze - fachową pomoc. To mi dużo wyjaśniło. Wracam do pracy :)