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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorTygrys1982
   • CommentTime9 Nov 2024 18:11 zmieniony

    
   Cześć wszystkim.
   Zafascynowany możliwościami tego narzędzia: ->link<- postanowiłem wgrać obrazek, a następnie na jego podstawie wygenerować obrazek o wymiarach 320 x 192 (załącznik) i rozmiarem pikseli 2px, a następnie przekonwertować go do formatu RAW. Moim celem było wczytanie tego pliku RAW i wyświetlenie go w trybie graficznym 8 za pośrednictwem programu napisanego w ATARI BASIC.
   
   Program jest następujący:
   10 GRAPHICS 8
   20 POSITION 0, 0
   30 OPEN #1, 4, 0, "D1:CAMEL.RAW"
   40 ADDR = PEEK(88) * 256
   50 FOR I = ADDR TO ADDR + 7679
   60 GET #1, A
   70 POKE I, A
   90 NEXT I
   100 CLOSE #1
   110 GOTO 110
   
   Problem w tym, że program nie wyświetla mi tego obrazka (pokazuje się standardowy niebieski ekran bez żadnej treści). Powoli kończą mi się pomysły co źle robię. Załączam również plik tego obrazka. Proszę o rady lub wskazówki.
   Z góry dzięki za wszelkie kontruktywne odpowiedzi.
   
   pozdro
   Tygrys1982

   • Camel.raw
2. • 2: CommentAuthormarok
   • CommentTime9 Nov 2024 18:11 zmieniony

    
   Poprawki do programu nie zaproponuję, niestety.
   
   Grafika chyba na pewno jest w 15-ce, nie w 8-ce (GR.15).
   
   Ten plik z załącznika otwiera się na PC (rozpoznawany jako PNG), jest mniejszy niż być powinien (7,5kb), więc w tej postaci do wyświetlenia na Atari się nie nadaje. (Musi być faktycznie RAW.)
   
   Przyznam, że niedawno się zorientowałem, że do oglądania obrazków można skorzystać z tej pomocy:
   ->link<-
   
   (coś w zastępstwie tego programu do wyświetlania grafiki na Atari, który chwilowo nie działa)
   
   (odpowiednio dobrać rozszerzenie do obrazka - jest rozpiska formatów na stronie)
   
   EDIT:
   sorki za pisanie trochę bzdur
   w sensie nie jest to gr. 15, a faktycznie rozdzielczość 8-ki, z tym że grafika ma do 16 odcieni (jak się wydaje, piksel definiowany jest na 4 bitach)
3. • 3:
      
     CommentAuthorPeri Noid
   • CommentTime9 Nov 2024 18:11

    
   Po pierwsze primo, czy jesteś pewien, że plik, który chcesz wczytać, jest tym o co chodzi? Ma on 5855 bajtów a ty chcesz wczytać 7696 bajtów. Po drugie, obraz w rozdzielczości 320x192 w trybie 8 zajmuje 7680 bajtów. Ale najważniejsze - adres bufora obrazu oblicza się tak: PEEK(88)+PEEK(89)*256.
4. • 4: CommentAuthorTygrys1982
   • CommentTime9 Nov 2024 20:11

    
   @Marok, @PeriNoid - kiedy poprawiłem swój program i spróbowałem wyświetlić obrazek w trybie graficznym 15, obrazek wczytał mi się, ale ... w postaci śmieci (tzn. chaotycznie ułożone piksele, nie tworzące niczego na wzór obrazka). Czyli już wczytał, więc jest mały sukces.
   Na podanej ->link<- obrazek faktycznie nie wczytuje się. Więc moźe format RAW to nie najszczęśliwszy wybór?
   Pytanie, czy da się obrazek PNG skonwertować bezpośrednio do formatu GR8?
5. • 5: CommentAuthormarok
   • CommentTime9 Nov 2024 20:11

    
   @Tygrys1982: To co wczytujesz, to są jakby spakowane dane (Pomimo że ma rozszerzenie RAW jest to PNG). Ja sobie skonwertowałem ten obrazek online do BMP i wtedy to wygląda już na coś zbliżonego do RAW (zn. dane obrazka), ale piksel tam jest na 1/2 bajta (4 bity) duży zamiast na 1/8 (1 piksel= 1 bit, jak w gr8), więc i sam obrazek zajmuje 4 razy tyle pamięci.
   Nie da się go prosto z takiej postaci RAW przerobić potem (najprościej byłoby "przechrzcić" - znaczy zmienić samo rozszerzenie) na .gr8.
6. • 6: CommentAuthormarok
   • CommentTime10 Nov 2024 09:11

    
   Ten obrazek po konwersji na format BMP da się obejrzeć na Atari z rozszerzeniem VBXE, najprawdopodobniej z pomocą programu (nie używałem; cieszę się, że jest):
   
   ->link<-
   
   Obrazek używa 5 odcieni/ kolorów.
7. • 7:
      
     CommentAuthorpirx
   • CommentTime10 Nov 2024 14:11

    
   ADDR = PEEK(88) + peek(89) * 256
8. • 8: CommentAuthorTygrys1982
   • CommentTime11 Nov 2024 19:11

    
   @marok - a czy bez rozszerzenia VBXE da się odczytać ten obrazek na fizycznej maszynie? U siebie nie mam VBXE, być może dlatego program dalej mi wyświetla chaos pikselowy w trybach 8 i 15.
9. • 9: CommentAuthormarok
   • CommentTime11 Nov 2024 20:11

    
   obrazek jest ponad możliwości nie rozszerzonego atari, normalnymi technikami tego zrobić się nie da (może ktoś ze znawców tematu programowalnych trybów graficznych coś by tu jeszcze wymyślił, nie wiem)
   
   (ta rozdzielczość to tylko 2 kolory, a masz w swoim obrazku 5)
   
   poza tym zapis obrazka który masz w pliku (tym udostępnionym) jest na pewno spakowany (dlatego plik jest krótki), więc nawet mając rozszerzenie sprzętowe (vbxe) nie zobaczyłbyś wczytując z tego pliku dane do pamięci ekranu przygotowanej grafiki taką jaka ona miałaby być (ale też byłby to tylko chaos pikselowy)
   
   rozwiązaniem najprostszym jest dithering obrazka i tylko 2 kolory na wyjściu
   natomiast wygląda to potem zdecydowanie mniej czytelnie (gorzej)
   
   próbowałem to już zrobić narzędziami online, ale otrzymuję wciąż zbyt duży plik wynikowy w BMP (taki prawie RAW), z którym sobie dalej nie radzę w jego dalszej obróbce
10. • 10: CommentAuthormarok
    • CommentTime11 Nov 2024 23:11

     
    Obrazek po ditheringu w załączniku.
    
    Pasuje pod program z pierwszego posta.
    Dithering na mój gust mógłby wyglądać trochę lepiej zwłaszcza przy oddaniu najciemniejszego koloru, który jest nazbyt rozjaśniony (nazbyt się zlewa z tłem).
    
    Obrazek w BMP ma następujące wartości kolorów 3,6,9,12,15.
    Podejrzewam (bo nie przyjrzałem się temu, ale tak teraz spekuluję), że 3 odpowiada najciemniejszemu kolorowi, i gdyby tą wartość troszkę zmniejszyć, to uzyskalibyśmy lepszy efekt (bardziej wyrazistą czerń - prawie lub bez ditheringu, w ramach tego najciemniejszego koloru).

    • Camel-dithered.gr8
11. • 11: CommentAuthormarok
    • CommentTime12 Nov 2024 19:11

     
    Rozwiązaniem mógłby okazać się jeszcze konwerter grafiki LEPICON.EXE na PC (do formatu HR2).
    
    format HP2:
    ->link<-
    
    "Lepicon":
    ->link<-
    
    
    Sam spróbowałem uruchomić ten konwerter grafiki pod DOSBox przez nakładkę(?) DOS4GW.EXE (1.97) licząc na to, że to jakoś pomoże, ale niestety, mnie się to chyba nie powiedzie.
    ("DOS/4GW fatal error (1008): can't load executable format for file LEPICON.EXE [1]")
    
    Mam przygotowany plik obrazka w postaci *.g (w wymaganej rozdzielczości 320x200) do konwersji (alternatywnie może to być plik BMP), chociaż jest to w przypadku tego przygotowanego pliku proste skopiowanie danych z BMP - prawdopodobnie więc dane wymagają jeszcze przetasowania (w BMP obrazek zapisany jest zawsze do "góry nogami", natomiast spodziewam się, że konwerter bez tego "odwracania obrazu" traktuje format *.g).
12. • 12: CommentAuthormarok
    • CommentTime12 Nov 2024 21:11

     
    jeśli kolory 0 i 1 (licząc od 0) palety GR8 są kolorami 1 i 2 palety GR15

    
    
    to frag. z opisu formatu
    czy kolory z palety GR15, o które powinno tu chodzić, to nie 2 i 3 ?
    
    

    dli_loop
    	lda colF1
    	ldx colF0
    	sta $d40a
    	sta $d017
    	stx $d018
    	
    	lda colE2
    	ldx colE3
    	sta $d40a
    	sta $d017
    	stx $d018
    
    	dey
    	bne dli_loop
    
13. • 13: CommentAuthormarok
    • CommentTime1 Dec 2024 00:12 (1 dzień temu) zmieniony

     
    Obrazek w ditheringu prawdopodobnie nie do końca prawidłowo mi się odwrócił (chociaż nie umiem tego stwierdzić "naocznie", to wyszło potem, że program "odwracający" miał błąd - powinno to się uwidaczniać na lewem brzegu obrazka).
    
    Wciąż nie udaje mi się uruchomić dedykowanego programu "Lepicon" do konwersji obrazków z BMP do atarowskiego formatu HR2.
    
    Dokonałem jednak tej konwersji "domowymi sposobami" (trochę kodu w asm 6502) podczepiając się do kodu źródła innego narzędzia (z obsługą wczytywania). Pisanie tego zajęło mi sporo i okazało się (dla mnie) wymagające.
    
    Wygenerowałem plik obx z obrazkiem do załadowania pod emulator (ew. można spróbować prawdziwej atarki). Niestety obrazek jest tutaj do góry nogami - za co przepraszam (ew. mogę popracować jeszcze nad jego odwróceniem).

    • Camel-updown(HR2).obx
14. • 14:
       
      CommentAuthorKaz
    • CommentTime1 Dec 2024 06:12 (1 dzień temu) zmieniony

     

    marok:

    Dokonałem jednak tej konwersji "domowymi sposobami" (trochę kodu w asm 6502) podczepiając się do kodu źródła innego narzędzia (z obsługą wczytywania).

    
    
    O jakie narzędzie chodzi? Jakieś dedykowane Atari?
    
    Uruchomiłem xex w Atari800Win, zrzut ekranu obrócony, żeby łatwiej porównać. Na górze to, co zrobiłeś w interlace, na dole to co było w GR.8.

    • camel_interlace.png
      
      
      
      
    • Camel-dithered.png
      
      
      
      
15. • 15: CommentAuthorVidol
    • CommentTime1 Dec 2024 06:12 (1 dzień temu)

     
    Po przeróbce na bmp 320x200 256 lepix sobie z tym już poradzi. Co do Lepxa to nie trzeba żadnych DosBoxów, chodzi bezproblemowo z wiersza poleceń.
    W załączniku pliki wygenerowane z lepixa, z g2f i plik camel.gr8, który nadaje się do wyświetlenia programem z 1 posta.

    • !camel.zip
16. • 16: CommentAuthormarok
    • CommentTime1 Dec 2024 13:12 (18 godzin temu)

     
    @Vidol: Super paczuszka - dziękuję.
    
    (Sądzę, że piszesz o Lepiconie? Czy się go da bezproblemowo uruchomić z wiersza poleceń - nie jestem przekonany czy dotyczy to także systemu Linuxowego?! Jestem mocno słaby w rozeznawaniu się na PC-tach.)
    
    
    Kaz:

    O jakie narzędzie chodzi? Jakieś dedykowane Atari?

    
    
    Tak. Tzn., w ostatnim czasie wciąż polegam na kodzie pakera z zina "Energy" (dla wygody i pewności działania odpowiednich procedur). W przypadku kodu konwertera przydatne były szczególnie procedury Elektrona (obsługa I/O), choć zwykle poważniejsze znaczenie miewa dla mnie część właściwa pakera autorstwa Jaskiera (przemyśliwałem od dłuższego już czasu nad trochę innym pakerem).
    
    Próbowałem przez shift+F10 w emulatorze Atari800 skopiować sobie ekran ("zrzut"), ale nie mogę doszukać się obecnie (może ciężka skleroza) w systemie programu graficznego do wklejenia obrazka "ze schowka" (skop. do pamięci).
    
    Jeśli tak ładnie wygląda ta konwersja, jak się przedstawia na screenie (uwzględniając "oszustwo" blendowania ze sobą dwóch ramek) to jestem bardzo zadowolony.
    Dziękuję, że wkleiłeś!
    (Są pewne przekłamania w niektórych miejscach, zakładam, ale ogólnie wygląda dla mnie niemal jak oryginał w BMP)
17. • 17: CommentAuthorVidol
    • CommentTime1 Dec 2024 15:12 (16 godzin temu)

     
    @marok: Tak chodziło mi o Lepicona, ale jak widać z rana jeszcze nie do końca się rozbudziłem :)
    Co do uruchamiania programu to w paczce znajduje się plik !run.bat, który działa na windows. Na Linuxie prawdopodobnie pójdzie to przez Wine.
18. • 18: CommentAuthormarok
    • CommentTime1 Dec 2024 21:12 (10 godzin temu)

     
    Zorientowałem się, gdzie są umieszczane (automatycznie) w katalogu screenshoty z Atri800. Zamieszczam dwa w celach porównawczych (podmieniłem kolory w tym xex wygererowanym przez Lepicona, który jest od @Vidola).
    
    Wydaje mi się na podstawie ich porównania wizualnego, że generuje się to samo (zarówno z "Lepicona" jak i z tej konwersji zastępczej).
    Róznica jest taka, że nie dokładnie z tego samego BMP korzystaliśmy przy konwersji, bo ja swoją wersję najprawdopodobniej rozciągnąłem jeszcze ze 192 na 200 w pionie wiadomym narzędziem internetowym (o nim w pierwszym wpisie w wątku).
    
    W 3 załączniku jeszcze plik xex po konwersji zastępczej (obrazek już nie jest odwrócony).
    
    Kolor najjaśniejszy wychodzi nieco ciemniej niż w oryginale (chociaż najbardziej odpowiedzialny rejestr koloru podkręcony jest na $0e - ale "uśrednia" się z wartością $08 rejestru od GR8).
    
    @Vidol: Dzięki za doprecyzowanie. WINE nie mam zainstalowanego (czytałem o nim), ale mam nazbyt duży rozgardiasz w systemie (taka nieopanowana sytuacja mi się wytworzyła), abym mógł spróbować teraz go sobie instalować.

    • Camel-hr2_homeEdit.xex
    • homeedit.png
      
      
      
      
    • lepicon.png