Niezalogowany (Zaloguj się)

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

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

Taka tam nowa gra

Od 1 do 50 z 101

- 1: CommentAuthorBluki
- CommentTime25 Jul 2011 zmieniony
Taka tam gra, ale nowa moja gra...

64 FIGURY

Oglądaj online: 64 figury

Zasady są proste: trzeba umieścić 64 figurki na właściwych miejscach, według wskazówek i jak najszybciej.
Nie będę się wdawał tu w szczegóły, gdyż znajdują się one w opisie gry. Jeśli jest to pierwsze uruchomienie to wystarczy nacisnąć START, aby przeczytać opis.
Gra niestety nie będzie działać z magnetofonu. Wymaga stacji dysków, rzeczywistej lub wirtualnej.
No chyba, że mamy DOS na kartridżu i przynajmniej 128kB RAM. Wtedy można 64 figury „odpalić” z RAM-DYSKU.
- 64 figury.7z
- 2: CommentAuthorgorgh
- CommentTime26 Jul 2011
nie jestem fanem takich gierek, ale wygląda porządnie i olskulowo
- 3:
  
  CommentAuthorgreymsb
- CommentTime26 Jul 2011
to co powiedział Gorgh :) 3mam kciuki za kolejne projekty!
- 4:
  
  CommentAuthorxeen
- CommentTime26 Jul 2011 zmieniony
fajny pomysł, ale trochę ciężko się steruje, czy nie da rady zrobić podświetlenia całej figury? Pasek jest mało widoczny (moje subiektywne zdanie).
warto też chyba gierkę skompilować celem przyspieszenia.
- 5: CommentAuthorBluki
- CommentTime26 Jul 2011
Z podświetleniem całej figury byłby problem, głównie z powodu formatu pola 11*22 piksele. Zapewne nie udałoby się uzyskać właściwej płynności. I czy pulsująca cała figura wyglądałaby dobrze? Poza tym nie może być zbyt łatwo...
Dodam,że gra ma 5 kolorów, a używa 4. kolorowego trybu graficznego (BASIC 15). PMG robi za piąty kolor.
Co do kompilacji, to przyspieszenie nie byłoby znaczne, ze względu na wykorzystanie PLOT, DRAWTO i POKE, które to są już same w sobie procedurami maszynowymi. Widoczne przyspieszenie byłoby tylko podczas rysowania planszy. Gra jednak nie była pisana "pod kompilator" i prawdopodobnie po kompilacji nie będzie działać poprawnie.
Poza tym znowu te godziny testowania :)
- 6: CommentAuthorZza_parawanu
- CommentTime26 Jul 2011
Luźne skojarzenie: czy nie ma jakichś alternatyw dla PLOT, DRAWTO, etc? Można by napisać szybsze (może specjalizowane) procki maszynowe uruchamiane przez USR. Te domyślne są powolne chyba właśnie dlatego, że uniwersalne. Taka biblioteczka pomogła by autorom gier.
- 7:
  
  CommentAuthorxeen
- CommentTime26 Jul 2011
a nie można użyć dwóch duszków?
z płynnością nie będzie żadnego problemu pod warunkiem wykorzystania dedykowanej procki. pod tbxl polecam

->link<-

do prostych rzeczy bez multipleksacji wystarcza...
- 8: CommentAuthormarok
- CommentTime26 Jul 2011
Bardzo miła rzecz.
Nie wiem czy dałbym rzeczywiście radę i czy starczyło by mi wytrwałości, ale gdyby powstał pomysł "przepisania" gierki na asma celem nadania jej większej płynności to mógłbym spróbować pomóc (o ile ktoś sprawniejszy pokroju Xxl nie wyrazi zainteresowania tym samym).

To jest gra pomysłu własnego czy na czymś wzorowana?
- 9:
  
  CommentAuthorCOR/ira4
- CommentTime26 Jul 2011
osobiście z każdej nowej gry na XL/XE się cieszę (może i nawet bardziej niż z nowości wychodzących na PS3[bywają wyjątki....potwierdzające ....] )
- 10: CommentAuthorBluki
- CommentTime26 Jul 2011
xxl:
wpisalem sie dwa razy na hiscore, gdzie mozna obejrzec liste wynikow?

Nie ma oddzielnej listy. Po wybraniu poziomu gry (np. beta 2 wyświetla się najlepszy uzyskany rezultat dla tego poziomu.

sa jakies reguly oprocz tych z kolorami?

Nie, chyba że za zmianę zasad przyjmiemy poziom gamma.

adv, marok:
Czy to pomysł własny autora?

Tak. Chociaż niektórzy twierdzą, że w przypadku gier wszystko już było...

trumphil :
Grafika jak na TBXL chyba niezła?

TBXL może więcej. Potrzebny jednak byłby grafik.

xeen:
a nie można użyć dwóch duszków?

Wszystkie „siły” PMG są zaangażowane do utworzenia piątego koloru - żółtego. Playery 0-3 obsługują pierwsze cztery kolumny pola gry, a missile 0-3 następne cztery kolumny. Aby wygospodarować jednego playera trzeba by ograniczyć liczbę kolumn do 7, czyli do 56 lub nawet 49 figur. A tego nie chciałem.
- 11: CommentAuthorBluki
- CommentTime26 Jul 2011 zmieniony
Xeen: link ciekawy. TBXL posiada instrukcje umożliwiające płynne przesuwanie PMG w dowolnym kierunku (MOVE, -MOVE), ale ten program, jak zauważyłem upraszcza ten problem.
- 12:
  
  CommentAuthoradv
- CommentTime26 Jul 2011
Rzeczywiście jest to zatem NOWA gra. Jeśli mógłbym podpowiedzieć:

1) Umieściłbym imię i nazwisko autora programu i podał dane kontaktowe, żeby było wiadomo kto jest podmiotem osobistych praw autorskich.
2)Zastrzegłbym, choć to jest oczywiste, że robienie przeróbek programu na platformę, na którą zastał napisany lub jego opracowań w postaci wersji programu na inne platformy, bez zezwolenia autora jest zabronione.

Ochroną objęty może być wyłącznie sposób wyrażenia. Jeśli ktoś napisze nowy program oparty lub dokładnie kopiujący ten pomysł na tą samą bądź inną platformę, wolno mu. Będzie on traktowany jako autor swojego programu.

@Bluki Gratulacje!
- 13:
  
  CommentAuthorxeen
- CommentTime27 Jul 2011 zmieniony
Wszystkie „siły” PMG są zaangażowane do utworzenia piątego koloru - żółtego. Playery 0-3 obsługują pierwsze cztery kolumny pola gry, a missile 0-3 następne cztery kolumny. Aby wygospodarować jednego playera trzeba by ograniczyć liczbę kolumn do 7, czyli do 56 lub nawet 49 figur. A tego nie chciałem.

tak, błędnie założyłem, że gra nie jest w trybie bitmap. w trybie znakowym piąty kolor (inverse) masz prawie że za free.
- 14: CommentAuthorBluki
- CommentTime29 Jul 2011
Początkowo planowałem użyć trybu znakowego, 5 kolorów idealnie by pasowało. Ale pole gry nie jest wielokrotnością bajtu. Znaki musiałyby być „łamane” w różnych miejscach. A jeszcze tekst po prawej stronie, w porywach w trzech kolorach. Dwa - trzy zestawy znaków plus operacje na pojedynczych bitach przy zmianie figury... Uznałem że lepiej będzie, pomimo straty jednego koloru, zastosować tryb graficzny, w którym nie występują takie ograniczenia jak w trybie znakowym - w tworzeniu grafiki.

Dzięki za życzliwe przyjęcie gry. Po krytycznych wypowiedziach na temat „Space Harriera” spodziewałem miażdżącej krytyki, a tu – o! Jednak nic straconego. Przy następnej grze... :)

A przy okazji: na fotkach w poście #1 znajdują się elementy z podtekstem „książkowo – filmowym”. Czyżby nikt tego nie zauważył... Może jednak?
- 15:
  
  CommentAuthorbobikowoz
- CommentTime29 Jul 2011
Ronja - córka zbójnika mnie się z dziecinnymi bajkami kojarzy :)
- 16: CommentAuthorBluki
- CommentTime30 Jul 2011
I o to chodziło. Ronja i Birk to bohaterowie powieści dla dzieci Astrid Lindgren "Ronja, córka zbójnika". Powstał też film i musical, ale nie ma gry na Atari :(
- 17: CommentAuthorQTZ
- CommentTime4 Aug 2011 zmieniony
Bluki Gratuluję!
Gra się bardzo przyjemnie (mój wynik na alfa 1: 406p ;)). Gra przypomina mi MatchBoxes z uwagi na grafikę w dobrym, starym stylu :)

Mam jednak kilka uwag:
- Co do listy rekordów rzeczywiście byłoby lepiej gdyby do każdego "poziomu" było np. pięć wpisów - najlepszy widoczny jak jest, z ostatniej gry i pozostałe po wybraniu.
- Gdy figury są takie same nie ma potrzeby ich rysowania (choć jest to jedyny efekt wybrania pól) mam wrażenie, że w zależności od figury gra się szybciej lub wolniej, co stwarza nierówne szanse
- W związku z powyższym warto by było dodać np. dźwięki przy wybieraniu i zatwierdzaniu
- Wpisywanie imienia:
- zatwierdzenie przyciskiem /Start/ - niewygodne i trzeba się domyśleć - brak info
- brak możliwości cofania przy wpisywaniu imienia (lewo, prawo) - można dodać zatwierdzanie np. na końcu linii
- Zapis punktów mógłby się odbywać po wpisaniu imienia automatycznie, bo z tego, co napisałeś dzieje się to tylko przy wyjściu
- Przy wyjściu można nacisnąć break ponownie - jeszcze w czasie dźwięku. Odblokowanie reset/break powinno być na końcu
- I to, czego zazwyczaj mi brakuje w grach z rekordami to możliwość miksowania rekordów dwóch graczy (tu z dwóch dyskietek)

Co do przyspieszenia rysowania grafiki to można ją zrobić na czcionce i wyświetlać tak jak tekst zamieniając aktywny font.
Figur jest w sam raz tyle, aby zmieścić je na jednym foncie - 64 figury każda 16x16, ale ponieważ tryb 4 kolorowy - wychodzi 8x16, czyli 2 znaki na figurę, co daje 128 znaków (pełny font - jeden znak się powtarza). W trybie graficznym i tak nie ma to specjalnego znaczenia, ale jest wygodniejsze w użyciu ;)
Ponieważ program jest w pewien sposób zabezpieczony (o czym poniżej) napisałem niezależny programik :) - w załączniku listing z czcionką i osobna czcionka, abyś mógł ew. dołączyć po swojemu :) Znaki są tak poukładane, że pierwsze 64 to górne części figur, a kolejne 64 to odpowiadające im dolne części (kolejność figur jest inna, bo zrobiłem ze screenshot'a nie znając oryginalnej kolejności).

Pytania:
Jak rozwiązałeś to, że dane do rysowania, czcionka i help są umieszczane w pamięci? Czy wymaga to dodatkowych narzędzi? I gdzie zapisywane są rekordy? Jak je skasować? Rozumiem, że są dołączane do pliku gry? Bo po zmodyfikowaniu lub tylko ponownym zapisaniu "save" gra nie może siebie odnaleźć (jest uszkodzona - prosi o podanie dysku i error) mimo, że jest na dysku :) Prawdopodobnie można dopisać linie i zapisać przez list pod inną nazwą zachowując oryginalny program, a później dograć je (E.) i uruchomić. Nie analizowałem dokładnie kodu... ale zauważyłem, że użyłeś losowania podobnego jak wymyśliłem na potrzeby statków :)
Czy używanie "%" zmniejsza zajmowaną pamięć przez liczbę, bo zauważyłem, że dość często tego używasz, czy może ma to inne znaczenie?
W Basic'u W.Z. stosował przypisanie Q1=1 i dalej używał Q1, etc.

Edit:

"%" znalazłem (to są stałe i mają taką rolę jak przypuszczałem).

Z czcionką (TEXT) nie jest tak prosto jak mi się wydawało, bo nie można ustawić koloru tła, ani nakładać tekstu na tło bez jego czyszczenia i znowu dochodzą operacje na bitach lub zamalowywanie... W prasie były publikowane różne programy typu textplot czy 80 znaków w wierszu, może któryś z nich okaże się pomocny... jeszcze się zastanowię i poszukam... a może ktoś spróbuje wyciągnąć i "poprawić" komendę TEXT z TB do postaci USR() lub wskaże komórki które należy zmienić, aby tekst był nakładany inaczej...
- 64FigurySpeedFontListing.7z
- 18: CommentAuthorBluki
- CommentTime5 Aug 2011 zmieniony
QTZ:
Co do listy rekordów rzeczywiście byłoby lepiej gdyby do każdego "poziomu" było np. pięć wpisów...

Na pewno byłoby atrakcyjniej, ale nie spodziewałem się takiego zainteresowania grą. Jest to na przyszłość nauczka: czy gra się podoba czy nie, jeśli jest wpisywanie rekordów, to bardziej rozbudowana tabela nie zaszkodzi.

Gdy figury są takie same nie ma potrzeby ich rysowania (...) W związku z powyższym warto by było dodać np. dźwięki przy wybieraniu i zatwierdzaniu

Jednak jest potrzeba rysowania. Zmiana tła kasuje figurę i trzeba ją ponownie odtworzyć. Poza tym brak reakcji optycznej mógłby wprowadzać w błąd. No i kwestia zachowania zasad wyświetlania dla wszystkich poziomów.
Z dźwięku, w tym momencie gry, świadomie zrezygnowałem. Niekiedy irytowało mnie to, że w grze słyszę po raz 198 ten sam dźwięk... Zastosowałem „subtelniejszy” wskaźnik: pierwsza figura wybrana do zamiany jest zaznaczona niemigającym kursorem.

mam wrażenie, że w zależności od figury gra się szybciej lub wolniej, co stwarza nierówne szanse

Rzeczywiście, czas potrzebny do narysowania figurki zależy od jej złożoności. Wyrównanie tego wymagałoby rozbudowania procedury rysującej (wyliczenie czasu), a problem uznałem za mało istotny. W życiu też przecież nie ma równych szans :)

zatwierdzenie przyciskiem /Start/ - niewygodne i trzeba się domyśleć - brak info
- brak możliwości cofania przy wpisywaniu imienia...

W czasie gry wytwarza się nawyk, że naciśnięcie fire powoduje zamianę. Dlatego nie zastosowałem tego przycisku do zatwierdzenia imienia – odruchowe naciśnięcie fire mogłoby zakończyć wpis zbyt wcześnie.
Rzeczywiście, nie ma bezpośredniej wskazówki co do naciśnięcia START. Jedak w „Jak grać” widnieje: START – wykonaj polecenie. Pewnie należało to ująć precyzyjniej, ale chciałem aby instrukcja była możliwie zwięzła i nie „straszyła” rozmiarem. Może na przyszłość należałoby dołączać plik tekstowy ze szczegółowym opisem?
Jest możliwość cofnięcia wpisu – klawiszem ESC. Zmiana znaku wewnątrz jest problematyczna, powodowałaby znaczną rozbudowę procedury, a przecież to tylko 8 znaków. Problem polega na tym, że wykorzystywane jest polecenie TEXT Turbo BASIC-a, a znaki mają szerokość 4. pikseli (czyli dwa na bajt). Wpisanie „w środku” znaku wykasuje też następny znak po prawej. Trzeba by „odświeżać” cały tekst.

Zapis punktów mógłby się odbywać po wpisaniu imienia automatycznie, bo z tego, co napisałeś dzieje się to tylko przy wyjściu

Tak. Początkowo miało to się odbywać każdorazowo po uzyskaniu rekordu. Pojawił się jednak problem związany ze stacją dysków. Po pierwsze, trzeba by chwilę zaczekać, aż zapis się dokona. Po drugie, w przypadku gdy zapis nie jest możliwy, to o ile mój TOMS 720 radził sobie z tym w miarę sprawnie, to CA 2001 potrzebowała kilkunastu sekund na zwrócenie komunikatu błędu (nie wiem jak to jest np. z SIO2SD). A w tym czasie nic się nie działo (z punktu gracza). Dlatego uznałem, że zapis na końcu będzie lepszym rozwiązaniem. Zdecydowana większość użytkowników ma wyrób komputeropodobny, zwany pecetem, więc jest przyzwyczajona do zamykania programów...
Odblokowanie reset/break powinno być na końcu

I początkowo było. Jednak ze względu na powyższe problemy ze stacją dysków zostawiłem „furtkę” dla niecierpliwych.

...to można ją zrobić na czcionce...

No, sam zauważyłeś, że nie byłoby to takie proste. Ja też :) Albo przeliczanie bitów, czyli obliczenia z użyciem potęgowania, albo trzy dodatkowe generatory znaków plus czwarty wykonawczy, a jeszcze litery i cyfry, w „porywach” w trzech kolorach... Uff. Tryb graficzny nie ma takich ograniczeń. Prawda, tekstowy ma jedną zaletę: szybkość rysowania znaków.
Przerysowywanie figur ma też swój „smaczek”. Szybka zamiana powodowałaby, że figury by „przeskakiwały”, a tak są „przenoszone”.

Pytania

Jeśli dobrze zrozumiałem:.
Cały program składa się z dwóch części połączonych w jedną całość. Pierwsza to program w TBXL, a druga to dane.
Blok danych zaczyna się nazwą wersji, potem znacznik (bajt #255), dalej dane rekordów (90B), modyfikowane przez program główny. Dalej m. in. dane figur, generator znaków, 3B do konfiguracji menu po uruchomieniu, ekran gry i ekran „Jak grać”. Dwie ostatnie pozycje są wczytywane w obszar pamięci obrazu opcjonalnie (są to jakby „zrzuty ekranu”).
„Czy wymaga to dodatkowych narzędzi?” – Mogłbyś to pytanie rozwinąć?
Rekordy zapisywane w obszarze pamięci określonym zmienną REK, a po użyciu BREAK przepisywane bezpośrednio do pliku gry dzięki nieocenionym :) poleceniom POINT i BPUT.
Kasowanie rekordu tylko pojedynczo (dla każdego poziomu oddzielnie) – patrz użycie klawisza ESC w „Jak grać?”.

Gry nie da się skopiować poleceniem LOAD/SAVE. Musisz do tego użyć programu kopiującego lub DOS-a (opcja C -MyDos). Błąd odczytu może też nastąpić jeśli uruchamiasz grę np. z napędu #2, a masz ją zapisaną również w #1. Powodem jest to, że napęd domyślny to #1, dopiero jak tam się program „nie odnajdzie” to prosi o wskazanie numeru napędu. Ponieważ fizycznie (zwykle) na obu dyskach plik zajmuje różne miejsca, to dane konfiguracyjne będą błędne.

Nie wiem czy to wystarczy. Jeśli masz QTZ dalsze pytania to dawaj je i dzięki za dobre słowo :) i uwagi, przydadzą się jak nie teraz, to przy następnych produkcjach (jeśli będę miał jakiś pomysł na grę).
- 19: CommentAuthorQTZ
- CommentTime5 Aug 2011 zmieniony
Dziś udało mi się zmodyfikować program i "podejrzeć" kolejność figur ;) W tym celu zapisałem zmodyfikowany plik FIG64A.TB przez SAVE i dograłem do niego dane z pierwotnego pliku :) (26248 Bajty). Inaczej program nie znajdował się nawet jeżeli zmodyfikowałem go wyłącznie w pamięci?! Mimo różnicy w wielkości, nowy plik TB działa :) (nie przewidziałeś, że wylosują się wszystkie znaki już ułożone, ale na szczęście na listę w ten sposób się dostać nie można :)). W tym celu użyłem kilku programów na PC. Jest to dość uciążliwy sposób na edycje. Stąd moje pytanie o narzędzie, jak i z ciekawości - jak dołączyłeś te dane. W jaki sposób poprawnie zapisać 64 Figury z poziomu TB bez takich kombinacji?

Mimo, że czcionka nie rozwiązuje problemu "podświetlania" można jej użyć w innych przypadkach - po wybraniu "poziomu" plansza (także przykładowa) rysuje się dość długo (za długo!), więc tu byłoby to wskazane (poprawiłem kolejność znaków, tak, aby się zgadzały z kolejnością figur w grze i zamieniłem podmienione części serca i karo). Eksperymentalnie mógłbyś spróbować wyświetlać wszystkie figury z fonta także w czasie gry, a "podświetlone" na zielono i niebiesko rysować jak dotychczas na tle, tyle, że też z czcionki, tylko, że w odpowiednim kolorze w inverse (efekt wypełniania figury). Jeżeli chodzi o efekt rysowania, który nadaje fajny klimat (też się obawiam o jego stratę) można spróbować zamieniać znaki po połówce z użyciem inverse w tym samym kolorze (inaczej nie da to efektu przy takich samych figurach). Przy okazji kolejna uwaga - nie można odznaczyć błędnie wybranej figury - trzeba ją zamienić, wygodniej by było gdyby ponowne wciśnięcie odblokowywało kursor (po wykryciu puszczenia i ponownym wciśnięciu fire).

Chętnie zobaczyłbym to rozwiązanie w działaniu, więc mam nadzieję, że umieścisz je w kolejnej wersji :)

Dalej warto by było spróbować napisać podprogram umożliwiający manipulację na bitach konkretnych figur bezpośrednio na ekranie - najlepiej zamieniający linie należące do wybranych figur. Nie trzeba do tego używać potęg (bardzo powolne), wystarczą mnożenie *2 *.5, operacje logiczne &, ! i ew. EXOR. Trzeba ustalić, które bajty zajmuje figura w linii (8 możliwości - 2-3 bajty w linii na figurę) i przy użyciu odpowiednich masek (aby nie modyfikować fragmentów sąsiednich figur, ramki i bitów koloru, który tworzy figurę) dokonać odpowiednich modyfikacji (przesunięcie i ew. dodanie "podświetlenia") i tak samo (bajty ustalamy raz) dla 16 linii każdej z zamienianych figur i już :) To dałoby efekt zamiany figur linia po linii (np. z dołu do góry, na przemian, etc.. Nie wiadomo tylko czy napisane w TB byłoby odpowiednio szybkie...

Innym sposobem - łatwiejszym jest napisanie programu operującego na fragmencie linii jak wyżej, ale tylko "dorysowującego" zielone lub niebieskie "podświetlenie" (lub figurę na "podświetleniu"). Jak mi starczy determinacji to spróbuję taki podprogram napisać.

Edit:
Jeszcze innym, najprostszym sposobem jest użycie LOCATE i PLOT :)
- 64FiguryOnFontFixed.7z
- 64FiguryOnFontLocatePlot.7z
- 20: CommentAuthorBluki
- CommentTime7 Aug 2011
QTZ:
Inaczej program nie znajdował się nawet jeżeli zmodyfikowałem go wyłącznie w pamięci?!

Program do określenia początku danych na dysku używa rejestru DAUX (778, 779). Normalnie, po uruchomieniu części w TBXL, wskazuje on (w uproszczeniu) na początek danych, które następnie zostają pobrane z dysku. W efekcie DAUX zmienia wartość i teraz wskazuje (również w uproszczeniu) na początek „Jak grać?”. Jeśli teraz wykonasz RUN, to te wskazanie zostanie przyjęte jako początek danych. I katastrofa gotowa.

nie przewidziałeś, że wylosują się wszystkie znaki już ułożone

W testach losowały się najwyżej 4 figury na swoim miejscu, więc uznałem problem za nieistotny.

plansza (także przykładowa) rysuje się dość długo (za długo!)...

Rzeczywiście, dosyć długo, bo 27 sekund, ale Twoja (U5B) z wypełnieniem, rysuje się 55 sekund... Jeśli dodamy przeliczanie bitów, to raczej będzie wolniej niż szybciej.
Jedyny sposób przyspieszenia, jaki ja widzę, to rysować figury na czarnym tle przy pomocy znaków, a na kolorowym dotychczasową metodą. Co prawda mielibyśmy zmienną „szarpaną” prędkość rysowania, mniej estetyczną, ale na pewno byłoby znacznie szybciej.

Przy okazji kolejna uwaga - nie można odznaczyć błędnie wybranej figury - trzeba ją zamienić, wygodniej by było gdyby ponowne wciśnięcie odblokowywało kursor (po wykryciu puszczenia i ponownym wciśnięciu fire).

Wygodniej i łatwiej, ale gra nie powinna być zbyt łatwa. W tym przypadku pomyłka nie owocuje „utratą życia”, a jedynie odrobiny czasu. Niekiedy też może okazać się korzystna. Podczas testów zdarzyła mi się przypadkowa zamiana i... obie figurki zmieniły tło na żółte!
A trzeba pamiętać, że dodatkowa funkcja, to dodatkowa komplikacja kodu, która niekiedy może negatywnie się odbić na szybkości programu.

Nie trzeba do tego używać potęg (bardzo powolne)

Informacje o powolności potęgowania są mocno przesadzone :) Weźmy taki przykład:
10 FOR A=1 TO 5000:X=2^2:NEXT A
Ten program wykonuje się (TBXL / Atari BASIC - sekundy) ok. 20,4 / no, nieważne...*
Dla X=2*2, to jest 14 / 31.3
Dla X=2+2 to 10.6 / 23
*Po 3.5 minuty przestałem liczyć czas, zmienna „A” ledwo dobijała do 1000.
Jak widać potęgowanie w TBXL jest szybsze niż dodawanie w A.B. (!). Można śmiało tej funkcji używać, byle z umiarem.

Stąd moje pytanie o narzędzie, jak i z ciekawości...

Narzędzia, to może za dużo powiedziane. Raczej są to programy pomocnicze pisane pod konkretne zadanie. Jeden z nich przerabiałem kilka razy, tak, że sam do końca nie wiem o co w nim chodzi :), ale działa prawidłowo. Można je traktować raczej jako ciekawostkę niż narzędzia - chyba do niczego więcej się nie przydadzą. 64f – kit
- 21: CommentAuthorQTZ
- CommentTime8 Aug 2011
Wyświetlanie samego fontu bez inverse zajmuje około jednej sekundy, więc pomijając Locate i Plot na obliczenia zostaje jak się wydaje sporo czasu.

W u5b zamieniłem Locate na Get#6, co dało o ponad 11 sekund lepszy rezultat:
```
76 FOR L=%0 TO 15:POSITION X,Y+L:FOR P=%0 TO 7:GET #6,C:IF C=%0 THEN PLOT X+P,Y+L
```
Niestety próba przypisania linii do zmiennej tekstowej i wyświetlanie przez Print#6; spowodowała spowolnienie.

Kolejny test (u6) - wyświetlanie bajtów przy użyciu Move - zajmuje około 9,5 sekundy, jednak na razie niczego nie obliczam, a po dodaniu losowania danych (linia 215) czas wydłuża się do ok. 40 sekund!? Więc wygląda na to, że program będzie zbyt wolny...

Aby zminimalizować obliczenia mogę zamiast MOVE użyć PRINT #6; - odpadnie przesuwanie danych. Jednak pierwsze rozwiązanie byłoby o tyle lepsze, że można by było na jego podstawie napisać procedurę maszynową.

Można też najpierw użyć Text, pobierać bajty z ekranu i dodać podświetlenie.

I jeszcze jeden pomysł - przy wyświetlaniu "planszy" można dodatkowo losować kolejność wyświetlania figur, co da ciekawy efekt - aby nie wydłużać czasu losowania można zrealizować je w jednej wspólnej pętli.

Dzięki za odpowiedzi i pliki :)
- 64FiguryOnFontByteClear.7z
- 22: CommentAuthorBluki
- CommentTime9 Aug 2011
Ta procedura (U6) działa szybko, jeśli chodzi o przepisywanie znaków, ale nadal nie rozwiązuje problemu rysowania na kolorowym tle. Gdyby przyjąć, że na początku wszystkie figury są całkowicie nie na swoich miejscach, to wystarczyłyby 2 sekundy do narysowania planszy...
Losowanie i wyświetlanie równocześnie? No nie wiem, czy byłoby szybciej. Losowanie odbywa się liniowo (pojedyncza pętla), a rysownie figur w dwóch wymiarach – dwie pętle FOR – NEXT.

Wydaje mi się, że realne przyspieszenie można by uzyskać pisząc grę w asemblerze lub jak zauważył to ś. p. Zza_parawanu stosując specjalizowane procedury rysujące – dostosowane do konkretnego trybu graficznego.
- 23: CommentAuthorQTZ
- CommentTime10 Aug 2011 zmieniony
Kolejna wersja i znowu przeorganizowanie fontu - tym razem dla zapewnienia ciągłości odczytu bajtów (jedynym drobnym problemem jest przeliczanie kodu ATASCII na miejsce w czcionce). Kolejność jest zachowana, ale znaki są ułożone tak, że każda kolejna para tworzy figurę (góra, dół, góra, dół... itd.). Dopisałem konwersję kolejnych bajtów czcionki na bity i te wyświetlam przez Print #6; niestety ciągle zbyt wolno, ale efekt jest już lepszy :) Umieściłem też najprostszy sposób, który jak do taj pory jest najszybszy z tych, które użyłem. Dodałem wyświetlanie czasu - jak się okazuje jest to bardzo przydatne, bo wiem, gdy coś popsuję ;) Na marginesie: zauważyłem, że użycie %0 przy Trap nie powoduje błędu w TB przy renumeracji (nie jest przerenumerowywane i nie zostaje zepsute).

Mam jeszcze taki pomysł - można wyświetlić figurę i zapamiętać bajty z ekranu przy użyciu programu maszynowego: Okna, który o ile się nie mylę działa na całych bajtach - jakbym się mylił to ten program by wystarczył :). Potem wyświetlić inverse znaku w odpowiednim kolorze i znowu zapamiętać. Następnie złożyć w całość (! -OR) i wyświetlić złożone. Kopiowanie bajtów będzie działać błyskawicznie, problemem będzie pętla, która połączy dane bajt po bajcie... a będzie to 48 bajtów (x2).

Nie chodziło mi o to, żeby losować pozycję figur w trakcie wyświetlania - może niefortunnie to ująłem - a o to żeby losować kolejność ich wyświetlania - to znaczy losować jeszcze jedną zmienną LOS3$ i na jej podstawie wyświetlać figury według losowania jak dotychczas, ale nie w kolejnych polach, tylko według tej zmiennej, co da efekt jak w Boulder Dash'u :) a losowanie umieścić w już istniejącej pętli np. w linii 10262, aby dodatkowo nie spowalniać za nadto.

U6 wyświetla figury przez Text (podobnie jak wcześniej, więc brak kolorów) - w ten sposób możesz wyświetlić planszę podając kol, wiersz i zn, więc możesz je losować. Nowością w tej wersji było operowanie na bajtach, ale w tej chwili to jedynie czyszczenie planszy, do czego wrócę i postaram się to rozbudować (wtedy będzie można podświetlać), ale podejrzewam, że będzie bardzoooooo woooooooolno :)

Myślę, że póki co warto zmienić sposób wyświetlania planszy na TEXT (font u5.fnt), a w trakcie gry zostawić jak jest.
W trybie gry z jedną figurą dałbym jedną na stałe, tak, aby nie było problemu z prędkością gry.
- 64FiguryOnFontBitToPrint.7z
- 24: CommentAuthorBluki
- CommentTime12 Aug 2011 zmieniony
Rzeczywiście, wydaje się, że rysowanie figur w losowych polach byłoby atrakcyjniejsze.
Kluczową jednak kwestią jest jak wyświetlić dwukolorowe figury w czasie znacząco krótszym niż 27 sekund - powiedzmy przynajmniej w 17 s. Jak na razie to się nie udało. Hybrydowe wyświetlanie (znaki na czarnym tle jako fonty, a na kolorowym PLOT/DRAWTO) jednak nie wchodzi w grę, bo na poziomie "gamma" WSZYSTKIE figury mają kolorowe tło.

W trybie gry z jedną figurą dałbym jedną na stałe, tak, aby nie było problemu z prędkością gry.

Ja jednak uważam, że lepszy jest jednolity mechanizm wyświetlania, bez względu na wybrany poziom gry.
- 25: CommentAuthorQTZ
- CommentTime14 Aug 2011 zmieniony
Dzisiaj zająłem się nauką assemblera 6502 :)

Na początek zmieniłem MOVE (Taki jak użyłeś w Dzikiej Wyspie - na marginesie - świetne opisy sytuacji) - tak, aby wykonywał OR stąd nazwa MOR - Multiple OR - w ten sposób można wyeliminować powolną pętlę TB (dołączony prosty test).
Zmodyfikowałem też Okna, ale w tym przypadku funkcjonalność się nie zmieniła, natomiast program jest teraz relokowalny - nie musi być umieszczony na 6 stronie pamięci, za to urósł o kilka bajtów. Ponieważ to moja pierwsza "większa" modyfikacja myślę, że da się to zrobić lepiej, ale działa prawidłowo :)
Jest nadzieja, że program z wykorzystaniem tych binarek będzie wystarczająco szybki, choć nadal to nie będzie to, co chciałbym uzyskać.

Program Okna jest uniwersalny, więc jeżeli nie w tym projekcie, to z pewnością w innym może Ci się przydać.

Pochodzi prawdopodobnie z Bajtka, nie pamiętam dokładnie, ale na szczęście opis użycia dołączyłem do pliku. W załączniku programy wraz z kodami źródłowymi z moim opisem na potrzeby nauki :) Są tam trzy wersje Okien: OKNA.LST - prawdopodobnie nieznacznie zmodyfikowana oryginalna; OKAN256.LST - linie Data zamienione na bajty (Okna + Copy 256); OKNAREL.LST - moja wersja relokowalna.
- Okna-Copy256-Move-MultipleOR.7z
- 26: CommentAuthorQTZ
- CommentTime16 Aug 2011 zmieniony
Zrobiłem wyświetlanie przez Text, Move, Okna i MOR (test 5) tak jak opisałem powyżej. Wyświetlenie podświetlonych figur zajmuje ok. 5 sekund, niepodświetlone najlepiej wyświetlać przez Text.
Podczas wyświetlania figura miga szybko na przemian z pustym miejscem i inversem w kolorze, jest to efekt użycia Text i Okien.
Użycie Okien wymaga zapisania w zmiennej danych, które będą podmieniane z tymi na ekranie, co robię raz na początku - dlatego wyświetlam fragmenty ramki.
Liczba linii przy Oknach = 15, bo jak zauważyłem trzeba podawać liczbę o 1 mniejszą.
Wyświetlenie tych danych (uzyskanych po MOR) linia po linii w TB zajmie co najmniej dodatkowe 7 sekund - jak widać na przykładzie (u6 - czyli - test 2 - czyszczenie), ale dopóki wymaga "migania" nie będzie to wyglądało dobrze.
- 64FiguryOnFontOknaMOR.7z
- 27: CommentAuthorBluki
- CommentTime16 Aug 2011
Przymierzałem się kiedyś do wpisania "okien" z "Bajtka", ale zawsze było coś ważniejszego do zrobienia...

Procedurki ciekawe, szczególnie relokowalne. Może przydadzą się za jakiś czas, choć spodziewałem się, że okna będą trochę szybsze.
- 28: CommentAuthorQTZ
- CommentTime16 Aug 2011 zmieniony
Okna działają szybko tylko w tym przypadku trzeba je wywołać kilka razy i wykonać inne operacje - patrz komentarze.

Bluki nie rozumiem, jeszce kilka dni temu marzyłeś o 17 sekundach, a teraz marudzisz na 5 :)
Bluki:
Kluczową jednak kwestią jest jak wyświetlić dwukolorowe figury w czasie znacząco krótszym niż 27 sekund - powiedzmy przynajmniej w 17 s.

Sprawdziłem, że dodatkowe wyświetlanie linia po lini zajmuje w sumie około 14 sekund, więc i tak mniej niż 17 :)

Można to zrobić jeszcze szybciej używając większej zmiennej na okno. To znaczy wyświetlić wszystkie figury jako text, zapisać jedno duże okno z całą planszą, potem wyświetlić na nich inverse tych które mają być podświetlone i ponownie zapisać okno, potem zrobić MOR i wyświetlić przy pomocy okna - wszystko można zrobić przy wygaszonym ekranie. A ponieważ może na to zabraknąć pamięci można to zrobić np. w czterech częściach (cztery okna po kolei). I już plansza będzie wyświetlona.

Oczywiście najlepiej byłoby napisać procedurkę w assemblerze od razu konwertującą font na odpowiednio podświetlone figury, tak jak zrobiłem to w Basicu (lub tak jak obmyśliłem na początku), ale na razie się uczę więc póki co zacznę od rozdzielenia funkcji z Okien na odczyt, zapis i zapis z MOR jednocześnie, co wyeliminuje przynajmniej miganie pustym tłem i pewnie nieco skróci czas.
- 29: CommentAuthorBluki
- CommentTime19 Aug 2011
A, nie miałem czasu i nie przyjrzałem się dokładnie.
- 30: CommentAuthorQTZ
- CommentTime2 Oct 2011 zmieniony
W związku z ostatnią kumulacją postanowiłem odkopać program LoTTo 6 z 49. Pierwotnie program był napisany na kalkulatorek Casio przez A. Hinkel'a, a całkowicie przerobiony przeze mnie w 2002 roku. Teraz zrobiłem wersję na Atari.

Wygląd programu nie uległ zmianom, jedyna różnica to czcionka - moja jest bardziej "zaokrąglona". Podobnie jak na kalkulatorku znaki są różnej szerokości. Przy tworzeniu fontu pomogłem sobie prostym programem WSFONT.BAS, tworzącym zmienną WS$, która zawiera szerokości liter zgodne z podanymi.

Główny program pozostawiłem praktycznie bez zmian, musiałem tylko zmienić współrzędne plotów (na kalkulatorku można ustawić dowolną skalę i w niej wyświetlać ploty).

Do zapamiętania ekranu pierwotnie użyłem Okien i MOR'a, a ostatecznie zmodyfikowałem procedurę okien tworząc kilka nowych, dzięki którym można:

OKNA - zapisać okno na ekranie zapamiętując tło (oryginał)
OOR - nałożyć okno zapamiętując tło (podobnie jak oryginalnie, ale z or).
OGET - pobrać okno z ekranu;
OPUT - zapisać okno na ekranie;
OPUTOR - nałożyć okno na ekran;
OPUTORGET - nałożyć okno na ekran i zapisać do zmiennej źródłowej;

Te procedury pozwalają wyeliminować użycie MOR'a i wielokrotne wywoływanie Okien, jak również zbędne miganie obszaru okna. Program z wykorzystaniem tych procedur staje się również bardziej czytelny i szybszy.

Same Okna nieco skróciłem - usunąłem sprawdzanie czy program jest wywoływany bez parametrów - co było niepotrzebne, bo i tak się zawiesza, gdy parametrów nie jest tyle ile potrzeba, a o taka pomyłkę łatwiej.

Nowe Okna są na dyskietce w pliku OKNA.LST - wszystkie procedury wywołujemy z parametrami jak standardowe Okna.

Przy okazji zauważyłem, że MOR ma błąd - OR-uje o jeden znak za dużo (ale chyba nie w każdym przypadku - tu przetwarzał 1025 Bajtów zamiast 1024). Ponieważ jest on lekko zmienionym MOVE prawdopodobnie błąd występuje również tam.

Program Lotto umieszczam w tym wątku, gdyż kontynuuje on temat przyśpieszenia wyświetlania.

Na dyskietce również nowa wersja testu U9.BAS, Test 6 wykorzystuje zmodyfikowane okienka (mignięcie jest spowodowane już tylko użyciem text'u), nie wymaga zapamiętania ramek, a wyświetlenie 64 figur z podświetleniem zajmuje mniej niż 4 sekundy.
- 31: CommentAuthorQTZ
- CommentTime6 Oct 2011 zmieniony
Moja pierwsza, własna, nowa procedura w assemblerze 6502 :)

B2P konwertuje dane znaku (figury) o wielkości max 255 Bajtów na 8 razy większe dane do PRINT #6; z użyciem kolorów COLOR i FCOLOR (PEEK(765)). Później można je wyświetlić w dowolnym trybie *graficznym*.

Procedura w zasadzie jest multi-konwerterem DEC->BIN - przykład (B2P.LST), ale zastosowanie ma szersze.

Źródło w assemblerze w dwóch wersjach: dla 6502 Simulator'a Michała Kowalskiego - Thanks to Rudla :) i dla Mads'a.

Dla 64 figur obliczenia z B2P zajmują 0,56s, co skraca czas Testu3 z 61,84 do 17,7s ;). Nie użyłem optymalizacji dla pustych / pełnych linii, więc wszystkie figury są obliczane / wyświetlane w podobnym czasie. Optymalizacja obliczeń i tak niewiele by zmieniła, a jest lepiej gdy są wyświetlane ze stałą prędkością.

W U10 "wyłączyłem" wyświetlanie mniej istotnych testów, zostawiłem tylko 3,6 i 2.

Co prawda Test3 w parze z Test6 w zasadzie już są wystarczająco szybkie, ale jeszcze spróbuję napisać kod dla Testu2, który wydaje się, że będzie najszybszy do wyświetlania figur linia po linii w czasie gry, a wraz z OPUTOR będzie się nadawał do wyświetlania planszy bez użycia TEXT'u, co całkowicie wyeliminuje miganie. Natomiast do szybkiego czyszczenia ekranu można użyć OGET/OPUT.

Bluki, mam nadzieję, że jeszcze tu zaglądasz, bo ja, jak widać się jeszcze nie poddaję i mam nadzieję, że moje eksperymenty nie pójdą na marne :)

Pomyślałem, że można byłoby dodać więcej obrazków figur w tym samym stylu, z których wyświetlane byłyby 64, bo te, mimo, że fajne, to już trochę mi się nudzą ;)
- 64FiguryBytes2Print6MC.7z
- B2P.7Z
- 32: CommentAuthorBluki
- CommentTime6 Oct 2011
Zaglądam, zaglądam. Jak jednak powszechnie wiadomo, zawsze czasu jest za mało. Liczyłem na rozbicie banku w LOTTO, mógłbym wówczas zajmować się hobby 8 godzin, a pracować jedną... Niestety, nie udało się :(
Eksperymenty nigdy nie idą na marne, zawsze wzbogacają wiedzę, doświadczenie. Nawet jeśli nie zostaną wykorzystane teraz, to mogą się przydać kiedyś w najmniej spodziewanym momencie.
Może napiszesz "64 figury II"? Cholera, dlaczego to wygląda jak "Commodore 64 II"? To może "256 figur"? :)
Tylko co ze "Statkami", chciałbym już pograć :)
- 33:
  
  CommentAuthorKaz
- CommentTime7 Oct 2011
Gra "64 Figury" poszla do katalogu gier, a "Lotto" do uzytkow, dzial roznosci.
- 34: CommentAuthorBluki
- CommentTime7 Oct 2011
Dzięki Kaz, ale dokument "64 figury" powinien być w formacie .odt, a nie txt, inaczej robi się nieczytelna "sieczka".
- 35:
  
  CommentAuthorKaz
- CommentTime7 Oct 2011
Wrecz przeciwnie, to format odt na Atari objawia sie jako sieczka... :)
- 36:
  
  CommentAuthorKaz
- CommentTime8 Oct 2011
Bluki - widze, ze wszystkie gry maja u Ciebie format ODT. Czy chcesz, zeby takie wersje dokumentow wrzucac do katalogu? Sugerowalbym jednak TXT w formacie ATASCII.
- 37: CommentAuthorQTZ
- CommentTime8 Oct 2011 zmieniony
Kolejna moja procedurka - CHARGRAF - BYTE TO 2 COLOR WITH SHIFT (4 COLOR MODE ONLY)

Konwertuje ona kolejne Bajty znaku (figury, grafiki) na dwukolorowe i wyświetla je na ekranie. Obecna wersja działa poprawnie tylko w trybach 4 kolorowych, stąd każdy Bajt na ekranie zajmuje 2+1. Ten dodatkowy na przesunięcie, które umożliwia umieszczenie grafiki w dowolnym miejscu ekranu.

Przesunięcie o 1 piksel wynosi tu 2 bity, więc wartość przesunięcia może wynosić od 0 do 4, tak, aby zmieściła się w Bajcie. Poprawność Shift nie jest sprawdzana.

Kolory są odczytywane z rejestrów koloru jak w B2P (COLOR i FCOLOR). Mogą one mieć wartości większe niż 3, kolor i tak zostanie ustawiony na podstawie 2 najmłodszych bitów.

Wywołanie:
Z=USR(ADR(CH2G4$),ADR(CHR_DATA$),ADR(SCREEN$)
,SHIFT,CHR_HEIGHT,SCREEN_WIDTH)

Adres grafiki, adres na ekranie i przesunięcie trzeba obliczyć w Basic'u.

Wskazując kolejne Bajty (lub w dowolnej kolejności) przy wysokości 1 można wyświetlić znak linia po linii (dla efektu dodając PAUSE), lub wskazując pierwszy Bajt i podając odpowiednią wysokość - wyświetlić cały.

Odpada konieczność używania różnych procedur do figur z podświetleniem i bez - zmieniamy tylko kolor, podobnie z czyszczeniem.

Brakuje jeszcze możliwości nakładania bez czyszczenia tła, ale przy 64 Figurach nie jest to potrzebne.

W załączniku kod źródłowy i demko jego działania - ToDel2 i ToDel - pierwsza wersja z "mixowaniem" kolorów (uwaga - ma zamienione parametry: SHIFT i CHR_HEIGHT).

Bluki, Kaz, niestety nie mam w tej chwili czasu, więc to tyle na dziś, postaram się odpisać następnym razem.
- CHARGRAPH4C.7z
- TODEL2.7Z
- 38: CommentAuthorBluki
- CommentTime8 Oct 2011
Kaz, format odt jest popularny, tworzy oszczędny objętościowo plik, nawet WordPad go odczytuje (choć z problemami), a daje możliwość formatowania i kolorowania tekstu, wstawiania fotek, itd. Mamy XXI wiek, nie musimy się ograniczać tylko do formatu tekstowego. Bez problemu, w razie potrzeby, każdy może dokonać sobie konwersji odt na txt choćby wspomnianym WordPadem.
Dlatego wolałbym pozostać przy odt. Pewną alternatywą mógłby ewentualnie być format rtf.
- 39:
  
  CommentAuthorKaz
- CommentTime8 Oct 2011
Bluki, jaki polecasz czytnik rtf albo odt na Atari?
- 40: CommentAuthorBluki
- CommentTime8 Oct 2011 zmieniony
Na Atari nie, ale jak napisałem, każdy komu jest to potrzebne może łatwo sobie przetworzyć plik na txt. Po co zubożać wygląd dokumentu - a może zostawić obie wersje txt i odt?
- 41: CommentAuthorQTZ
- CommentTime9 Oct 2011 zmieniony
Uf, a już myślałem, że jestem tutaj sam :) Też liczyłem na wygraną w Lotto, jednak mój program nie trafił nawet "jedynki" :( A czasu na hobby i tak poświęcam za dużo :) Procedurki prościutkie, ale dla Basic'owca mogą być bardzo przydatne. Żałuję, że nie miałem takich, kiedy pisałem dużo programów w Basic'u. Teraz napisałem je sam i z pewnością będę ich używał, do czego również zachęcam - bo tak jak piszesz Bluki, mogą się przydać w najmniej spodziewanym momencie ;) Mam też kolejne pomysły, więc pewnie jeszcze kilka napiszę :), a i obecne też troszeczkę poprawię.

"256 Figur" ...czemu nie, już próbowałem coś sensownego narysować i... nie jest to takie łatwe w tak małej rozdzielczości (tym bardziej brawo!) - na razie mam około 10 nowych figur :) Może ogłosimy konkurs? I wtedy dorzucimy te najciekawsze :)
Bluki, z Kit'em do gry mogę drugą wersję przygotować sam... ale w końcu Ty jesteś autorem, więc liczę na Ciebie. Myślę, że "II" to za dużo ("64 Figury II" wcale nie wygląda jak "Commodore 64 II" - widziałem Commodore 64 w obu wersjach - wyglądają zupełnie inaczej ;->), najwyżej będzie to 1.1, w końcu to tylko przyspieszenie. Przygotuję kolejny test, jak będzie wystarczająco szybki to postaram się dostosować go do programu gry.

Statki - wszystkie potrzebne algorytmy mam... na papierze, zająłem się grafiką i na razie odłożyłem... a też bym sobie pograł, gorzej z pisaniem...

Co do formatu odt to wcześniej się z nim nie spotkałem, odczytanie go w WordPad'zie daje "krzaczki", bo jest to plik binarny - archiwum zip, które zawiera m.in. plik content.xml z tekstem dokumentu i dołączone pliki graficzne, a te już można odczytać po rozpakowaniu. W pliku odt możemy znaleźć ciąg znaków "opendocument" i "openoffice.org", dzięki czemu wiadomo czym ten plik został utworzony. Zanim ściągnąłem OpenOffice'a xml'a otworzyłem w xml Notepad'zie, którego miałem zainstalowanego. Tak, więc skonwertowanie tego pliku na txt bez dodatkowej wiedzy i narzędzi wydaje się niemożliwe. A instalowanie OpenOffice'a tylko po to, żeby skonwertować plik odt na tekstowy trochę mija się z celem, choć nie do końca. Teraz mam zainstalowanego OpenOffice'a, jednak żeby móc otworzyć plik odt na innym komputerze muszę go najpierw skonwertować na inny format, bo nie każdy komputer ma zainstalowanego OO i nie każdy chce lub może go zainstalować. Zapisywanie tekstów w tym formacie z pewnością rozszerzy grono użytkowników OO. Może warto dodać info, jaki program otwiera ten plik i link gdzie go znaleźć?, lub dodawać w nazwie np. "instrukcja"?, co da do zrozumienia, że jest to dokument tekstowy. Ja jestem z OO zadowolony, oprócz odczytania plików przecież również można je tworzyć - skorzystałem już dwa razy - dzięki Bluki :) Myślę, że o ile to możliwe warto dodać txt, a najlepiej zapisywać w bardziej popularnym formacie np. rtf. Kaz, oczywiście nie przeczytamy go na Atari, ale nie przeczytamy również djvu, pdf, większości jpg, nie wspominając o html, czy mht, a w tych formatach na ogół są zapisane instrukcje i literatura dla Atari, które w razie potrzeby możemy np. wydrukować. Za to instrukcja choćby skrócona w formie txt ma ten plus, że można w niej łatwo wyszukiwać, zamieścić ją łącznie z programem w pliku ATR i się nie zgubi, jednak wtedy z kolei może zostać zupełnie niezauważona. Ja na dwóch dyskietkach dołączyłem plik CZASY.TXT skonwertowany na format Panther, czy go zauważyliście?

Co do nietypowych formatów to nie udało mi się rozpakować Mini Zjadacza z filmikiem UHARC. Bluki pomocy!

A teraz wracam do eksperymentowania...
- 42:
  
  CommentAuthorKaz
- CommentTime9 Oct 2011
Kaz, oczywiście nie przeczytamy go na Atari, ale nie przeczytamy również djvu, pdf, większości jpg, nie wspominając o html, czy mht, a w tych formatach na ogół są zapisane instrukcje i literatura dla Atari, które w razie potrzeby możemy np. wydrukować.

Ta konkretna instrukcja to niewielki kawalek tekstu, ktory nie wymaga obrazkow, metadanych, linkow, etc. Nie ma zadnego uzasadnienia, zeby trzymac to w jakimkolwiek specyficznym pecetowskim formacie.

Ten tekst spokojnie mozna zapisac jako ASCII lub ATASCII i bedzie tak samo czytelny na pececie (w tym drugim przypadku przez jeden z wielu czytnikow ATASCII) jak i na Atari. Jezeli zas bedzie w formacie ODT to przeczytac go mozna tylko na pececie, a na Atari juz nie. A z tego co wiem, sporo osob, ktore sciagaja nasz katalog gier - korzysta z niego na prawdziwym Atari (np. SIO2SD).

Ale oczywiscie to wybor autora. Ja tylko zwrocilem uwage, zeby za bardzo nie odbiegac od wymogow prawdziwego sprzetu w uklonie dla graczy "emulatorowych" :).

Instrukcja choćby skrócona w formie txt ma ten plus, że można w niej łatwo wyszukiwać, zamieścić ją łącznie z programem w pliku ATR i się nie zgubi, jednak wtedy z kolei może zostać zupełnie niezauważona. Ja na dwóch dyskietkach dołączyłem plik CZASY.TXT skonwertowany na format Panther, czy go zauważyliście?

Nie sadze, zeby ludzie chcieli grzebac po dyskietkach w poszukiwaniu plikow, o ktorych istnieniu nie wiedza. Dlatego czesto wyrzucam plik txt "na zewnatrz" dyskietki i w takiej dodatkowej formie wystepuje w katalogu gier. Wydaje mi sie to dobrym sposobem na przykucie uwagi :)
- 43: CommentAuthorQTZ
- CommentTime9 Oct 2011
Gdy nie ma uzasadnienia użycia jakiegoś wymyślnego formatu to oczywiście jestem za txt. Jednak wolę pliki txt w formacie zgodnym z PC, bo zazwyczaj czytam ja na PC. A jeżeli są w formacie Atari to je konwertuję i też nie ma problemu (chyba, że jest ich dużo). Z tym grzebaniem to różnie bywa - zaglądam gdy mam wątpliwości i czasami znajduję, choć myślę, że większość nie jest aż tak dociekliwa. Ja zaznaczyłem w tekście, że na dyskietce są dodatkowe programy, więc ktoś kto tam zajrzy powinien zauważyć i txt'ka. Umieszczenie pliku txt "na zewnątrz" wraz z atr - ok, ale lepiej w formacie PC, na dyskietce wyłącznie w ATASCII.
- 44: CommentAuthorBluki
- CommentTime10 Oct 2011 zmieniony
QTZ:
Uf, a już myślałem, że jestem tutaj sam :)

To tak jak ja w wątku „Gry szerzej nieznane”, ale w ostatniej chwili pojawił się Kaz :)

Co do wersji #2 64 figur, ta tak jak napisałem, jeśli chcesz to możesz stworzyć swoją wersję, wystarczy, że na planszy tytułowej podasz źródło inspiracji (na przykład: „...na podstawie gry 64 figury, (c) 2011 Blue Kitten Software” lub coś podobnego). Ja mogę w miarę wolnego czasu wystąpić w charakterze „konsultanta” :)
Konkurs mógłby się przydać, tylko będą zainteresowani graficzką 8*16 pikseli?

Do kompresji/dekompresji UHARC wykorzystuję program WinUHA, strona domowa: ->link<- , co prawda pisze, że działa tylko pod Windows XP, ale pod W7 też nie ma problemu.
Z dekompesją (tylko) poradzi sobie też PeaZip.

No dobrze, do prostych informacji technicznych wystarczy format ATASCII i txt, choć użycie koloru poprawia czytelność. Jednak w takim przypadku jak "Dobry Król Zurp" moim zdaniem już nie. Jak wspomniałem wcześniej – może przynajmniej w niektórych przypadkach umieszczać dwa pliki: ATASCII i odt albo rtf. Pamiętajmy też, że dokument można zawsze sobie wydrukować. Nie ma też obawy, że dokumenty się zgubią – po to wymyślono foldery.

QTZ:
odczytanie go [odt] w WordPad'zie daje "krzaczki"

Ja mam WordPada 6.1 (Service Pack 1) i czyta bez większych problemów format odt. Jedynie kłopot pojawia się z tekstem na kolorowym tle, a dokładniej źle te tło wyświetla.

Oto przykład dokumentu odt na WordPadzie (obrazek później usunę):

[15.10.2011]
Na życzenie Kaza przykład zostaje :)
- ODT w WordPadzie.PNG
- 45:
  
  CommentAuthorKaz
- CommentTime11 Oct 2011
Obrazka pozniej nie usuwaj, dolacz na forum.
- 46: CommentAuthorQTZ
- CommentTime21 Oct 2011 zmieniony
Bluki, tym razem mnóstwo nowości:

Test u12 wykorzystujący CH2G4 (Test2) wyświetla 64 figury w czasie max 2,5s. dla całych figur i nieco ponad 11s dla linia po linii, więc myślę, że to wystarczy i można już wprowadzić zmiany do gry, co postaram się zrobić.

Aby już więcej nie mieszać poprzednich rozwiązań zrobiłem okrojoną wersję u12cut - TESTFIG.64, zawiera ona tylko program wyświetlenia figur i test prędkości, stanowi więc bazę do zrobienia wyświetlania w grze. Program znajduje się dyskietce z nową wersją kit'u, którą przygotowałem.

Test pobiera dane z plików f0r.fig, f1r.fig, f2r.fig, f3r.fig, które są tworzone przez FREMAP.64 z plików f0.fnt do f3.fnt znajdujących się na dysku H:. Jest to wygodne, gdy edytuje pliki fnt przy pomocy narzędzi na PC. W każdym razie pliki f0.fnt do f3.fnt znajdują się na dyskietce, więc wystarczy zmienić litery dysku w programie, lub skopiować pliki na H:. Plik f0.fnt zawiera standardowy zestaw figur, kolejny raz przeorganizowany dla zachowania kolejności przy maksymalnym uproszczeniu obliczeń. W plikach f1.fnt i f2.fnt są nowe piktogramy, kilka zaczerpnąłem z innej gry ;), niektóre wymagają poprawek, f3.fnt jest pusty.

Do edycji figur na PC używam Atari Font Mover'a (utworzenie plików *.G2F i ułożenie znaków), Graph2Font'a (rysowanie figur w zoom z siatką), Atari Font Maker'a (kopiowanie usuniętych duplikatów i ostatnie poprawki – np. przesunięcie figury na środek pola 8x16).

Program FREMAP.64 (Fig Remapper) zmienia kolejność elementów figury z ułożenia czytelnego w Atari Font Mover'ze, tak aby dane były ułożone ciągiem dla każdej z figur (wynikowe pliki fig to również fonty). Program umożliwia też podgląd pojedynczych znaków na wybranym kolorze tła (Strzałki lub JoyStick; [TAB] lub [FIRE]). Korzysta z procedur ch2g4.bin i oget.bin, których kombinacji użyłem do wyświetlania figury w powiększeniu. Jak się okazuje zmiana parametru szerokość ekranu ma sens :) „1” może się przydać, a i nawet 255 może być za mało... gdybym zrobił jeszcze obsługę trybów z większą ilością kolorów to zoom byłby jeszcze lepszy :) Myślę, że na bazie tego programu można zrobić edytor figur :)

Kolejnym programem, który napisałem prawie od zera jest SUMATOR2.64, teraz wyświetla on nazwy plików, odpowiadające im nazwy zmiennych i ich rozmiar - wpisane w liniach Data. Po zsumowaniu plików oblicza automatycznie adresy, które naciskając kilkakrotnie Return można wprowadzić do pliku gry. Dzięki temu, że pliki font z wizerunkami figur są traktowane jak dane nie muszą być umieszczone od początku strony, co umożliwia ich umieszczenie w bloku danych na początku pliku, tak jak dotychczasowych danych dla Plot i Drawto. Uwaga: ilość plików w Bloku (chodzi o pliki umieszczane przed font'em PL) również należy podać w linii Data.

Niestety nie wiem, jak odczytać dokładny rozmiar pliku? Jedyne co przychodzi mi do głowy to czytać Bajt po Bajcie, aż wystąpi błąd... Przydałoby się to do całkowitego zautomatyzowania procesu sumowania plików, w tym pominięcia łączenia z poziomu DOS'u. Przy okazji można by było sprawdzać czy rozmiar plików jest zgodny z deklarowanym w Data.

Teraz sumowanie jest dużo prostsze. Ale... Uwaga: miejsca na dyskietce jest zbyt mało i najlepiej przed złączeniem plików SUM.BIN i FIG64A.TB, skopiować je na nową dyskietkę!

Gra z dołączonymi dodatkowymi danymi (nie zmieniłem kodu gry, więc nie są używane) nie zawiesza się :), więc wygląda na to, że nowy sumator działa prawidłowo, a ponieważ dołączam nowe dane figur wraz z obecnymi, myślę, że można dołożyć ich więcej, wykorzystując miejsce dotychczasowych, oczywiście po zmianach w programie gry. Przy większej ilości figur trzeba będzie dodatkowo przerobić losowanie, tak aby korzystało z DPoke, aby zmienna mogła wskazywać więcej niż 256. Można też czytać figury, każdą osobno po wylosowaniu, wtedy ograniczeniem będzie już tylko pojemność dyskietki ;). W danych dołączam 16 zerowych Bajtów, bez adresu, tuż przed danymi figur – są to dane „pustej” figury, która będzie miała kod „-1”, czy będą potrzebne okaże się później.

Dopisałem też Readme.txt wraz z programem do podglądu - Readme.tb (rozmiar pliku .txt jest zapisany na stałe), zrobiłem go "na szybko", na bazie Lotto. W pliku jest opis zmian i poprawek, które wprowadziłem do pierwszej wersji kit'u. Plik nie zawiera informacji, o nowych narzędziach.

I to chyba tyle jeżeli chodzi o kit'a.

Na koniec obszerny bug report do Turbo Basic Loader'a, który na pierwszy rzut oka wygląda świetnie, jednak...
- Brak help'a, nie ma chociaż krótkiej informacji o klawiaturze np. "Press [Shift]+[,] [Shift]+[.] to change option", która mogłaby być np. wyświetlana po naciśnięciu Help'a (chyba żaden program tego nie wykorzystuje? :)) Nie wiadomo, co dają opcje Hdv, tur? lub mon, mlm? Jak z nich korzystać?
- Niekonsekwencja - opis po angielsku, a komunikaty po polsku.
- Brakuje możliwości wczytywania plików *.lst (*.tbl).
- Przydałaby się przeglądarka plików tekstowych (w trybie tekstowym). Teraz wskazanie pliku tekstowego powoduje wyświetlenie błędu, ale na pustym ekranie!? Wtedy naciśnięcie np. "1" już niewiele pomaga - ekran standardowy, widać kursor z systemu, nie widać kursora programu i po naciśnięciu Return występuje błąd 12 w linii 0, a programu już nie ma...
- Niewygoda - kursor nie przechodzi na drugą kolumnę po dojściu na dół (i na dół do poprzedniej kolumny po dojściu na górę). Lewo i prawo przenosi, ale tylko gdy pliki są w zasięgu kursora.
- Program zachowuje się nieprawidłowo przy konkretnej ilości plików:
- Gdy w pierwszej kolumnie jest o jeden plik mniej niż się w niej mieści, występuje błąd 28 w linii 1200 w momencie wskazania tego pliku.
- W drugiej kolumnie nie można przejść na przedostatni plik, a gdy jest zapełniona, dodatkowo wskazanie ostatniego pliku (przechodząc w prawo z pierwszej kolumny) i przejście dalej w prawo powoduje błąd jak wyżej.
- Trzeciej kolumny jeszcze nie zapełniłem...
- I ostatni, błąd TBL, który zauważyłem i prowizorycznie usunąłem. Z TBL nie działały programy korzystające z trybów graficznych. Programy wymagały naciśnięcia Reset i ponownego uruchomienia. Było to spowodowane pozostawieniem "przypadkowej" wartości w PEEK(106), co poprawiłem w liniach 1700 i 1710 przed GR.0 dodając POKE 106,SCR i mniej ważne POKE 82,2 i jakoś działa ;) Dopisałem też w 1690, ale i tak ponowne wczytanie TB zawiesza po resecie;).
Co ciekawe, przy okazji okazało się, że Turbo Basic inaczej znajduje pamięć ekranu w przypadku Plot i Drawto, niż w przypadku Text, który „nie działał”, co widać w przypadku Lotto.

Bluki, gdyby nie te usterki program byłby znakomity, więc mam nadzieję, że je poprawisz :)

PS. Ostatnio tyle siedzę przy emulatorze, że już TV chce przyspieszać naciskając F7 :)
- 64F_KIT_REV3.7z
- 47: CommentAuthormono
- CommentTime21 Oct 2011 zmieniony
Rozmiar pliku w SDX możesz przeczytać jednym XIO 39. Konkretów dowiesz się jak zwykle z Atariki.
W Atari DOS jest nieco trudniej. Co mi przychodzi do głowy to odczytanie długości pliku w sektorach (DIR), ustawienie się funkcją POINT na ostatnim sektorze i odczyt bajt po bajcie aż dostaniesz EOL.

Edit: AtariDOS... Ewentualnie można jeszcze wykorzystać metodę binarną do odkrycia ilości bajtów w ostatnim bloku.

Edit 2: Paranoja! AtariDOS i pochodne używają w NOTE/POINT fizycznego nru sektora dyskietki a nie kolejnego nru sektora w pliku. Wygląda na to, że chcąc uzyskać rozmiar takiego pliku należy faktycznie przeczytać kolejno wszystkie bajty :/ Przepraszam za zamieszanie (chyba przyzwyczaiłem się do SDX za bardzo :D).
- 48: CommentAuthorQTZ
- CommentTime22 Oct 2011 zmieniony
Ok, zrobiłem tak jak napisałeś Mono, nic nie namieszałeś! Chyba wpadliśmy na ten sam pomysł w tej samej chwili :). Wielkie dzięki! Sądziłem, że da się to zrobić bardziej elegancko, ale wygląda na to, że nie ma innego wyjścia. W manualu nie ma opisu do Point więc link też się przydał :).

DIR rozwiązałem tak jak to zrobił Bluki w TBL. Do ustalenia początku pliku posłużyłem się omówionym wyżej przez Bluki'ego i używanym w 64 Figurach rejestrem DAUX. Dzięki Bluki!

Jedynym problemem było ustalenie wielkości sektora z czym sobie poradziłem odczytując Bajt 17 w sektorze 1. Jeden Bajt, bo wskaźnik w Point może mieć wartość od 0 do 255, więc stąd wniosek, że sektor nie może być większy.
Jednak nie wiem czy zawsze w tym miejscu jest wielkość sektora, więc czy zawsze tak jest prawidłowo? Może trzeba to zrobić inaczej?

Co ciekawe gdy sformatowałem większy plik atr (pojemność była i tak podobna, więc prawdopodobnie zrobiłem to nieprawidłowo) Point przy niektórych plikach zwracał błąd 166 i to mimo, że wywołuję go przy każdym pliku z dokładnie takimi samymi parametrami.

Trochę to dziwne, że raz można ustawić Point poza obszar otwartego pliku, a do tego w niektórych przypadkach już nie...

Program działa prawidłowo na oryginalnej dyskietce z kit'em i mojej wersji, a mają one różną wielkość sektorów. Nie wiem jednak jak utworzyć dysk z dowolną wielkością sektorów i jakie są standardowe - moje tworzone pod emulatorem mają sektory 125 Bajtów i mimo różnych ustawień przy tworzeniu atr'a po sformatowaniu jest podobnie.

DOS nie kopiuje pustych plików więc użyłem MakeATR'a ;), który mówiąc na marginesie, wyświetla rozmiar sektora błednie - w obu przypadkach 128B.

Edit:
Usunąłem załączony plik. Poprawioną wersję dołączyłem dalej.
- 49: CommentAuthormono
- CommentTime22 Oct 2011
Test na sektorze 1 nie zadziała dobrze, bo sektory 1..3 mają dla dyskietek rozmiar 128 bajtów. POINT przeprowadzaj na sektorze >= 4.
- 50: CommentAuthorQTZ
- CommentTime22 Oct 2011
No tak, ale w sektorze 1 jest zapisana wielkość dalszych sektorów (no chyba, że trafiłem przypadkowo na prawidłową wartość)... Więc skąd/jak można ją odczytać?

Od 1 do 50 z 101