na początku ostrzegam - ostatni raz pisałem coś na Atari jakieś 15-16 lat temu ;)
pomyslałem o małym odswieżeniu zabawy a Turbo Basic XL. O ile 1 projekt po kilku problemach udało się ukonczyć, to w drugim natrafiłem na coś z czym nie pamiętam jak sobie poradzic.
skrótowo sprawa wygląda tak:
oczywiście spodziewałem się wyswietlenia listy wyrazów / i teraz gdzie jest błąd? przy odczycie danych, czy też sam sposób zapisu jest już nieprawidłowy?
Niby wszystko bezbłędnie, ale... w linii 6, gdzie zapisujesz informacje wyczytane z DATA, zamiast przecinka daj średnik. O ile się nie mylę, przecinek w takiej sytuacji zapisywał TABa w pliku, co powoduje zwiększenie się ilości danych do wczytania (a 10 bajtów/znaków na to nie wystarcza) Eksperymentalnie :D zwiększyłem rozmiar zmiennej A$ do 32 i... wyszło szydło z worka :D Powodzenia w przypominaniu Turbo Basic'a.
Błąd nr 137 (za Zientarą): "Odczytany rekord miał długość większą od długości przenaczonego dla niego bufora".
Instrukcja INPUT była raczej stworzona do pracy w innych warunkach ;-) i pozwala na odczyt danych o długości do 253 znaków (+1 bajt oznaczający długość +1 bajt oznaczający koniec danych, co daje 255 bajty informacji ==> tak myślę, choć nie mam pewności, co do tych dodatkowych 2 bajtów). Do zapisu i odczytu dużej ilości danych na urządzeniu zewnętrzym w Atari Basic należy raczej korzystać z pary instrukcji PUT/GET, a w Turbo-Basic XL wygodniejszych BPUT/BGET.
1. Dzięki. Z tego co sprawdziłem instrukcjami put/get bput/bget nie zapiszę/odczytam zmiennej tekstowej a$. Może niezbyt elegancko, ale udało mi się obejść problem zapisując/odczytując a$ po 160 znaków.
2. W jednym z numerów TA, był artukuł nt. odbioru map meteorologicznych nadawanych drogą radiową przy pomocy Atari - w programie do obsługi przystawki był bardziej elegancki sposób zapisu/odczytu plików graficznych. Pozostaje tylko kwestia czy istnieje jakiś inny ultra szybki sposób przetworzenia obrazka na daną a$ (taką jak podałem w przykładzie)?
ad. 1 zapis: OPEN #1,8,0,"D:TEST.DAT" BPUT #1,ADR(A$),L CLOSE #1
odczyt: OPEN #1,4,0,"D:TEST.DAT" BGET #1,ADR(A$),L CLOSE #1
gdzie L to oczywiście zmienna L z programu
ad. 2 Jeśli chodzi o zapis/odczyt danych obrazu (i innych), to wcale nie ma potrzeby konwersji obrazka do zmiennej tekstowej. Tu spokojnie możesz zapisać i odczytać bezpośrednio dane obrazu. Twój program wyglądałby tak: 1 GR.15 2 C.2:PAINT 0,0 3 C.1:CIRCLE 80,80,75 4 C.3:CIRCLE 40,40,35 : CIRCLE 120,120,35 5 O.#1,8,0,"D2:TEST.PIC": BPUT#1,DPEEK(DPEEK(560)+4),7680:CL.#1 6 GR.0 :? "NO TO NACISNIJ SPACJE": GET KL 7 GR.15 8 O.#1,4,0,"D2:TEST.PIC": BGET#1,DPEEK(DPEEK(560)+4),7680:CL.#1
pisane z pamięci bez sprawdzania, ale powinno działać :) dodatkowa zaleta: plik zajmuje 7680 bajtów, a nie 25 tys.
W takim razie odczyt/zapis mamy już z głowy. A teraz wyjasnienie dlaczego uparłem na zapis obrazka jako danej tekstowej. Napisałem sobie taką pierdołę (plik w załączniku). I pomyślałem że przerobie to na wersję z obrazkiem, plansza 8x8, czyli 64 klocki (wieksze klocki podczas ruchu mogłyby się rysować za długo). Ponieważ puki co nie wymylśiłem nic lepszego, dane graficzne klocka chcę pobierać jako fragment danej a$, i wyświetlać to poprzez PRINT #6,a$.
Zmień generator znaków, czyli w miejsce standardowych nieużywanych znaków wstaw wzór grafiki klocka i wyświetlając obraz w trybie tekstowym używaj normalnego POSITION x,y: PRINT "twój_znaczek" (x,y z rodzielczością "znakową") lub w trybie graficznym TEXT x,y,"twój_znaczek" (x,y z precyzyjną rodzielczością punktową).
---- edit:
W programie dodałem tylko jedną linię nr 0 oraz spreparowany zestaw znaków w pliku ZNAKI.FNT na dyskietce. Aby za wiele nie zmieniać w programie, to podstawiłem grafikę pod cyfry 2-9, więc licznik czasu pokazuje nam teraz głupoty, ale chodziło mi tylko o pokazanie zasady działania.
Na początku własnie myślałem o wygenerowaniu odpowiednich znaków. Poźniej wymyśliłem sobie, że obrazek z trybu 15 (160x160x4) podzielę sobie na 64 klocki, do których będę miał dostęp poprzez zmienna a$ czyli ciąg 25600 znaków odpowiadających kolorom pixeli obrazka.
poprzez procedurkę:
10 for a=0 to 19 20 klocstart=(nrklocka*20-19)+160*a: klockoniec=klocstart+20 30 pos. xgracza*20,ygracza*20+a: print #6;a$(klocstart,klockoniec): next a
mogłbym sobie rysować poszczególne klocki (rozmiar klocka 20x20 pixeli), czyli fragmenty obrazka.
Nistety widzę ze nic z tego nie będzie - po zarezerwowaniu tablic a(7,7) b(7,7) i a$(25600) włączenie trybu grafiki 15 powoduje brak pamięci ;)
Teraz wpadłem na inny pomysł. O ile pamiętam, było coś takiego jak technika "page fliping" do robienia animacji. Czy w moim przypadku dałoby się w tej technice przechowywać gdzieś w pamięci gotowy obrazek (niewidoczny) i jakiś sposób pobierać jego fagmenty (klocki) i wyświetlać w różnych miejscach ekaranu w trybie 15?
Tak. Dane obrazka można sobie przechowywać, gdzie tylko chcesz. Znajdź wolny obszar w pamięci i załaduj tam dane, a później odczytuj. Ta metoda nie ma za dużo wspólnego z techniką animacji, o której wspomniałeś, ale można to zrobić. Nie będzie to jednak zabójczo szybkie. Szczególnie w Basicu. Zrób klocki ze znaków! W takim przypadku ich szerokość i wysokość nie będzie zupełnie dowolna, bo musi to być wielokrotność rozmiaru znaku, ale wygoda użycia i szybkość wyświetlania bez porównania! Zamiast klocka 20x20 byłby 16x16 lub 24x24.
OIDP page flipping byl opisany w "Atari Basic" wraz z przykladowym programem. Zreszta przyda Ci sie ta ksiazka jako lektura wlasnie takich zapomnianych podstaw:
Może czegoś nie rozumiem.. ale jak chce zrobić puzzle w trybie gr.15 (160x160x4kolory) - odpowiednik w trybie znakowym to wydaje mi sie tryb gr.12 20x20 znaków w 4 kolorach. Z tego co pamietam mozna zdefiniowac 128 własnych znaków. 20x20=400 znaków do zdefiniowania to troszkę za dużo.
Wracając do Page Flipping - seria obrazków wyświetlała sie bardzo szybko dając złudzenie animacji, a działało to w basicu. Nie da się zrobić tak, aby w dowolnym miejscu ekranu równie szybko wyświetlał się dowolny fragment obrazka ukrytego w pamięci?
ps. dobrze że na początek zrobiłem te puzzle w trybie tekstowym, gromadzące się problemy potrafią niezle zniechęcić - a tak mam już coś grywalnego ;)
ps2. Dzięki KAZ.. zerknąłem do "Atari Basic" i już wiem dlaczego Page Flipping nie nadaje się do puzzli.
teraz pomysły mam 2:
1. ustalenie adresu pamięci ekranu, wczytanie obrazka do innego obszaru pamięci. przenoszenie klocków jako fragmentów pamięci obrazka na ekran za pomoca komendy MOVE.
2. ściagnałem taki programik G2F. O ile dobrze zrozumiałem to programik przerobi mi plik BMP na fonty Atari - czy takiech fontów mogę w jakiś sposób uzyć w moich puzzlach?
To co widzimy na ekranie w G2F faktycznie jest wyświetlane na znakach, ale wykorzystanie tego programu do zamiany grafiki na fonty w celu użycia ich we własnym programie jest raczej problematyczne.
jeśli chodzi o pkt. 1 pomysłu 2 ;) to dobry kierunek :)
Od biedy można już zagrać w nowe Puzzle ;) (obrazek do ułożenia jest totalnie beznadziejny - kratka i kilka kółek narysowane komendami basic'a, taki do sprawdzenia czy to w ogóle działa)
lista co chciałbym zrobić: - kilka "ładnych" obrazków - funkcja SAVE (ułożenie puzzli z 64 klocków to już nie taka prosta sprawa) - muzyczka CMC (tylko do tego formatu mam player w basicu) - o ile wystarczy pamięci, podgląd ułożonego obrazka pod przyciskiem FIRE - ładowanie palety kolorów do każdego obrazka
na koniec kolejny problem: po ok. 10min zaczynąją się zmieniac losowo kolory ekranu, pomaga dopiero wciśnięcie klawisza.. da się jakoś temu zaradzić??
Dobre! Tymi kratkami mnie zastrzeliles :), to trudniejsze niz obrazki. Jezeli moge cos podpowiedziec, to zrob po prostu ladowanie dowolonych obrazkow z dysku. W sieci znajdziesz troche grafik w standardowym trybie, ktore mozna by tu sobie ukladac.
To losowe zmienianie kolorow ekranu po 10 minutatch i 52 sekundach to tryb przyciagania uwagi (Attract Mode). Tutaj mozesz o tym przeczytac wiecej i szczegolowiej: ->link<- (patrz punkt 3.1.3)
ad. 1 W wiekszosci przypadkow nie tracisz nic cennego, a taka opcja dawalaby szersze pole do popisu graczom.
ad. 2 Obrazki w AIS sa konwertowane do trybow istniejacych na Atari, z ktorych zadny nie ma standardowo 160x160. Wiec lepiej moim zdaniem uzyc do tworzenia plikow MIC innego programu "G2F". Wczytujesz obrazek pecetowski, ustalasz, ktore wiersze zostawiasz (tak, zeby bylo 160 pikseli w pionie - 20 wierszy) i zapisujesz jako MIC. Jak bedziesz mial jakis problem jak to zrobic to pisz tu smialo, wytlumacze szczegolowo.
1.Puki co nie wiem jak MIC wczytać pod Turbo Basic. Od biedy wczytując MIC 160x192 po prostu 32 ostatnie linie nie były by wyświetlane w puzzlach.
edit: ok, moje puzzle bez problemu wczytują plik MIC, obcinając ostanie linie (zamiast 7680B wczytują 6400B), muszę zrobić jeszcze coś aby w takim wypadku wczytywała się paleta kolorów z pliku
2.W tym g2f bede mógł usunąć dowolne linie, czy tylko zbędne ostatnie 32?
ps. widzę, że w tym G2F ładnie się konwertuje BMP 160x160
Plik MIC to sa czyste dane obrazu plus kilka bajtow informacji o kolorach (spotkalem sie, ze byly zarowno na poczatku pliku jak i na koncu - u TeBego jest to chyba na koncu, ale glowy nie dam, bo w tej chwili nie pamietam). MIC wczytywal (o roznej wysokosci) Sikor w grze Sssnake - moze podpatrz tam procedury?
ad.2
Tak, mozna usuwac dowolne wiersze, wiec obrazek moze byc w dowolnym miejscu na wysokosc, reszte z gory lub z dolu mozna usunac. Jezeli zostawisz 20 wlaczonych wierszy to przy zapisie MIC bedziesz mial te 20 wierszy. Jezeli 22 - to MIC bedzie mial 22.
Plik ALIEN.MIC (był razem z G2F) wczytuje się ładnie do puzzli (oczywiscie pomijając ostatnie linie) razem z paletą kolorów. Przy próbie odczytu pliku mario.mic (link do pliku post wyżej, plik utworzony w G2F) nie ważne czy podam długość pliku 7680, czy też 6400 paleta kolorów ustawia się na 0 (nic nie widać), niezaleznie od tego czy kolory chce wczytać z początku czy też konca pliku.
Mono - to co opisuje Atariki moze bylo kiedys aktualne, ale nie obecnie. Format MIC ewoluowal, chyba glownie dzieki G2F, ktory po prostu pozwala zapisac MIC jako dane aktualnego obrazu plus kolory. Niezaleznie od tego czy jest to szerokosc 48, 40 czy 32 bajty, niezaleznie od tego ile wierszy wysokosci. Wiec wspolczesny MIC niekoniecznie musi miec 7680 bajtow.
tbxx - jezeli chodzi o ten Twoj plik przygotowany przez G2F to zacznijmy od tego, ze ma on 9604 bajty, bo zapisales wiecej niz 160 pikseli wysokosci. Skoro kolory sa na koncu, to trudno, zeby po 7680 czy 6400 bajtach byly dane kolorow :). Obrazek w tym miejscu jest pusty (zera) wiec odczytujesz zera.
Graph2Font operuje na wierszach, poniewaz pierwotnie byl to program do zamiany grafiki na zestawy znakow.
Zeby pozbyc sie niechcianych wierszy trzeba je wylaczyc. Jezeli widzisz po lewej stronie obrazka takie cyferki w dwoch rzedach - to drugi rzad oznacza tryb graficzny, w jakim jest dany wiersz (1 - hires, 2 - lowres, 3 - GTIA mode). 0 - oznacza ze wiersz jest wylaczony. Tak wiec Twoim zadaniem jest wylaczyc wiersze ustawiajac wszedzie 0. Zostawiasz wlaczone (status - 2) tylko te 20 wierszy, ktore Ci potrzebne. 20 wierszy razy 8 pikseli to 160 pikseli.
Czy ten obrazek jest mieszany w taki sposób, że istnieje 100% możliwość ułożenia go? Czy może jest to losowa mieszanka i nie ma pewności, że z tego da się przywrócić początkowy obrazek?
2. Generator ułożenia klocków jest malutką modyfikacją tego z wersji tekstowej (z 9 klockami). Wersja tekstowa operowała na tablicy 3x3, graficzna ma poszerzoną do 8x8.
3. Klocki na 100% się nie powtarzają, i każdy klocek na 100% możemy ustawić w dowolnym miejscu ekranu.
4. Obrazek najlepiej zacząc układać od zgrupowania potrzebnych klocków w kwadracie 3x3 na dole po prawej stronie, i układać partiami 3x3 przesuwając się najpierw w lewo, a póżniej w górę ekranu. Pusty klocek zawsze na koncu znajduje się w lewym górnym rogu ekranu.
5. Układanie puzzli z dołączonym testowym obrazkiem to raczej dość masochistyczne zajęcie ;) Lekko modyfikując linie programu od 2000 do 2040 możemy sobie wczytać dowolny obrazek w formacie MIC (z tym ze ostatnie 32 linie bedą obcięte)
Pisales, ze chcesz rozdzielczosc 160 pikseli czyli 20 wierszy, a masz ustawione w tym obrazku 25 wierszy czyli 200 pikseli. No to oczywiste, ze G2F zapisze nie tylko wiecej niz 6400 bajtow (160x160 pikseli), ale nawet wiecej niz 7680 bajtow (160x192), skoro masz 160x200.
Przychodzi mi jeszcze na mysl cos z ustawieniami Windowsa, bo niektorzy zglaszali takie zachowania, ale w Windows Vista i Windows 7. Nowa wersja G2F, nad ktora pracuje TeBe ma rozwiazac te problemy. Ja mam jednak to samo co Ty i zadnych problemow z zapisem nigdy nie mialem i nie mam.
a po wczytaniu wszystkie 0 są ustawione na 2.
No tak, bo nie wczytujesz obrazka G2F, ktory "nadpisuje" wszystko co bylo na ekranie, tylko MIC, ktory jest traktowany jako ewentualna skladowa obrazka i jest "dopisywany" do ekranu. Po prostu natywnym formatem dla Graph2Font jest G2F, a MIC to tylko format uzupelniajacy, ulatwiajacy wlasnie wymiane danych.
Najwyraźniej mój Windows w duecie z G2F coś świruje ;) nawet jak pozostawiam aktywną 1 linię to obrazek zajmuje 9600B.
Jak kilkanascie lat temu robiłem program graficzny, to wydaje mi się, że miałem tam taki bajer: W dowolnym trybie graficznym ponad obrazkiem była linia w trybie gr.1 w której wyswietlało się tekstowe menu programu.
teraz pytania: - czy da się takie coś zrobić (czy mi się tylko wydaje) - jeśli tak to jak ;)
Tak, da sie. Poszczegolne wiersze ekranu moga byc w roznych trybach graficznych (wskazanych lista ktora sie nazywa Display List) i to jest wlasnie ogromna zaleta Atari. Jezeli szukasz sposobow modyfikacji DL to jest to rozlegle zagadnienie, ale wielokrotnie opisywane, wiec nie powinno byc problemow z wyguglaniem szczegolow.
Im dłużej siedzę nad tymi puzzlami tym więcej nowych pomysłów. Tak, że kosmetyka typu obrazki,stona tutułowa, muzyczka zeszły na dalszy plan...
Pierwotna koncepcja zakładała 10 obrazków do ułozenia po kolei, z funkcją save zapisującą nr.puzzli,czas gry, oraz tablicę rozmieszczenia klocków.
Na chwilę obecną plan jest taki:
1.Po stronie tytułowej (której jeszcze nie ma), wyświetli się lista pierwszych 10 plików MIC z dyskietki i będziemy mogli wybrać sobie obrazek do ułożenia (tak, że odpadnie funcja save)
2. W obrazkach zazwyczaj pojawiają się duże obszary w jednym kolorze, w związku z czym powstają identycznie wyglądające klocki - pomyślałem, że można zastąpic podgląd wyświetlania gotowego obrazka (fire) wyświetleniem nr.klocków
3. Ponieważ układ 8x8 klocków to lekki hardcore, myslę aby dorobić 2 dodatkowe poziomy trudnośći: 8x4 klocki oraz 4x4 klocki - z tym że większe klocki będa się wolniej kasowac/wyświetlac.
edit ;) w załączniku najnowsza wersja beta gry, z jednym z powyższych usprawnień. Ponad to w pliku EFECTOR.BAS znajduje się próbna wersja strony tytułowej.
- numery klocków nie wyświetlają się prawidłowo - przez głupi błąd w procedurze sprawdzającej poprawnosc ułożenie klocków, nie wyświetla się napis informujący o tym fakcie
błedy poprawione, tym razem nie udostepniam "bety"... chyba ze natrafie na problem z którym nie będe mógł sobie poradzić;)
Puzzle powiedzmy że są na ukończeniu, tym razem natrafiłem na poważniejszy problem.
Kod gry to ok.6,5kB
Teraz tak, ustalam adres ekranu EKRAN=DPEEK(88), W pamięci EKRAN-8192 jest przechowywany gotowy obrazek, z którego pobieram klocki. W pamięci EKRAN-16384 jest przechowywny aktualny ekran planszy gry podczas wyświetlania podpowiedzi.
Problem polega na tym że chciałem dodać muzyczkę CMC.. i raczej na nią nie ma już pamieci. Była na Atari jakaś gra wydana bodajże przez Mirage - odpalona na 64kB nie miała muzyki, a na 128kB muzyczka grała. Czy da się takie coś zrobić w Turbo Basic XL z muzyczką CMC?
Razem z Sikorem w naszych wspólnych bojach z TB, CMC i nie tylko, przy braku dostatecznej ilości pamięci, robiliśmy zwykle taki trik, że dane "nadmiarowe" dawaliśmy zwykle tam, gdzie później była grafika, a na początku programu robiliśmy MOVE np. na $a00 (2560 dziesiętnie). Trzeba było tylko przygotować pliki CMC i REP zapisane na ten adres (inne dane zwykle nie potrzebowały jakiegoś specjalnego zapisu). No i jeszcze ustawiać jakaś komórkę gdzies na początko, żeby program potem żadnych "śmieci" nie przeniósł tam, gdzie znajdują się już przeniesione dane. Wadą tego rozwiązania jest to, że z gry/programu nie ma już wyjścia do DOSa, ale czy jest sens wracać. Zaleta jest taka, że spokojnie do adresu $1fff (8191 dziesiętnie), można sobie trzymać, co się żywnie podoba. Jak coś napisałem zbyt niejasno, pytaj śmiało. :)
Akurat podczas gry potrzebny jest dostęp do dysku. Pomyślalem że dane grafiki zajmują 6400B, a ja rezerwuje pod to 8192B, więc nad EKRAN-8192 i EKRAN-16384 jest troszke miejsca. W jedno wcisnąłem music.rep a w drugie music.cmc niby wszystko jest ok ale po skomilowaniu gra wywala się przy odpalaniu muzyki - wersja nieskompilowana chodzi z muzyką bez problemu.
