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: CommentAuthorilmenit
   • CommentTime25 Jan 2010 11:01

    
   irwin, ale o co biega?
   Ja się od współzawodnictwa odcinam. Mam za to nadzieję na współpracę nad jakimś projektem w przyszłości.
2. • 2: CommentAuthorirwin
   • CommentTime25 Jan 2010 11:01 zmieniony

    
   Ilmenit to taki żart, nie bierz tego tak do siebie. Współzawodnictwo jest jak najbardziej ok, gdyby nie ono nadal siedzielibyśmy w jaskiniach i stukali się maczugami po głowach ;)
   Zawsze to lepiej aby na "rynku" ;) istniała konkurencja a nie monopol bo to korzyść dla nas atarowców ;)
   Dlatego Ooz tak w ostatnim roku nawoływał co ze sceną i w odpowiedzi ostatni konkurs pokazał co daje konkurencja i współzawodnictwo.
   
   Narazie w tym temacie tj quantizera na minimalne prowadzenie wysunął się Tebe - to nie znaczy że powinnieneś odpuścić.
   go! go! Ilmenit!
   go! go! Tebe!
   ;)
   A o co biega? hmm... naprawdę bardzo łatwo to odnaleźć. ;)
3. • 3:
      
     CommentAuthorKaz
   • CommentTime25 Jan 2010 11:01

    
   Gdyby bylo latwo, to bysmy odnalezli.
4. • 4: CommentAuthorirwin
   • CommentTime25 Jan 2010 12:01

    
   Ilmenit jednak po paru głębszych (testach ;) muszę przyznać że choć wersja Tebe ma większy potenciał (dithering, 5y kolor) to jednak daje w większości przypadków trochę gorsze rezultaty. (Choć pierwszy pic jaki sprawdziłem, wyglądał naprawdę znakomicie w wersji Tebe)
   Możliwe że jest to program o innym przeznaczeniu, nie wiem, nie znam się i trochę wyskoczyłem jak Filip z Konopii ;)
   Tak więc sorry
   wynik brzmi
   Ilmenit 1:1 Tebe
   ;)
   
   Link tutaj:
   ->link<- w sekcji download
5. • 5: CommentAuthorilmenit
   • CommentTime25 Jan 2010 13:01

    
   Znaczy BMP2MCH?
   Czy ten program umożliwia konwersję ze zmianami koloru co linię i w kolorach innych niż szare?
6. • 6: CommentAuthorirwin
   • CommentTime25 Jan 2010 13:01 zmieniony

    
   Niekoniecznie tylko szare ;)
   
   Góra u Ciebie wychodzi lepiej dół wg mnie wersji Tebe jest lepszy.
   Ale ogólnie tak jak powyżej napisałem Twoja wersja działa trochę lepiej.

   • 9.mch
7. • 7:
      
     CommentAuthorKaz
   • CommentTime25 Jan 2010 13:01 zmieniony

    
   Irwin - dorzucilem ten obrazek po konwersji z BMP2MCH do artka, dzieki :).
   
   ->link<-
   
   A jakie parametry uzyles?
8. • 8: CommentAuthorilmenit
   • CommentTime25 Jan 2010 21:01

    
   Najnowsza wersja Quantizatora - poprawiona duż liczba błędów i wszystkim używającym wcześniejszej polecam przerzucić się na aktualną.
   
   @irwin - jak skonwetowałeś bmp2mch na kolorowy obrazek?

   • Quantizator098.zip
9. • 9: CommentAuthorirwin
   • CommentTime25 Jan 2010 22:01 zmieniony

    
   Po pierwsze musisz użyć nie bmp2mch a bmp3mch, który jest w tym samym archiwum.
   Po drugie konwenter Tebe nie uznaje plików png, plików w 24bit. Ponadto nie ma resize więc trzeba to wszystko samemu zrobić tj przerobić plik na 160x240 w 8bit koloru. Czyli przerobienie to wymaga w odróżnieniu od Twojego konwentera udziału trzeciego programu który przerobi nam ów pic do zjadliwych dla bmp3mch 160x240 w 8bit. Skoro tak to jak zauważyłem że im mniej kolorów tym lepiej mu to idzie to zamiast do 256 przerobiłem do 50-60.
10. • 10: CommentAuthortebe
    • CommentTime25 Jan 2010 22:01 zmieniony

     
    bmp2mch - konwersja do 4 lub 5 kolorów
    bmp3mch - konwersja do 4 lub 5 kolorów co linię
    
    -r resize
    
    akceptuje BMP i PNG, tylko w palecie 8bit Per Pixel, max 160x240
11. • 11: CommentAuthorilmenit
    • CommentTime26 Jan 2010 12:01

     
    Jak po użyciu bmp3mch sprawić, żeby obrazek był kolorowy?
    Robię:
    bmp3mch dune.bmp -c5
    i dostaję efekt jak w załączniku.

    • mch.rar
12. • 12: CommentAuthorirwin
    • CommentTime26 Jan 2010 17:01

     
    U mnie kolory z Twojego pliku mch są. Podejrzewam że to wina wersji Graph2Fonta jakiej używasz.
    Przy okazji jak tam duszki? Jest jakaś nadzieja?
13. • 13: CommentAuthorilmenit
    • CommentTime26 Jan 2010 18:01 zmieniony

     
    Jakiej wersji G2F używasz? Ja mam najnowszą ze strony - Graph2Font v3.8.7.8. Testowałem zarówno full jak i lite i efekt ten sam.
    Wczytujesz poprzez menu File->Open... czy coś innego?
    
    Wcześniej niż na duszki będzie szansa na zmianę koloru w linii. Ale i tak musi trochę poczekać, bo muszę ulepszyć jeszcze Adventure Studio. Quantizator powstał właściwie dlatego, że brakowało mi grafiki do przykładowej gry, a domyślny konwerter w G2F dawał nieciekawe rezultaty.
14. • 14: CommentAuthorirwin
    • CommentTime26 Jan 2010 18:01

     
    Sprawdziłem ową najnowszą tj v3.8.7.8 i rzeczywiście pod nią są odcienie szarości. Ja używam nowszą/testową aktualnie v3.8.8.2 z 14.01.2010 i pod nią jest wszystko Ok. Pewnie Tebe wprowadził jakieś zmiany i dlatego. Napisz do Tebe.
    
    Ok w takim razie nic tylko pozostaje czekać na duszki.
15. • 15:
       
      CommentAuthorKaz
    • CommentTime31 Jan 2010 20:01

     
    Ilmenit - czy mi sie zdaje, czy wersj 0.98 generuje wiecej kombinacji niz 0.97 (tam bylo 24)?
16. • 16: CommentAuthorilmenit
    • CommentTime1 Feb 2010 11:02

     
    Tak, generuje więcej, choć w aktualnej mode=local nie ma sensu, bo jak sprawdziłem dokładnie taki sam rezultat daje przepisany na nowo algorytm podstawowy. Dlatego też nie warto używać /preview, a tylko /fastpreview.
17. • 17:
       
      CommentAuthorKaz
    • CommentTime18 Feb 2010 18:02

     
    Czy mozna liczyc na rozszerzenie programu na inne tryby niz GR12? Na przyklad tryby GTIA bardzo by byly dla mnie interesujace... i to wszystkie: GR9, GR10, GR11.
18. • 18: CommentAuthorilmenit
    • CommentTime18 Feb 2010 19:02

     
    Da się zrobić bez większych problemów. W jakim formacie zapisywane pliki wynikowe?
19. • 19: CommentAuthorirwin
    • CommentTime18 Feb 2010 19:02

     
    To i ja się dołącze:
    
    A da się zrobić aby całość grafiki była zapisywana tylko i wyłącznie do duszków np do pliku *.pmg? (czytanego przez g2f)
    
    Z góry uprzedzam że wiem i znam ograniczenia duszków i nie byłoby mi to potrzebne do konwersji obrazków 16mln kolorów a konwersji z góry przygotowanych uprzednio obrazków np takich:
    
20. • 20:
       
      CommentAuthorKaz
    • CommentTime18 Feb 2010 20:02

     
    Czy to z Timathesa?
    
    

    Imenit:

    W jakim formacie zapisywane pliki wynikowe?

    
    
    Nie mam pojecia - jezeli to ma byc zmiana koloru co wiersz to MIC nie wchodzi w gre, a standardu G2F co do zapisu GR10/11 nie ma. Musze pomyslec.
21. • 21: CommentAuthorirwin
    • CommentTime18 Feb 2010 20:02 zmieniony

     
    Nie, to zapisane do png duszki z grafiki Ooz'a "Elfi"
    Tak pokazałem dla przykładu, mam nadzieję i że dla testu engine ilmenita.
22. • 22:
       
      CommentAuthorKaz
    • CommentTime18 Feb 2010 20:02

     
    Rozumiem stojaca za tym idee i przylaczam sie do postulatu!
23. • 23: CommentAuthorilmenit
    • CommentTime19 Feb 2010 11:02

     
    Tebe mi napisał:
    "*.PMG to zrzuty pamięci tablic wykorzystywanych przez G2F, ogólnie sugeruję opracować jakiś prostszy sposób zapisu niż męczyć się z *.PMG"
    Tak więc najpierw musi być opracowany sensowny standard zapisu duszków i jego obsługa musi być dodana do G2F.
24. • 24:
       
      CommentAuthorKaz
    • CommentTime19 Feb 2010 14:02

     
    Mamy 2010 rok, ponad 30 lat od powstania 8-bitowego Atari i nie doczekalismy sie formatu zapisu duszkow...
    
    No to chyba czas rozwazyc taki format, rzucic jakies propozycje. Przede wszystkim format powinien umozliwiac zapis jednego, wybranego duszka (obojetnie czy gracza, pocisku czy 5-tego gracza) albo zestaw dla calego ekranu. To wazne do przenoszenia z innymi programami (ktore powstana, he he). Do tego w naglowku jakies informacje o ustawionych globalnych priorytetach duszkow.
    
    Z graficznego punktu widzenia duszki Atari (gracze, pociski) to paski grafiki wysokosci 256 linii, z tym ze w kazdej linii moze byc inny kolor, inna szerokosc duszka i inna pozycja na ekranie, w ktorej sie znajduje.
    
    Moim okiem niefachowca zapis danych moglby wygladac jakos tak:
    
    1. Naglowek calego pliku
    - informacja o tym, ze to PMG 2.0 :)
    - informacja o liczbie duszkow w pliku i ich rodzaju, oraz ewentualnie kolejnosci
    - a dalej dane poszczegolnych duszkow:
    
    2. Naglowek duszka:
    - nr duszka (determinuje czy to pocisk, gracz czy 5-ty duszek czyli wszystkie pociski razem)
    - jego pozycja startowa na ekranie Y
    
    3. Dane duszkow na calej wysokosci, 256 linii. Dla jednej linii duszka byloby to tak:
    - informacja czy duszek jest aktywny w danej linii (uwaga! to wazne, bo duszek czesto zaczyna sie znacznie wyzej niz jego rzeczywiste dane na ekranie, wiec bitmapa i inne dane moga byc puste, wartosc zero, ale duszek tutaj moze sie zaczynac)
    - pozycja X na ekranie (od krawedzi ekranu? bezwzgledna?) w danej linii
    - dane bitmapy danej lini duszka
    - informacja o kolorze linii
    - informacja o szerokosci duszka w linii
    
    Tak na oko jedna linia potrzebowala by tyle bajtow:
    aktywnosc duszka - 1 bit \ wiec to mozna by razem,
    szerokosc duszka - 2 bity / w jednym bajcie jako nibble
    pozycja X na ekranie - dwa bajty
    dane bitmapy - jeden bajt
    kolor linii - jeden bajt
    
    Co daje 5 x 256 = 1280 bajtow na jednego duszka. W skrajnym przypadku 1,2KB x 8 = 10KB na dane o wszystkich duszkach. Oczywiscie tam bedzie mnostwo zer w takim pliku, wiec mozna wymyslic sposob pomijania duzych partii pustych danych i program zapisujacy albo odczytujacy pominie puste miejsca. Mozna tez kompresowac, ale to juz szczegoly do ustalenia.
25. • 25:
       
      CommentAuthorDracon
    • CommentTime19 Feb 2010 15:02 zmieniony

     
    Mamy 2010 rok, ponad 30 lat od powstania 8-bitowego Atari i nie doczekalismy sie formatu zapisu duszkow...

    
    
    Kiedys namawialem Sebana na ripper do... duszkow z gier, itp. On zbadal sprawe i stwierdzil, iz to niemozliwe do realizacji, bo kazdy programista mial swoje sposoby obslugi (zapisu) duszkow...
    
    
    

    To wazne do przenoszenia z innymi programami (ktore powstana, he he).

    
    Przeciez istnieja takowe, np. w zestawie "Avalon Game Studio" (czy jakos tak podobnie sie zwalo), gdzie tworzono grafike, albo LUDEK MAKER - niezwykle wygodny. :]
26. • 26: CommentAuthormono
    • CommentTime19 Feb 2010 15:02

     
    W każdej linii może być też inny priorytet i konfiguracja sprajtów (multicolor, 4/5 players) GTICTL.
27. • 27: CommentAuthorirwin
    • CommentTime19 Feb 2010 17:02 zmieniony

     
    @mono - podałem przykład duszków Ooza - obecnie naszego najlepszego grafika. On nigdy nie używa innego piorytetu niż 4, nigdy nie używa połączonych pocisków dla duszka nr 5. Nie wiem co GTICTL, ale pewnie też tego nie używa. Tak więc dla uproszczenia niech to będzie stały piorytet4 i zwykłe 4 duszki i 4 pociski. Bo owszem można i "nie da się" ;) tylko to raczej nowych obrazków nie przysporzy.
    
    @ilmenit - ".PMG to zrzuty pamięci tablic wykorzystywanych przez G2F", jak potrafisz to rozgryźć, - w końcu w g2f spełnia swoją rolę, w końcu Tebe jakoś to zaprogramował - to może być i ten *.pmg.
28. • 28: CommentAuthormono
    • CommentTime19 Feb 2010 18:02

     
    @irwin: a ktoś tu w swoich obrazkach eksperymentował z priorytetem 0 :)
    
    Jeśli opracowujecie format, to fajnie by było, żeby był w miarę kompletny po to, żeby za chwilę nie pojawił się "nowy, lepszy standard".
    W zasadzie prócz rejestrów, które podał Kaz i ja nie ma chyba potrzeby zmieniać innych z linii na linię no bo poza tym to są tylko rejestry kolizji i VDELAY opóźniający rysowanie duchów dwuliniowych o jedną linię skanningową (ustawia się go raczej globalnie raz).
    
    Generalnie to rejestry GTIA można dzielić na 2 grupy:
    a) dotyczące konkretnego sprajta czyli jego kształtu, położenia i szerokości oraz rzeczonego opóźnienia w rysowaniu danych sprajta,
    b) dotyczące konfiguracji sprajtów i mające odzwierciedlenie na grupie sprajtów czyli kolory, tryb multicolor, priorytet i 4/5playerów (wpływa na wykorzystywany kolor dla missiles i wyłącza dla nich multicolor pozostawiając go tylko dla playerów).
    
    Format oczywiście może opisywać dane na wyższym poziomie abstrakcji, niż rejestry ale powinien imho uwzględniać specyfikę pmg. Nie powinno to raczej skomplikować niepotrzebnie formatu czyniąc go niemożliwym do ustalenia :)
29. • 29: CommentAuthorirwin
    • CommentTime19 Feb 2010 19:02 zmieniony

     
    Ja próbowałem z piorytetem 0 i się poddałem, kolory powstałe były nieodpowiednie dla mnie, ponadto wtedy aż trzy kolory stają się prześwitujące dla duszków.
    A patrząc na twój wpis na stronce forever to mniemam że Ty użyłeś tego piorytetu. Gratuluje więc i jego użycia, bo wiem że to dość trudne, wymaga specyficznego obrazka a dwa, samego wystartowania w kompo graficznym, już się nie mogę doczekać obrazka by Mono. Mam nadzieję że wystartujesz w następnych, także w Kaz Atarionline GFX Compo 2010 jeśli będzie (musi być ;)
    
    Co do podanych technikali, to dzięki za informacje, ale w sumie dla grafika to, jak i sam format pliku pmg powinien być nieistotny. W sumie bowiem chodzi oto aby format/standard spełniał swoją rolę tj aby zawierał dane duszków i pozwalał na wczytanie do wszystkich (czyli sztuk jeden ;) programów graficznych tj do Graph2Fonta. Obecny *.pmg jest ok, pozostaje go rozgryźć, lub jeśli to awykonalne zrobić jakikolwiek inny ale z naciskiem na ZROBIĆ jeszcze w tym stuleciu ;)
    
    Jeśli miałoby to przyspieszyć stworzenie to początkowo możnaby odpuścić sobie duszka nr5, duszki multicolor, piorytety inne niż 4. Lepiej zrobić coś niż stwierdzić że wszystko razem jest za trudne i nie zrobić nic. Przykład Ooza pokazałem dlatego aby uzmysłowić że przy standardowych ustawieniach piorytetu i zwykłych 4 duszkach da się wygrywać kompoty raz za razem ;)
30. • 30:
       
      CommentAuthorKaz
    • CommentTime19 Feb 2010 20:02 zmieniony

     
    @Dracon:
    
    Tak, istnieja programy do duszkow, ale nie sa zgodne ze standardem, ktory wlasnie wymyslamy :P. Zreszta zaloze sie, ze nie maja uwzglednione wszystkich mozliwosci zmian rejestrow co linie, chyba jeszcze nie powstal taki program, ktory to umozliwia.
    
    

    Mono:

    W każdej linii może być też inny priorytet i konfiguracja sprajtów (multicolor, 4/5 players) GTICTL.

    
    
    Zalozylem w propozycji, ze priorytet bedzie staly dla calego duszka, bo tak sie najczesciej ustala, ale masz racje - ze format danych powinien uwzgledniac maksymalne mozliwosci manipulowania duszkami, a nie najczesciej wykorzystywane.
    
    

    Irwin:

    i pozwalał na wczytanie do wszystkich (czyli sztuk jeden ;) programów graficznych tj do Graph2Fonta. Obecny *.pmg jest ok, pozostaje go rozgryźć,

    
    
    Obecnie DearHorse tworzy edytor PMG, jest chetny do wspolpracy, mozna sprobowac dogadac sie z nim co do formatu danych. Nawet mozna powiedziec, ze to najlepszy moment, zeby z nim pogadac na ten temat...
31. • 31: CommentAuthorirwin
    • CommentTime20 Feb 2010 08:02

     

    Kaz:

    Obecnie DearHorse tworzy edytor PMG, jest chetny do wspolpracy, mozna sprobowac dogadac sie z nim co do formatu danych. Nawet mozna powiedziec, ze to najlepszy moment, zeby z nim pogadac na ten temat...

    
    
    Tworzyć to tworzy, znam też inną osobę która również tworzy edytor gfx z duszkami na pc dla Atari. Tyle że to trwa już jakiś czas, a pewnie potrwa jeszcze jakiś czas - a znając realia Atari to raczej będzie długi czas i do tego wcale nie jest pewne czy nie skończy się jedynie na zapowiedziach i wiecznym tworzeniu. Zaś graph2font namacalnie istnieje, format pmg istnieje więc warto wykorzystać to co jest. Jeśli Tebe pisze że ".PMG to zrzuty pamięci tablic wykorzystywanych przez G2F", to może zamiast wymyślać koło od nowa to jakoś inkorporować ten fragment kodu z g2fonta. W końcu po pierwsze ów plik pmg w g2f spełnia swoją role pozwala na zapis/odczyt duszków. Po drugie taki plik nie musi "ładnie" wewnętrznie wyglądać - ważne żeby spełniał swoją rolę. Owszem jeśli ilmenit opracuje nowy sposób, standard zapisu i dogada się z Tebe aby g2f potrafił go wczytać to piękna sprawa!, ale z obecnego tonu wypowiedzi ilmenita wnioskuje - mam nadziję że całkowicie błędnie - że ponieważ nie ma żadnego pliku w którym można zapisać duszki (poza pmg Tebego) to do czasu opracowania nowego standardu postępowanie w sprawie zostało zawieszone ;)
    A mając na uwadze tekst Kaz'a "Mamy 2010 rok, ponad 30 lat od powstania 8-bitowego Atari i nie doczekalismy sie formatu zapisu duszkow..." może minąć kolejne 30 lat i nic się nie zmieni.
    
    

    Kaz w odpowiedzi na tekst Mono:

    ... ale masz racje - ze format danych powinien uwzgledniac maksymalne mozliwosci manipulowania duszkami, a nie najczesciej wykorzystywane.
    

    
    
    Owszem ale pod jednym warunkiem a mianowicie jeśli owe maksymalne manipulowania duszkami okazałyby się zbyt kłopotliwe do stworzenia, to jestem za opcją najcześciej wykorzystywanych ustawień. Lepiej mieć coś niż nic. Lepiej mieć teraz niż za 5 lat.
    
    Kiedyś zdaje się około 2006 roku na forum Coreplayera (player wideo na szereg mobilnych platform) napisałem aby stworzyć możliwość czytania i wyświetlania napisów/subtiles, prostych z pliku txt. Kierujący firmą stwierdzili zdopingowani przez innych użytkowników (niech czyta pliku srt, pliki microdvd, pliki wewnętrznie w pliku mkv itd...) uznali że lepiej zamiast protezy zrobić do dobrze i całościowo.
    
    Do dziś CorePlayer nie czyta żadnych napisów. A mamy rok 2010.
    
    Nie chciałbym żeby i w tym wypadku duszków sprawa wyglądała podobnie.
32. • 32:
       
      CommentAuthorKaz
    • CommentTime16 Mar 2010 20:03

     
    Mamy 2010 rok, ponad 30 lat od powstania 8-bitowego Atari i nie doczekalismy sie formatu zapisu duszkow... No to chyba czas rozwazyc taki format, rzucic jakies propozycje.

    
    
    Irwin w tej sprawie zwrocil sluszna uwage, ze kiedys Mono przy okazji powstania swojego programiku do malowania duszkami w obszarze 64 pikseli stworzyl format MCE - niespecjalnie skomplikowany, gdzie zapisywane sa obszary duszkow (4 strony).
    
    Mono, nie badz skromny i pochwal sie formatem :)
33. • 33: CommentAuthormono
    • CommentTime16 Mar 2010 22:03 zmieniony

     
    Format .mce (mono color game graph engine) jest bardzo prosty i zakłada, że sprajty są skonfigurowane następująco:
    - wykorzystane są tylko playery,
    - ustawiony jest tryb multicolor,
    - ustawiona jest rozdzielczość jednoliniowa sprajtów,
    - playery mają szerokość x4.
    Żaden z missiles nie jest wykorzystany więc nie ma znaczenia player5.
    Jest to format roboczy do chwilowego zapisywania grafiki o rozdzielczości 64x192 piksele w trybie 12 BASICA (4 ANTIC) z playerami nałożonymi na siebie statycznie (od lewej: 0+1 i 2+3 zaraz obok co daje pokrycie właśnie 64 pikseli).
    
    Ekran składa się z 24 linii tekstowych trybu 4 ANTICa.
    W każdej linii wykorzystanych jest 16 znaków, co 4 linie na DLI przełączany jest generator znaków. Jak więc widać używa się tylko połowy generatora znaków. Sprajty zapisane są w zwyczajnej postaci.
    
    Format .mce:
    $0000..$00FF: Player 0
    $0100..$01FF: Player 1
    $0200..$02FF: Player 2
    $0300..$03FF: Player 3
    $0400..$05FF: Generator 0
    $0600..$07FF: Generator 1
    $0800..$09FF: Generator 2
    $0A00..$0BFF: Generator 3
    $0C00..$0DFF: Generator 4
    $0E00..$0FFF: Generator 5
    $1000..$100F: Linia 0
    ..
    $1170..$117F: Linia 23
    $1180: COLPM0/2
    $1181: COLPM1/3
    $1182: COLBAK
    $1183: COLPF0
    $1184: COLPF1
    $1185: COLPF2
    $1186: COLPF3
    ósmy kolor sam powstaje ze złożenia (funkcja OR) kolorów COLPM0/1 oraz COLPM2/3.
    
    Jak mówiłem nie jest to format elegancki - bardziej roboczy, więc nie uznałbym go za żaden standard i nawet nie chciałbym, żeby się standardem stał.
    W późniejszym czasie wprowadziłem sobie drugi format dla grafiki, który jest już nieco bardziej elegancki, ale z kolei nie odpowiada dokładnie możliwościom Atari - jest skonstruowany nieco na wyrost.
    Ponieważ w projektowanym edytorze można użyć 8 kolorów (5 kolorów trybu 4 ANTIC + 3 kolory sprajtów) postanowiłem zapisywać treść obrazu, jako bitmapę - w każdej połówce bajtu indeks użytego koloru (pikesle parzyste w starszej połówce, piksele nieparzyste w młodszej).
    
    Format .mc8 prezentuje się następująco:
    $0000..$001F: 1 linia zapisana od lewej do prawej
    ...
    $17E0..$17FF: 192 linia
    $1800: COLPM0/2
    $1801: COLPM1/3
    $1802: COLBAK
    $1803: COLPF0
    $1804: COLPF1
    $1805: COLPF2
    $1806: COLPF3
    
    Indeksy kolorów odpowiadają kolejno kolorom w pliku (7 to ósmy kolor powstały ze złożenia sprajtów).
    
    0: player 0/2 (COLPM0/2)
    1: player 1/3 (COLPM1/3)
    2: pixel %00 (COLBAK)
    3: pixel %01 (COLPF0)
    4: pixel %10 (COLPF1)
    5: pixel %11 (znak w normal - COLPF2)
    6: pixel %11 (znak w inverse - COLPF3)
    7: player 0/2+1/3 (COLPM0/2 OR COLPM1/3)
    
    Indeksy 8..15 są niewykorzystane.
    
    Ten format mógłby prędzej być wykorzystany, jako standard mimo że wymaga konwersji na postać "natywną" Atari. Pozwala też na zapis niemożliwych do wyświetlenia na Atari grafik :), bo używanie odpowiednich kolorów podlega ograniczeniom.
    1. Kolory 0,1,2 i 7 są zamienne w obrębie chunka 4x1.
    2. Kolory 3,4 mogą być użyte swobodnie na całym obszarze.
    3. kolory 5 i 6 są zamienne w obszarze chunka 4x8.
    Jak więc widać nie wszędzie można wyświetlić piksele o kolorach 0,1,2,7 czy 5,6 obok siebie.
    
    Dzięki temu, że używana jest tylko połowa generatora, drugą połowę można wykorzystać do rysowania grafiki już w 4 kolorach na reszcie ekranu (czyli poza obszarem 64 pikseli w każdej linii). Ponieważ "tryb" ustawia sprajty statycznie a DLI używa tylko do przełączania generatorów znaków, nie zabiera prawie w ogóle czasu procesora dzięki czemu można realizować podczas wyświetlania transmisję I/O, czy grać muzykę.
    
    Dość łatwo można ten "tryb" rozszerzyć do obszaru 80x192 pikseli (w pionie można mieć nawet 240 linii) wykorzystując 4 dodatkowe znaki w każdym wierszu (po 16 w każdym zestawie znaków) oraz missiles nałożone na siebie parami analogicznie, jak playery.
    
    Aktualnie można prostym edytorem projektować sobie grafikę i zapisywać/odczytywać ją z dysku (w załączniku). Nie mam opracowanych procedur do wykorzystania we własnych produkcjach.
    Wymyśliliśmy taki tryb z MaW'em 2 lata temu podczas przygotowań do prac nad jego grą, ale z mojej winy zarzuciliśmy prace.
    
    Wracając do tematu: nie chciałbym, żeby stało się to standardem, ponieważ jest to format wewnętrzny stworzony na potrzeby edytora, nierozszerzalny (brak nagłówków, informacji o rozdzielczości itp.), a nie rzecz uniwersalna pozwalająca na wykorzystanie możliwości Atari.
    
    Edit: Mam nadzieję, że Ilmenit się nie pogniewa za lans ;) w jego wątku.

    • mceng9.obx
34. • 34:
       
      CommentAuthorMaW
    • CommentTime16 Mar 2010 22:03 zmieniony

     
    Hehe, skądś znam ten edytor... ;-)
    
    Mono, kiedy ruszamy ponownie ?
35. • 35:
       
      CommentAuthorKaz
    • CommentTime23 Oct 2010 15:10

     
    Quantizator i Graph2Font zostaly wykorzystane do zrobienia... demka (no, slideshow) na konsoli Atari 7800. Pliki do sciagniecia w tym watku:
    
    ->link<-
36. • 36:
       
      CommentAuthorKaz
    • CommentTime20 Apr 2012 11:04

     
    Quantizator zmienil nazwe na RastaConverter?
37. • 37: CommentAuthorilmenit
    • CommentTime20 Apr 2012 11:04

     
    RastaConverter to napisany od nowa program.
38. • 38: CommentAuthorw1k
    • CommentTime21 Apr 2012 14:04

     
    what setting for Q is best for making pictures?
39. • 39: CommentAuthorKonop
    • CommentTime21 Apr 2012 15:04 zmieniony

     
    Swego czasu podsyłałem Kazowi szablonowy dokument opisujący dane sprite'ów bazujący na XML. Być może na forum pozostał tego jakiś ślad.
    
    Aktualizacja. Udało mi się go znaleźć na dysku.

    • Format.g2fsprt
40. • 40: CommentAuthortebe
    • CommentTime22 Apr 2012 01:04

     
    w RastaConver przydała by się opcja wyłączająca z użycia wybrane rejestry, np. rejestr $d016 w liniach 112:200, albo $d000 itp.
    
    z myślą o wykorzystaniu takiego obrazka na potrzeby gry, dema, kiedy wybrany kolor zostanie wykorzystany na scroll lub tym podobne efekty
41. • 41: CommentAuthortebe
    • CommentTime22 Apr 2012 15:04

     
    spróbowałem przełożyć jeden z obrazków SergeantSeymour na program rastra G2F, optymalizacje typu ładowanie rejestru w poprzedniej linii i zapisywanie w kolejnych oraz inne skróty nie pozwalają tego zapisać w uporządkowanej wersji G2F
    
    podobnie ma się sprawa z obrazkami generowanymi przez PGR
    
    potrzebny byłby właśnie taki tryb -PGR- tylko dla rastra, z tym że oznaczałoby to brak możliwości używania okien EDIT COLORS i EDIT PMG, wszelka edycja polegała by na ręcznym dłubaniu w programie rastra, albo użyciu EDIT PALETTE
    
    innym wyjściem jest zmiana koncepcji Ilmenita i podzielenia programu rastra jak robi to G2F, tak aby EDIT COLORS i EDIT PMG mogły funkcjonować
42. • 42:
       
      CommentAuthorKaz
    • CommentTime22 Apr 2012 19:04

     

    Konop:

    Swego czasu podsyłałem Kazowi szablonowy dokument opisujący dane sprite'ów bazujący na XML. Być może na forum pozostał tego jakiś ślad.

    
    
    Ja zas stwierdzilem, ze najlepszymi odbiorcami tego byliby Ci, ktorzy tworza narzedzia graficzne dla Atari: Tebe, Dearhorse, moze autor Timanthesa. To by pozwolilo wytworzyc pewien standard danych i wymieniac grafike miedzy narzedziami.
    
    Ale zdaje sie Konop pracujesz jeszcze nad ostateczna wersja tego dokumentu?
43. • 43: CommentAuthorKonop
    • CommentTime23 Apr 2012 10:04

     
    W najbliższym czasie nie planuję jego rozwijania. Można go wykorzystać w obecnej formie.