GED
From Atariki
(Różnice między wersjami)
| Wersja z dnia 11:57, 20 lip 2006 KMK (Dyskusja | wkład) ← Previous diff |
Aktualna wersja Dracon (Dyskusja | wkład) |
||
| Linia 1: | Linia 1: | ||
| - | {{SDP}} | + | Edytor graficzny autorstwa [[John Harris|Johna Harrisa]] (autora także np. asemblera [[MAE]]), służący do podkolorowywania atarowskiej grafiki w [[Graphics 15|15. trybie Basica]] (160x200 pikseli) z użyciem łączenia przerwań [[DLI]] i grafiki [[PMG]] czyli popularnych [[duszki|duszków]]. Wykorzystywał także nowatorską (jak na czasy powstania - przełom lata 80 i 90. XX w.) technikę ''dzielenia rastra'' celem uzyskania więcej niż 4 różnych kolorów w jednej linii ekranu (maks. 9 kolorów). Co ważne, tak podkolorowana grafika nie drażniła oczu jakimkolwiek "miganiem" (tak jak to było w trybie [[interlace]]), gdyż takie właśnie były założenia autora. GED był niezbyt łatwy w obsłudze i być może z tego powodu używało go niewielu grafików na scenie: [[Dracon]], [[Titus]], [[Vidol]]. Mimo wszystko umożliwiał uzyskanie odpowiednich efektów szybciej niż w konkurencyjnym [[PowerGraph]]. |
| - | '''GED''' - edytor graficzny autorstwa [[John Harris|Johna Harrisa]] (autora także np. asemblera [[MAE]]), służący do podkolorowywania atarowskiej grafiki w [[Graphics 15|15. trybie Basica]] (160x200 pikseli) z użyciem łączenia przerwań [[DLI]] i grafiki [[PMG]] czyli popularnych [[duszki|duszków]]. Wykorzystywał także nowatorską (jak na czasy powstania) technikę ''dzielenia rastra'' celem uzyskania więcej niż 4 różnych kolorów w 1 linii ekranu (maks. ok. 9 kolorków). Co ważne, tak podkolorowana grafika nie drażniła oczu jakąkolwiek "migawą" (tak jak to było w trybie [[interlace]]), gdyż takie właśnie były założenia autora. GED był niezbyt łatwy w obsłudze i być może z tego powodu używało go niewielu grafików na scenie: [[Dracon]], [[Titus]], [[Vidol]]. Mimo wszystko umożliwiał uzyskanie odpowiednich efektów szybciej niż w konkurencyjnym [[PowerGraph]]. | + | |
| - | Na temat tego programu do podkolorowywania grafiki najwięcej napisał Dracon (instrukcja użytkowania - w [http://ftp.pigwa.net/stuff/collections/atari_forever/www-magazines/ENERGY1/gedinfo.htm ENERGY #1] oraz [http://ftp.pigwa.net/stuff/collections/atari_forever/www-magazines/ENERGY2/ged21.htm ENERGY #2 (cz.1)]/[http://ftp.pigwa.net/stuff/collections/atari_forever/www-magazines/ENERGY2/ged22.htm (cz.2)]) oraz [[Jaskier]] (przeglądarka plików GED - ang. ''viewer'' - poniżej). | + | Na temat tego programu do podkolorowywania grafiki najwięcej napisał Dracon (instrukcja użytkowania - w [http://ftp.pigwa.net/stuff/collections/atari_forever/www-magazines/ENERGY1/gedinfo.htm ENERGY #1] i [http://ftp.pigwa.net/stuff/collections/atari_forever/www-magazines/ENERGY2/ged21.htm ENERGY #2 (cz.1)]/[http://ftp.pigwa.net/stuff/collections/atari_forever/www-magazines/ENERGY2/ged22.htm (cz.2)]) oraz [[Jaskier]]. |
| - | <pre> | + | == Zobacz także == |
| - | '''GED viewer''' | + | * [[RastaConverter]] |
| - | Wielu z Was zapewne słyszało o pewnym programie graficznym, zwanym skrótowo GED. Napisany | ||
| - | został on w 1993 roku przez Johna Harrisa. Jest to program, który pod względem możliwości | ||
| - | graficznych znajduje się gdzieś w pierwszej piątce wszystkich programów graficznych na Atari. | ||
| - | Również pod względem ilości wbudowanych opcji ten program znajduje się w pierwszej piątce, tyle | ||
| - | że od tyłu. | ||
| - | |||
| - | Jednak, mimo braku nawet najbardziej elementarnych opcji, program jest szeroko używany przez | ||
| - | grafików różnych maści. Jest to spowodowane tym, że program udostępnia chyba najwięcej (na oko | ||
| - | jakieś 20%) możliwości graficznych Atari, spośród wszystkich innych programów graficznych. | ||
| - | |||
| - | Pomysł, aby nie tylko zmieniać kolory co linię, ale również w jej środku, a ponadto dodać | ||
| - | pełnię możliwości PMG, oddzielne dla każdego ghosta kolory i szerokości, priorytety i inne | ||
| - | zabawki, jest wspaniały. Naprawdę wielkie brawa dla Johna Harrisa. | ||
| - | |||
| - | Ach, gdyby nie ta zapierająca dech obsługa. | ||
| - | |||
| - | Program niestety ma również inną wadę, ujawniającą się niestety najpóźniej, bo już po | ||
| - | narysowaniu całego obrazka. Do programu mianowicie nie dołączono procedury, którą można by | ||
| - | umieścić we własnym programie, aby pokazać w nim własny obrazek narysowany w GED-zie. Tą | ||
| - | niedogodnością jakiś czas temu zaciekawił mnie Dracon/USG/Taquart. Poprosił mnie mianowicie (po | ||
| - | tym jak odmówił mu Konop i paru innych koderów) o napisanie takiej procedury, gdyż potrzebował jej do swojego (planowanego) slideshowu. Po przejrzeniu GED-a za pomocą wszystkich dostępnych mi debuggerów (z których każdy niestety pokazywał to samo) zabrałem się do pracy. | ||
| - | |||
| - | Oto wynik moich poszukiwań. (Pełny tekst programu znajduje się w zarchiwizowanym pliku (dołączonym do magazynu ENERGY) jako GEDVIEW.ASM.) | ||
| - | |||
| - | Dane program trzyma od adresu $5330, do adresu $7f4f. Zapisywane jest to jednym ciągiem w | ||
| - | formacie DOS-owym to znaczy z bajtami $ffff, $5330, $7f4f na początku. | ||
| - | |||
| - | Zmieniając adres danych można zmieniać tylko pierwszą cyfrę, gdyż Antic ma głupi zwyczaj dane obrazka pobierać tylko z czterech kilobajtów. | ||
| - | |||
| - | Kilka linii przed początkiem obrazka zaczyna się przerwanie. Jest ono docyklowane z | ||
| - | dokładnością do 0.001 cykla, tak więc należy zwracać uwagę na to, że: | ||
| - | |||
| - | Mój program został przystosowany do umieszczenia na początku strony. Wszelkie zmiany tego | ||
| - | położenia, a także wszelkie zmiany w programie mogą zmienić położenie pętli umieszczonych w | ||
| - | przerwaniu. Pętla, której początek i koniec znajdują się na dwu różnych stronach może znaleźć | ||
| - | się na jednej stronie, a tym samym rozkaz skoku na początek pętli (bpl) będzie działać o 1 cykl | ||
| - | krócej. Należy również uważać na to, że display list musi znaleźć się cały w jednym kilobajcie. | ||
| - | Ponadto zaraz za programem należy zostawić 10KB wolnego, gdyż umieszczany jest tam program | ||
| - | przerwania generowany dopiero po uruchomieniu mojej procedury. | ||
| - | |||
| - | Oto skrócony opis programu, dla tych, którzy chcieliby poznać sposób, w jaki pokazuje się | ||
| - | obrazki z GED-a. | ||
| - | |||
| - | Najpierw opis danych: | ||
| - | |||
| - | Osiem tablic po 200 bajtów zawiera dane zmian kolorów itp. robionych co linię: -tb2, tb3, tb4, | ||
| - | tb5, tb6, tb7, tb8, tb9- dane ośmiu zmian kolorów w linii, kolejno: kolor 1, 2, 3, 1, 2, 3, 1, | ||
| - | 2. | ||
| - | |||
| - | Oprócz tych zmian można dokonywać również co linię jednej ze zmian w ghostach (kolor, szerokość | ||
| - | itp.) lub koloru tła. Wartości tych zmian zawiera tablica tb0, zaś komórki, które trzeba | ||
| - | zmieniać tablica tb1. | ||
| - | |||
| - | -dane- szesnaście komórek: | ||
| - | -0,1,2,3 - kolory wpisywane do $d012-$d015 | ||
| - | -4- szerokości playerów (po dwa bity od najstarszych wpisywane do $d008-$d00b), | ||
| - | -5- szerokości missilów ($d00c), | ||
| - | -6- priorytety ($d01b), | ||
| - | -7- kolor missilów (do $d019), | ||
| - | -8- kolor tła ($2c8 lub $d01a), | ||
| - | -9,10,11,12- położenia poziome graczy (komórki od $d000 do $d003), | ||
| - | -13- położenie poziome pierwszego missila, do pozycji następnych dodawana jest szerokość | ||
| - | poprzedników, | ||
| - | -14- numer opóźnienia przerwania i tym samym miejsca zmiany kolorów. W GED-dzie ustawia się to | ||
| - | klawiszami [,] i [.]), | ||
| - | -15- nieużywane. | ||
| - | |||
| - | -obr1,obr2- dane obrazka podzielone na dwie części z powodu pewnej wady Antica. | ||
| - | |||
| - | A teraz opis kilku części programu: | ||
| - | |||
| - | lda >pmg-$300 pierwsze 3 strony nie są | ||
| - | sta $d407 używane, więc stąd ten adres. | ||
| - | |||
| - | lda <end Generuje początkowe | ||
| - | sta addr bajty umieszczane za | ||
| - | lda >end etykietą END. Najpierw | ||
| - | sta addr+1 na podstawie dane+14 | ||
| - | lda dane+14 umieszczane są 4 bajty, | ||
| - | asl @ które nic nie robią, ale | ||
| - | asl @ dają różne opóźnienie. | ||
| - | adc #3 Owe czwórki bajtów | ||
| - | tax umieszczone są pod | ||
| - | ldy #3 etykietą proc3. | ||
| - | s1 lda proc3,x | ||
| - | sta (addr),y | ||
| - | dex | ||
| - | dey | ||
| - | bpl s1 | ||
| - | |||
| - | Teraz adres jest zwiększany o 4: | ||
| - | lda <end+4 | ||
| - | sta addr | ||
| - | lda >end+4 | ||
| - | sta addr+1 | ||
| - | i dalej będzie procedura generująca 200 | ||
| - | razy prog. zmieniający kolory w każdej linii. | ||
| - | (Jest za długa aby ją tu umieszczać.) | ||
| - | Składa się ona ze zwykłego przepisania | ||
| - | wartości z tablic, tak aby przerwanie nie | ||
| - | marnowało czasu na długie rozkazy typu: | ||
| - | lda tb4+175 | ||
| - | ale zadowalało się rozkazami typu: | ||
| - | lda #$16 | ||
| - | (wartość $16 została wcześniej pobrana z | ||
| - | tablicy tb4+175). Zysk: 1 cykl. | ||
| - | Każdy fragment przerwania kończy się | ||
| - | rozkazem inc 0, które nie ma niczego robić, | ||
| - | ale tylko zająć 5 cykli, tak aby czas | ||
| - | tworzenia 1 linii przez Antic był równy | ||
| - | czasowi wykonywania tego fragmentu | ||
| - | przerwania przez procesor. Jednakże, | ||
| - | pamięć obrazka została podzielona na dwie | ||
| - | części i kiedy Anticowi podaje się do żarcia | ||
| - | tę drugą część (w dliście wygląda to jak: | ||
| - | dta b($4e),a(obr2)), to procesor ma o 2 | ||
| - | pla cykle mniej czasu. | ||
| - | clc Należy więc zmienić ten | ||
| - | adc #1 rozkaz na lda 0, który | ||
| - | cmp #$66 zajmuje 3 cykle. | ||
| - | bne s4 Ten program rozpoznaje | ||
| - | pha właściwy wiersz i | ||
| - | dec addr+1 dokonuje drobnej zmiany | ||
| - | ldy #$fe (bajt $a5) w już wygene- | ||
| - | lda #$a5 rowanym fregmencie | ||
| - | sta (addr),y programu. | ||
| - | inc addr+1 | ||
| - | pla | ||
| - | s4 cmp #$c8 a tu sprawdza, czy to już | ||
| - | bne s2 wszystkie linie. | ||
| - | ldy <proc3-proc2 z kolei tutaj | ||
| - | s5 lda proc2,y generowana jest | ||
| - | sta (addr),y procedura | ||
| - | dey wyjścia z | ||
| - | bpl s5 przerwania. | ||
| - | |||
| - | lda dane+5 Ten fragment programu | ||
| - | ldx #0 jest o tyle ciekawy, że | ||
| - | ldy #$ff wykorzystany jest tutaj | ||
| - | s6 iny nic nie robiący rozkaz | ||
| - | s7 lsr @ bit $4a. Kiedy jednak | ||
| - | bcc s9+1 wykonamy skok w bajt | ||
| - | lsr @ stanowiący operand $4a | ||
| - | bcc s8 to wykona się rozkaz | ||
| - | inx lsr @. Pozwala to znacznie | ||
| - | inx skrócić program. Polecam | ||
| - | inx tę sztuczkę każdemu. | ||
| - | inx Ten fragment akurat | ||
| - | s8 inx dokonuje ustawienia | ||
| - | inx położeń pocisków na | ||
| - | s9 bit $4a podstawie dane+5 oraz | ||
| - | inx ich szerokości. Ponieważ | ||
| - | inx to nieistotne część | ||
| - | pha programu wyrzuciłem: | ||
| - | (......) | ||
| - | pla (akurat tę zapisującą | ||
| - | cpy #3 już wartości) i zostawiłem | ||
| - | bne s6 wyjście z pętli. | ||
| - | |||
| - | Teraz rzecz najgorsza, czyli programy | ||
| - | pracujące w przerwaniach. Na początek | ||
| - | procedury przepisywane. (Patrz wyżej.) | ||
| - | -PROC1 to procedura wygenerowywana 200 | ||
| - | razy. Była już o niej mowa wcześniej. | ||
| - | -PROC2 to procedura kończąca przerwanie. | ||
| - | -PROC3 zawiera kilka 4-bajtowych procedur | ||
| - | służących ustawieniu (z dokładnością do 1 | ||
| - | cyklu) miejsca zmian kolorów. Kazda 4-ka | ||
| - | bajtów różni się czasem wykonywania. | ||
| - | -DL tu się zaczyna przerwanie. Zwykłe | ||
| - | ustawianie wartości itp. Jedyny ciekawy | ||
| - | fragment to: | ||
| - | ldx #11 ciekawy dlatego, że nic nie | ||
| - | dex robi. Chodzi tutaj jedynie o | ||
| - | bne *-1 przeczekanie trochę cykli | ||
| - | lda (0,x) aż sprawa nie przycichnie... | ||
| - | lda 0 tfu... co ja mówię!!! | ||
| - | |||
| - | end equ * od tego miejsca wpisywane | ||
| - | są poszczególne procedury: 4 bajty wzięte | ||
| - | z PROC3, następnie 200*PROC1, a w końcu | ||
| - | PROC2. | ||
| - | Ostatnia linia w programie wygląda tak: | ||
| - | end | ||
| - | |||
| - | Jest to najważniejszy rozkaz w programie. Jak twierdzi pewna dobrze obeznana z tym osoba, każdy | ||
| - | dobrze napisany program kończy się tym rozkazem, po czym można poznać, że programista skończył | ||
| - | pracę, a nie usnął w jej trakcie. | ||
| - | |||
| - | Jak widziecie metoda pokazywania obrazków stworzonych GED-em (gadem?) jest dość prosta. | ||
| - | </pre> | ||
| - | |||
| - | {{stub}} | ||
| [[Kategoria:Oprogramowanie Atari 8-bit]] | [[Kategoria:Oprogramowanie Atari 8-bit]] | ||
| [[Kategoria:Formaty plików]] | [[Kategoria:Formaty plików]] | ||
| + | [[Kategoria:Programy graficzne]] | ||
Aktualna wersja
Edytor graficzny autorstwa Johna Harrisa (autora także np. asemblera MAE), służący do podkolorowywania atarowskiej grafiki w 15. trybie Basica (160x200 pikseli) z użyciem łączenia przerwań DLI i grafiki PMG czyli popularnych duszków. Wykorzystywał także nowatorską (jak na czasy powstania - przełom lata 80 i 90. XX w.) technikę dzielenia rastra celem uzyskania więcej niż 4 różnych kolorów w jednej linii ekranu (maks. 9 kolorów). Co ważne, tak podkolorowana grafika nie drażniła oczu jakimkolwiek "miganiem" (tak jak to było w trybie interlace), gdyż takie właśnie były założenia autora. GED był niezbyt łatwy w obsłudze i być może z tego powodu używało go niewielu grafików na scenie: Dracon, Titus, Vidol. Mimo wszystko umożliwiał uzyskanie odpowiednich efektów szybciej niż w konkurencyjnym PowerGraph.
Na temat tego programu do podkolorowywania grafiki najwięcej napisał Dracon (instrukcja użytkowania - w ENERGY #1 i ENERGY #2 (cz.1)/(cz.2)) oraz Jaskier.
[Edytuj]
