Działam sobie na CC65. Pod tym linkiem jest program testowy grafiki: ->link<- Program się nie kompiluje bo brakuje mu funkcji "graphics" :( Po zamianie "graphics" na "_graphics" jest przez krótką chwilę tryb tekstowy (niebieski ekran) a potem czarny ekran (chociaż powinien wyświetlić się tekst).
Czy są jakieś możliwości robienia grafiki na CC65 dla Atari? (nie chodzi mi o taką grafikę jaka jest pod tym linkiem ale żeby była w ogóle, taka jak w Atari Basicu). Setcolor własnoręcznie napisany działa w trybie tekstowym:
#include <peekpoke.h> void setcolor(int reg, unsigned short int hue, value) { POKE(708+reg, hue*16+value); } // tak, wiem, zamiast "int reg" powinno być "unsigned char reg"
Sprawdzałem jeszcze _graphics(0); - też powoduje czarny ekran, nawet jak po jego wywołaniu zmieniam kolory przy pomocy setcolor i piszę tekst komendą printf.
Oj, ja niewiele tu pomogę. W ogóle nie bawiłem się atarowską biblioteką do cc65 - do BrainFucka nie było mi to potrzebne ;-) A poza tym C jest dla mnie zbyt niskopoziomowym językiem i bardzo niewygodnie się w nim operuje na danych tekstowych - więc przeniosłem się parę pięter wyżej ;) Zamiast POKE() możesz spróbować użyć wstawki assemblerowej:
__asm__("lda %w",710); __asm__("sta %v",kolor); (dla zdefiniowanego z góry adresu)
albo wskaźników:
static int adr; //adres komórki pamięci ... adr = 708 + reg; *(char *) adr = hue*16+value; (dla adresu ustalanego dynamicznie)
PS. Właśnie z powodu tych gwiazdek dałem sobie spokój z C ;-P
Jeszcze dźwięki mnie interesują (takie jak generowane przy pomocy basicowego SOUND), bo nie znalazłem nic sensownego we wbudowanych plikach *.h w katalogu include.
No tak, w sumie mało na temat odpisałem ;) Wydaje mi się, że - jeżeli chcesz programować naprawdę niskopoziomową grafikę, np. gry zręcznościowe - najlepiej byłoby napisać sobie własny, dopasowany do potrzeb zestaw procedur w assemblerze ca65. W którymś Bajtku z '92 był artykuł z kilkoma prostymi procedurkami graficznymi - w zasadzie niewiele, ale zerknąć warto.
PS. Co do dźwięków, to również w którymś Bajtku ('91?) były procedury dźwiękowe w asmie.
na tej stronie nie znalazłem przykładów programów z grafiką dla atari. Zauważyłem że do kyan pascala są dołączone procedury graficzne - wszystkie w asemblerze :) Czy dałoby radę je wykorzystać w cc65? co do samodzielnego pisania to dla mnie asembler atarowski w porównaniu z pecetowskim to czarna magia.
Moze niezbyt dokladnie sie wyrazilem: tam nie ma jakis specjalnych przykladow dla Atari, ale sa sposoby wykorzystania grafiki w CC65 oraz link do materialow dla Atari: ->link<- ->link<-
a tam jest napisane, ze: "Currently there are no graphics drivers available for the Atari platform. However, the runtime library provides a function named _graphics, with a mode parameter just like the BASIC GRAPHICS command. This function will switch to the requested graphics mode. There are currently no functions available to access the graphics memory. The access must be implemented manually."
Nie znam kompletnie CC65, ale nie wyglada to dobrze ;).
adiblol: A kto mówi o samodzielnym pisaniu? ;-) Ja mówiłem o gotowych procedurach w asmie - poszukałem i znalazłem graficzne w Bajtku 11'92; tak jak mówiłem: same podstawy (PLOT, DRAWTO itp.), ale zawsze to coś na początek. Dźwiękowych nie znalazłem, czyli albo są w którymś ze starszych Bajtków, albo w TA - tam w ogóle znajdziesz sporo gotowych procedur w assemblerze. W cc65 możesz korzystać z plików .obj skompilowanych w dowolnym języku, ale szczerze wątpię, żeby Kyan Pascal dawał kompatybilny kod... Spróbować zawsze można - importowane funkcje deklarujesz słowem "external". W sprawach związanych z architekturą cc65 możesz też - tak jak napisał Kaz - skontaktować się z Fox'em.
PS. Jeszcze mi coś przyszło do głowy: jeżeli chcesz mieć niskopoziomowe procedury rysujące i znasz tryb graficzny, w którym będziesz rysował, to nie trzeba przecież używać asma. Odwołujesz się bezpośrednio z C do pamięci ekranu, za pomocą konstrukcji *(char *) adr = wartosc. W ten sposób, jeżeli poszukasz odpowiednich algorytmów w Sieci, w gazetach, książkach czy gdzie tam jeszcze, możesz mieć dowolne procedury: rysowanie elipsy, flood fill, blitter i co tylko chcesz :)
W opisie jezyka jest napisane, ze dziala. Sam tez napisales, ze Ci dziala, bo przelacza w odpowiedni tryb graficzny. Ale potem masz:
"There are currently no functions available to access the graphics memory. The access must be implemented manually"
Czyli jest tak, jak napisales - nie mozesz nic narysowac. Bo zadna z zaimplementowanych funkcji nie ma dostepu do pamieci ekranu graficznego. To tak na chlopski rozum.
Kiedy wszystko zawiedzie, przeczytaj instrukcję ;) Kaz podał Ci linka, do dokumentacji: ->link<-
Many graphics modes require more memory than the text screen which is in effect when the program starts up. Therefore the programmer has to tell the program beforehand the memory requirements of the graphics modes the program intends to use. This can be done by using the __RESERVED_MEMORY__ linker config variable. The number specified there describes the number of bytes to subtract from the top of available memory as seen from the runtime library. This memory is then used by the screen buffer.
Czyli gdy chcesz użyć gr. 15 to w atari.cfg musisz ustawić __RESERVED_MEMORY__ minimalnie na 7120.
Napisano tam tak: "Many graphics modes require more memory than the text screen" co oznacza "Wiele trybow graficznych wymaga wiecej pamieci niz tryby tekstowe", a nizej jest tabelka i tam masz, ze musisz zdeklarowac:
graphics mode reserved memory 0 1
A nizej wytlumaczenie, dlaczego nalezy rezerwowac ten jeden bajt: "The values of "1" are needed because the graphics command crashes if it doesn't have at least one byte available. This seems to be a bug of the Atari ROM code." co oznacza "Wartosc "1" jest potrzebna, poniewaz komenda graphics wysypuje sie, jezeli nie ma dostepnego przynajmniej jednego bajtu. Prawdopodobnie jest to blad w ROM-ie Atari".
Jeżu... bo nie potrafisz czytać ze zrozumieniem? Dalej z powyższego linka: The values of "1" are needed because the graphics command crashes if it doesn't have at least one byte available. This seems to be a bug of the Atari ROM code.
Dobra. Wiem co trzeba zrobić, trzeba dodać do konfiguracji linkera opcję __RESERVED_MEMORY__ o wartości zależnej od trybu graficznego. Skąd mam wziąć plik konfiguracji linkera? Pisanie go samodzielnie mnie przeraża... napisali na oficjalnej stronie cc65 że powinien być w katalogu doc, nie ma go tam...
A może jest jakiś sposób na ustawienie opcji __RESERVED_MEMORY__ bez tworzenia pliku konfiguracji linkera (wtedy po prostu można użyć opcji "-t atari" a nie "-C atari.cfg")
Możesz go znaleźć w źródłach linkera, czyli w archiwum ftp://ftp.musoftware.de/pub/uz/cc65/cc65-sources-2.12.0.tar.bz2 w katalogu cc65-sources-2.12.0.tar\cc65-2.12.0\src\ld65\cfg\atari.cfg
dźwięki działają, wystarczyło POKE na rejestry POKEYa. Atariki bardzo pomogły :) Co do grafiki to na pewno nie będę korzystał z trybów OSu tylko display list.
Hej, Podłączę się pod temat, gdyż "zaprototypowałem" sobie nową gierkę w CC65 i właściwie poszło tak łatwo, że wolałbym ją dokończyć w CC65 niźli przepisywać to wszystko do ASM, zwłaszcza, ze nawaliłem tam wskaźników, wielopoziomowych tablic i sporo algebry :/
Prosiłbym praktyków CC65 o info czy nie napotkam problemów np. z odgrywaniem muzyki RMT albo integrowaniem obrazków tytułowych, itp.?
