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.

KRET - gra zręcznościowo-logiczna

Od 51 do 79 z 79

- 1:
  
  CommentAuthorpebe
- CommentTime2 May 2021 19:05 zmieniony
Znowu ja i Krecik.

Jeszcze nie grywalna, ale co raz bliżej, co raz bliżej...

- Zrobiony Joystick (przynajmniej u mnie działa :|)
- Ekran tytułowy
- Historia

TO DO:
- Poziomy - może jednak ktoś ma pomysł?
- Bonus
- Game Over - choć ten w pewnym sensie już jest :D
- Lista najlepszych i wpisywanie na listę.

przypomnę jeszcze z wcześniejszego postu, co może wpływać na trudność gry:

- szybkość spadania kloców
- szybkość po jakim klocek zaczyna się kruszyć
- szybkość kruszenia się klocka
- kret2.xex
- 2:
  
  CommentAuthorKaz
- CommentTime2 May 2021 19:05
Bardzo przyjemnie to wygląda!
- 3:
  
  CommentAuthorpebe
- CommentTime2 May 2021 20:05 zmieniony
@Kaz: Dziękuję. Jak widzisz, sporo pracy w to włożyłem i jestem mega zadowolon. Wiele pomysłów mam, co do tej gry. Zwłaszcza w kontekście efektów, jednak mam problem z optymalizacją, by ładnie efekty wyglądały (zwłaszcza, żeby mieścieściły się w "ramce")

Do tego, nie korzystam z gotowców, jak np. RMT. Stworzyłem prosty mechanizm, pozwalający odtwarzać dźwięki pod przerwaniem (nie jest to optymalna procedura)

Mam też pomysł na historię, która składałaby się z kilku obrazków (takich panoramicznych) i do tego pod spodem tekst. Jednak, grafikiem (aż tak zaawansowanym) nie jestem (próbowałem) To by miło wzbogaciło ten jakże egzotyczny fragment gry.

Jak (być może) zauważyłeś, padł też pomysł, by wykorzystać FujiNet do przechowywania listy wyników - jak dla mnie, bomba sprawa.

No i muzyka, która łagodzi obyczaje :P Do tego potrzebny SFX-Tracker (sam wymyśliłem :P) Czyli trzeba go napisać.

Ale... póki co, wszystko ładnie działa. Póki co, czas jest.
- 4: CommentAuthorkrzysztofk78
- CommentTime3 May 2021 15:05
@pebe

Nowy krecik jest uroczy a animacja uchodzenia z niego duszy wspaniała! Bardzo przyjemnie spędza się czas z Twoją grą. Trzymam kciuki za dalsze prace!!!!
- 5: CommentAuthorVidol
- CommentTime3 May 2021 15:05
Fajna gierka, tylko zapomniales o atract mode - po ok 10 minutach plansza tytulowa zmienia kolory tak samo jest podczas grania. Wystarczy wstawic w oczekiwaniu na ramke: sta $4d :)
- kolory.png
- 6:
  
  CommentAuthorpebe
- CommentTime3 May 2021 15:05
@Vidol: Tak, Dzięki. Już zmienione :)
- 7:
  
  CommentAuthorpebe
- CommentTime3 May 2021 15:05
krzysztofk78: Bardzo mi miło :) Ta animacja mnie niesamowicie bawi - tak bardzo, że mógłbym zaśpiewać Rotę :D:D:D ;)
- 8:
  
  CommentAuthorzbylu
- CommentTime3 May 2021 16:05
No to też jest i gameplay z nowej wersji Kreta:
- 9:
  
  CommentAuthorpebe
- CommentTime3 May 2021 16:05
@zbylu: jak zwykle, rękę na pulsie trzymasz ^_^
- 10:
  
  CommentAuthorpebe
- CommentTime6 May 2021 14:05
Trochę nowinek związanych z Krecikiem.

---

Po pierwsze: Krecik stoi w miejscu - póki co - a już tłumaczę czemu:

"Kret" aż się prosi o muzykę, a że wystartowałem z poziomu Turbo Basica, to napisałem własny silnik zwany przeze mnie SFX do uzyskania dźwięków pod przerwaniem VBlank.
Silnik ten przeniosłem do wersji MAD Pascalowej.

Jako, że lubię "wszystko sam", postanowiłem uruchomić nowy projekt o nazwie "SFX-Tracker".
To natywny tracker dla Atari, oparty o autorski silnik dźwiękowy SFX wykorzystany w grze Kret.
Będzie to prosty, czterościeżkowy traker jakich wiele, bez wodotrysków dźwiękowych (przynajmniej na razie :P) Ma zagrać melodię na kilku kanałach i tyle.

---

Po drugie: Jest niespodzianka, a nawet dwie i jedną Wam zdradzę.
Jest to pomysł, który podsunęła mi moja siostrzenica.
Ponieważ, w grze przewidziana jest runda bonusowa co poziom, to w tej rundzie, będzie się zbierało "coś" (pieniążek, gwiazdkę, albo coś innego).
Co kilka poziomów będzie... UWAGA!!! Boss :D Jak to opisała siostrzenica: "może by tak rzucać tymi gwiazdkami/pieniążkami w tego Sadystę?"
No i mnie urzekła tym :D

Tak więc, jest świetny pomysł.

Potrzebowałbym jeno grafiki Sadysty/Bossa :D Musi być na znakach, dość ograniczony, bo jest to tryb 20x12 w 5 kolorach.
Jest do dyspozycji trochę znaków, ok.47-48:
- 1 pusty na tło,
- 8 zajmują bloki,
- ze 2-3 na element bonusowy,
- 3 murki
- reszta do wykorzystania. Może być animowany - np. jak rzuca klockami. :P
To tylko tak, jak by się ktoś chciał zapisać w Creditsach :P
lub po prostu przyczynić do powstania ciekawszej gry :)

---

Po trzecie: Prawdopodobnie zmienię historię, bo ta się jakoś nie klei, a po za tym, dostałem świetny pomysł od Kaza - za co WIELGACHNE DZIĘKI, ja nie umiem w historie :P

Krecik dostał imię hahaha...

"Kret Stefan :D z powodu swojej ślepoty, nieopatrznie wszedł do magazynu z paczkami. Niezdarnie się poruszając spowodował, że wszystkie się na niego przewracają. Musi uniknąć zgniecenia i odszukać wyjście."

Prosta i idealnie odzwierciedlająca temat gry. Ta dieta ceglana, jakoś nie przemawia do mnie :P

---

Według mnie, dzieje się. :D

Pozdrawiam fanów Kreta.
- 11: CommentAuthorzyga64
- CommentTime7 May 2021 20:05
Trochę OT, ale pod Debianem fajnie działa mi Flash Player Projector (standalone) od Adobe ->link<-
- 12:
  
  CommentAuthorpebe
- CommentTime7 May 2021 21:05
@zyga64: Ściągłem, uruchomiłem, jednak nie odpala mi edytora PMG. W konsoli dostałem komunikat:
Failed to open VDPAU backend libvdpau_i965.so: nie można otworzyć pliku obiektu dzielonego: Nie ma takiego pliku ani katalogu

Prawdopodobnie (nie wiem, bo nie chce mi się sprawdzać) chodzi o biblioteki związane z Adobe. Wiem, że ich nie mam, bo je odinstalowałem.

Na dzień dzisiejszy, świetnie sprawuje się paczka od Bocianu pod Wine :D i tylko do tej apki do edycji PMG go potrzebuje.

Jednak dzięki za info. Być może, kiedyś pobawię bardziej.
- 13:
  
  CommentAuthorKaz
- CommentTime9 May 2021 11:05
PeBe - cieszę się, że przypadło Ci do gustu moja propozycja :)

Co do poziomów trudności, to można regulację zrobić na wiele sposobów, również w menu, ustawianą przez gracza. Jeżeli miałbym coś zaproponować, to najlepiej, aby wszystkie parametry (szybkość spadania kloców, szybkość po jakim klocek zaczyna się kruszyć, szybkość kruszenia się klocka) wzrastały równomiernie. Ale to do przetestowania i rozważenia.
- 14:
  
  CommentAuthorpebe
- CommentTime14 May 2021 21:05
Zważywszy na dzisiejszą niewielką awarię mojego kompa, postanowiłem w końcu zabezpieczyć swój "dorobek"

Kret jest dostępny na GitHubie:

->link<-
- 15:
  
  CommentAuthorpebe
- CommentTime26 Aug 2021 20:08 zmieniony
Hej.

Po dość długiej przerwie na "tapetę" wrócił Krecik :)

Na chwilę obecną, jest wersja nie wiele się różni od tej z maja.
Zintegrowałem silnik SFX, aby to on zajmował się częścią dźwiękową.
Doszły też muzyczki:
- tytułowa, napisana przez @tatqoo. Pewnie ją kojarzycie ze spotkania ze mną i SFX-Trackerem. @Tatqoo przyjął moją prośbę o jej rozwinięcie, jak i stworzenie melodii dla "Szykuj się Krecie", "Kret Zdechł" oraz dla "Listy najlepszych", za co niezmiernie mu dziękuję.
- melodie "Szykuj się Krecie" oraz "Kret Zdechł" to melodie mojego autorstwa - nic specjalnego. Stworzone na potrzeby testów.
- dźwięki w grze zachowałem takie jakie były. Dostosowałem je tylko do wymogów SFX-Engine, gdyż ten "tick" ma co ramkę, a pierwowzór robił to co drugą ramkę ekranu. To zwiększyło ilość danych, ale przynajmniej wiernie brzmi :P.

Zaszła też ciekawa sytuacja, gdyż, zastosowane przeze mnie rozwiązanie timerów w grze, nie współgrało z SFX-Engine.
Tak do końca, nie wiem, co było przyczyną jego złego funkcjonowania, ale lubiły się zawiesić (tak to się objawiało w grze)
Nie był to najwydajniejszy proces, bo na każdy timer poświęcałem 4 bajty (typ `longint`). Główny timer (także `longint`) był brany z rejestrów 12-14 (rclock)
Wszystkie były synchronizowane do głównego timera, a różnica pomiędzy głównym a testowanym timerem, dawała czas, który był sprawdzany. Jeśli przekroczył zadany limit, wykonywana była akcja.
w skrócie:
```
(* w pętli gry *)
   globalTimer:=getTime; // wartość rejestrów 12-14

   (* gdzieś w grze *)
   if (globalTimer-myTimer>=50) then // 50, limit timera
   begin
      myTimer:=globalTimer; // reset timera
      (* akcja *)
   end;
```
Działało, dopóki nie wrzuciłem SFX-Engine :P

Sam rclock działał poprawnie w momencie, gdy się "zawieszała" gra, jednak gdzieś, coś było nadpisywane (na stronie zerowej) co powodowało zwis, albo cholera wie gdzie :/
Rejestry SFX-Engine były umieszczone (na stronie zerowej) od $E8 do $FC. Z tego co pokazywał kompilator, wykorzystanie ZP przez program to $80-$D7, więc zakładam, że to nie wina MADzi.

W każdym razie, zmieniłem rozwiązanie timerów.

Teraz, każdy timer jest typem dostosowany do wymagań, tzn. jeśli nie trzeba długich czasów (ponad 5 sekund) wykorzystuje tylko typ `byte`. Chyba tylko jeden timer mam typu `word`.
Zasada funkcjonowania timerów jest trywialn:
W pętli głównej (można by to umieścić pod przerwaniem DLI albo VBL) co ramkę wywoływany jest blok, który zmniejsza każdy z liczników (timerów) o jeden, tylko gdy ten, jest większy od zera.
Wywołanie akcji następuje przez sprawdzenie czy timer jest równy zero, jeśli jest, przywracany jest stan timera i akcja zaczyna się od nowa.

w skrócie:
```
(* inicjacja przed pętlą gry *)
   myTimer:=50;

   (* główna pętla gry *)
   if (_timer-o_timer>0) then
   begin
      if myTimer>0 then dec(myTimer);
      o_timer:=_timer;
   end;

   (* gdzieś w grze *)
   if (myTimer=0) then
   begin
     myTimer:=50;
     (* akcja *)
   end;
```
Nie chodzi o chwalenie się :P tylko o przedstawienie, że powyższe (nowe) rozwiązanie, sprawdza się z silnikiem SFX-Engine.
Także tego. Silnik wymaga testowania, a jego wdrożenie w "prawie gotowy" produkt, może okazać się problematyczne.

W załączniku XEXik z krecikiem okraszonym dźwiękami spod SFX Trackera. A poniżej filmik:
- kret3.xex
- 16:
  
  CommentAuthorpebe
- CommentTime11 Sep 2021 16:09 zmieniony
Mam pustkę w głowie.

Dodałem "pieniążki" w głównej rozgrywce, jednak nie bardzo mi się to podoba, tzn. są za mało "pieniążkowate" :D A mówiąc jaśniej, brakuje mi dla nich koloru, a nie chcę rezygnować z koloru klocka, bo się zrobi monotonnie (chyba)

PS. "Coinsy" się na razie nie animują.

Zastanawiam się, jak je zrobić na PMG, bo mam dwa playery wolne. Problem w tym, że dwa playery to ciut mało, a nie umiem multiplikować PMG :( Zwłaszcza, że tytułowy Krecik jest w pojedynczej rozdzielczości, a pole gry odpowiada podwójnej - choć to nieco sztuczny problem. Gorzej, gdy w jednej linii znajdzie się więcej "pieniążka" :(

Po za tym, zaczyna mnie drażnić pasek z BONUSem. Niby sam to wymyśliłem, ale nie bardzo umiem sobie wyobrazić teraz tą rundę bonusową.

Boss. Tu kolejny zgrzyt. Pierwotnie miał stać w miejscu i rzucać cegłami, tzn. paczkami. Teraz, ma się ruszać (tzn. tak sobie wymyśliłem :P) Jednak nie będzie się poruszał płynnie, bo to tryb znakowy - a ja nie umiem płynnie w znakach.

Nie wiem. Strasznie rozdarty z tą grą jestem :(

Jedyne, co mi się spodobało to, efekt głębi jaki powstał po dodaniu tła w polu gry, który psują nieco "coinsy" :/
- 17: CommentAuthorastrofor
- CommentTime11 Sep 2021 21:09
Kret zapowiada się super. Gdyby kiedyś Pebe miał trochę czasu i pokombinował nad czymś jakby frameworkiem do przesuwania klocków opartych na czcionkach, aby potem można było z tego zrobić jakąś grę turowo logiczną to byłoby super. Ja zawsze obiecywałęm sobię że jak będe miał sporo wolnego czasu to nauczę się mapy pamięci atari, ale czasu coraz mniej, myślę że są ludzie co mają podobnie. Z pascalem chyba nikt nie ma problemów, także jakby się cośtakiego udało to było by super. Pozdrawiam mocno.
- 18:
  
  CommentAuthorpebe
- CommentTime12 Sep 2021 08:09
Kret zapowiada się super.

Dzięki.
Jest dużo pomysłów, jednak... pomysły to nie wszystko. :)

(...)frameworkiem do przesuwania klocków opartych na czcionkach(..)

Rozwiń proszę temat, bo nie wiem, jakie pytania zadać :D ;)

Ja zawsze obiecywałęm sobię że jak będe miał sporo wolnego czasu to nauczę się mapy pamięci atari, ale czasu coraz mniej, myślę że są ludzie co mają podobnie.

To nie do końca jest tak.
Podstawą wszystkiego są mobilizacja i chęć działania (o ile to nie to samo? :P)
Czas jest ważny, jednak nie najważniejszy.

Z pascalem chyba nikt nie ma problemów(...)

Hihi, ośmielę się stwierdzić, że: "Z Pascalem jak z Kobietą. Zmienna jest." ;)
- 19: CommentAuthorastrofor
- CommentTime12 Sep 2021 09:09 zmieniony
Chodzi mi o cos takiego jak phaser na atari...No powiedzmy ;). Chodzi o latwe przesuwanie klockow (tilesow) na ekranie, z tego co widzialem to tablice klockow masz w zmiennych blocksList i chyba w jakiejs drugiej tez. Chodzi o procedury add font to block, czyli wyswietlanie w danym bloku danego fonta, oraz remove font from block, albo change font in block.
Czyli wlasciwie (2,3) procedury.
Dzieki temu w moim mniemamniu bez znajomosci assemblera mozna zaimlementowac wlasciwie kazda turową gre logiczna. Oczywiście nawet nie wspomionam o zasobach i wydajności. Powiedzmy ze cala pamiec idzie wlasnie na ten cel, wiec bez muzyki itd. Wydajnosc jezeli chodzi o turowke tez nie jest priorytetem chyba.
Pascal na atari jest o tyle fajny o ile fajne jest jego community wspierające, sam autor, Bocianu i sporo ludzi pomagających na forum aol. Ja bym tez wolał c , ale tu już nieco trudniej o biblioteki i wsparcie. Sprajty tez moze dalo by sie prosto zrobic ale bez nich da się żyć. Celem jest więc tworzenie prototypów ciekawych(albo i nie) pomysłów na gry. Jak gra się spodoba to można będzie o niej myśleć dalej.
edit: oczywiscie calosc mozna zalatwic zapomoca instrukcji putcharatxy, ale to jest hardcore nawet dla autora.
- 20:
  
  CommentAuthorpebe
- CommentTime12 Sep 2021 11:09 zmieniony
@astrofor:
Słowem wstępu:
Klocki (tiles) w Krecie to dwie tablice: ich definicje i lista.
Używam pojedynczego zestawu znaków - bo więcej nie potrzebuje :)

Definicje klocków - ze względu na ich prostotę - to bloki po 8 bajtów każdy (prostota wyliczenia offsetu dla definicji 'blockId shl 3')
Każda definicja klocka zawiera:
- szerokość i wysokość opisu (w znakach), po jednym bajcie dla każdej wartości.
- po tym, idzie do 6 bajtów opisu klocka (tablica `[1..szerokość][1..wysokość]`)

Lista klocków - to tablica do 64 elementów, gdzie w skład elementów wchodzą:
- położenie klocka (kolumna i wiersz na ekranie)
- rodzaj klocka (id definicji)
- kolor (0-3, bity 7 i 6 znaku ekranowego w trybie antic 2)

Odpowiadając w kwestii frameworka:
Oczywiście, nie jest to nie możliwe do wykonania. Dużo zależy od stopnia skomplikowania, tj:
najważniejsze:
- rodzaj pola gry: graficzny (bitmapa) czy tekstowy (charset)?

- jak dużo definicji tilesów chcemy mieć
- jak duże ich definicje mają być
- czy używamy opisu bitmapowego, czy znakowego
- czy stosujemy maskę tła
- precyzja wyświetlania tilesa (chciałem napisać: "precyzja stawiania klocka" :D) tzn. z dokładnością do znaku (tak jak w Krecie) czy do piksela
- kolizje i ich rodzaj?

Do tego dochodzi kwestia buforowania wyświetlania. Ja w kreciku zastosowałem bufor pośredni dla wyświetlanych klocków, gdzie najpierw rysuje wszystkie klocki w buforze a później, kopiuje na ekran (wiem, można by to cyknąć przez zmianę adresu ekranu :P)

Tak dużo pytań, tak mało odpowiedzi ;)

PS. Czym jest phaser? :|

edit: oczywiscie calosc mozna zalatwic zapomoca instrukcji putcharatxy, ale to jest hardcore nawet dla autora.

Haha, szkoda, że nie mam pierwszych wersji Kreta pisanych w TurboBasicu. To był hardcore. Wszystko było w nim napisane od zera (nie było pół kodu assemblera) Linie DATA z definicjami, przerzut do tablic... masakiera.
Ale działało, z tym że grać się nie dało :P I to był punkt wyjścia do rozpoczęcia prac implementacyjnych w ASM (równie hardorowo, bo natywnie w QA). Później, przesiadka na MADzie.
- 21: CommentAuthorastrofor
- CommentTime13 Sep 2021 00:09
Chyba na przedefiniowanych czcionkach utworzonych w jakims font makerze do atari. Mysle ze definicje tilesow sa niepotrzebne. x i y powinny byc wyznaczany na postawie indeksow elementow tablicy. Nie wiem jak przypozadkowac wartosc tablicy do do elemenu graficznego tilesa, szczegolnie jezeli bedzie mozliwosc polaczenia paru fontow w 1 element tilesa. Chodzi o to żeby framework byl tylko i wylacznie do wyswietlania tilesow. Detekcja kolizji i inne rzeczy beda poza frameworkiem.Ekran bedzie sie odswierzal tylko po iteracji gracza, albo po dlugim timerze - nie krótszym niz sekunda, takze szybkosc raczej nie jest wazna. Natomiast bufor ekranu brzmi bardzo dobrze.
- 22:
  
  CommentAuthorpebe
- CommentTime13 Sep 2021 20:09 zmieniony
@astrofor: Robi się co raz bardziej technicznie i zastanawiam się nad utworzeniem osobnego wątku dla tematu frameworka.

Mysle ze definicje tilesow sa niepotrzebne.

A ja jestem nieco innego zdania :)
Fakt, to dodatkowy obszar pamięci, ale pozwoliłyby zaoszczędzić na znakach które się powtarzają (przynajmniej w teori) Dodatkowo...
Nie wiem jak przypozadkowac wartosc tablicy do do elemenu graficznego tilesa, szczegolnie jezeli bedzie mozliwosc polaczenia paru fontow w 1 element tilesa.

...rozwiązują właśnie problem przypisywania indeksów w tablicy generowanych kafli.

Łączenie kilku fontów w jeden kafel? Będzie ciężko, bo to kolejny koszt dla pamięci, gdyż dla każdego znaku opisującego kafel trzeba określić, z jakiego zestawu będzie pobierany.
Chyba że, ograniczy się ilość zestawów do np. 4 to wtedy można spakować dane po cztery w jednym bajcie, np.
```
%aabbccdd $d1 $d2 $d3 $d4

gdzie:
aa,bb,cc,dd - to bity opisujące przynależność do zestawu danych d?
d1-4 - znaki opisujące kafel
```
Dla zwięzłości, nie ograniczałoby to szerokości definiowanego kafla, bo np.
w trybie 40x25x5 kolorów, dla kafla o szerokości 6 znaków (tj. 24 pixele=4x6) i wysokości 3 znaków (24 pixele=3x8) definicja wyglądałaby następująco:
```
$06 $03 ; szerokość i wysokość definicji
1: %aabbccdd $d1  $d2  $d3  $d4  %aabb0000 $d5  $d6
2: %aabbccdd $d7  $d8  $d9  $d10 %aabb0000 $d11 $d12
3: %aabbccdd $d13 $d14 $d15 $d16 %aabb0000 $d17 $d18

gdzie:
1-3 to wiersz definicji :)
aa,bb,cc,dd - to bity opisujące przynależność do zestawu danych d?
d1-18 - znaki opisujące kafel
```
Całość zwiększa się o jedyne 6 bajtów, co daje łącznie 18+6+2=26 bajty, a nie 18+18+2=38 bajtów!
Jedynie ogranicza to ilość możliwych do zdefiniowania zestawów znaków.

Można by to jeszcze inaczej zrobić. Dodać jeden bajt informacji do definicji:
```
%s6543210

gdzie bity:
0-6, określają zestaw znaków
7 (czyli 's'), oznacza wykorzystanie czterech sąsiadujących zestawów, począwszy od wartości określonej w bitach 0-6
```
Czyli, taka definicja wyglądałaby wtedy tak:
```
%10000000 ; definicja wykorzystuje 4 zestawy znaków (od 0 do 3)
$06 $03 ; szerokość i wysokość definicji
1: %aabbccdd $d1  $d2  $d3  $d4  %aabb0000 $d5  $d6
2: %aabbccdd $d7  $d8  $d9  $d10 %aabb0000 $d11 $d12
3: %aabbccdd $d13 $d14 $d15 $d16 %aabb0000 $d17 $d18
```
```
%00000000 ; definicja korzysta z jednego zestawu (zestaw 0)
$06 $03 ; szerokość i wysokość definicji
1: $d1  $d2  $d3  $d4  $d5  $d6
2: $d7  $d8  $d9  $d10 $d11 $d12
3: $d13 $d14 $d15 $d16 $d17 $d18
```
Innymi słowy, można zdecydować, czy definicja kafla będzie mieściła się w jednym zestawie, czy też w czterech.

Na ile takie podejście będzie wydajne, trudno mi powiedzieć :) Trzeba by to sprawdzić.
Z pewnością będzie mniej wydajna, niż definicja kafla oparta na jednym zestawie - to oczywiste.

Chodzi o to żeby framework byl tylko i wylacznie do wyswietlania tilesow. Detekcja kolizji i inne rzeczy beda poza frameworkiem.Ekran bedzie sie odswierzal tylko po iteracji gracza, albo po dlugim timerze - nie krótszym niz sekunda, takze szybkosc raczej nie jest wazna.

To bardzo dobrze :D

Natomiast bufor ekranu brzmi bardzo dobrze.

To zawsze jest dobre rozwiązanie, jednak kosztuje pamięć.

Tu nasuwa się pytanie związane z organizacją ekranu.
Czy będzie to czysty tryb graficzny czy znakowy? Bo każdy ma swoje wady i zalety - przynajmniej w moim odczuciu, które przedstawię jutro, bo dziś już późno, zmęczony jestem i jutro "zu arbeit" wcześnie (w końcu, po 1,5 roku :D )
- 23: CommentAuthorastrofor
- CommentTime13 Sep 2021 21:09
Jeżeli chodzi o tryb, to pewnie taki gdzie łatwo się będzie się edytować kafelki, wiem że na fontach to jest jakiś atari font maker, jeżeli chodzi o grafikę to jeżeli dało by się sczytać jakiś tileset z bmp(określona szerokość kafelka) to też byłoby super.
Wydaje mi się też że na początek zrobić 1 font = 1 klocek. Lepiej zrobić prosto niż niedokończone.
Czyli rysowanie moglo by wygladac:
Byla by funkcja flush - czyli flushowanie bufora ekranu na ekran - w skrócie refresh ekranu.
1) jako rysowanie z tablicy z danymi, i po wywolywaniu flusha porownywalo by sie poprzednia tablice z danymi do obecnej i zmienialo tylko rozniace sie klocki.
2) jako funkcje drawtileatxy, wtedy draw bylby na buforowanym ekranie wiec flush rysowalby na wszystkie zmiany buforowanego ekranu na raz.
- 24:
  
  CommentAuthorpebe
- CommentTime14 Sep 2021 18:09 zmieniony
@astrofor:
Zacznę może od tego, co masz na myśli pisząc "1 font=1 klocek"? Czy chodzi Ci o jeden zestaw znaków na klocek? Czy może o 1 znak fonta?
Wiem, że to skrajne pytania, jednak nie mogę załapać Twojej istoty definicji pewnych rzeczy.

Może inaczej. Przedstawię, jak ja to widzę w swojej głowie.
Atari Font Maker to przyjazna i szybka aplikacja do tworzenia znaków dla Atari - fakt. Pozwala zdefiniować dwa zestawy znaków oraz mieć ich podgląd w oknie gdzie można je "miksować" z "dokładnością" do linii (sory za skrót myślowy)
Sam korzystam z AFM, by tworzyć znaki, czy tilesy do swoich produkcji.
Jednak zdarzało mi się, że brakowało znaków i tworzyłem nowy, dodatkowy zestaw.

Aby wykorzystać więcej niż jeden zestaw znaków, warto rozważyć tryb znakowy (jak w Graph2Font) Czyli na treść ekranu roboczego, przeznaczonych jest kilkanaście zestawów znaków, plus, pamięć ekranu oraz Display Lista wraz z przerwaniem DLI.

Najbardziej korzystny tryb to 32x24 znaki...
```
0: zestaw znaków #0; znaki: #0 do #31
 1: znaki: #32 do 63
 2: #64 do #95
 3: #96 do #127
 4: zestaw znaków #1; znaki: #0 do #31
 5: znaki: #32 do 63
 6: #64 do #95
 7: #96 do #127
 8: zestaw znaków #2; znaki: #0 do #31
 9: znaki: #32 do 63
10: #64 do #95
11: #96 do #127
12: zestaw znaków #3; znaki: #0 do #31
13: znaki: #32 do 63
14: #64 do #95
15: #96 do #127
16: zestaw znaków #4; znaki: #0 do #31
17: znaki: #32 do 63
18: #64 do #95
19: #96 do #127
20: zestaw znaków #5; znaki: #0 do #31
21: znaki: #32 do 63
22: #64 do #95
23: #96 do #127
```
...gdzie wykorzystanych jest 6 zestawów znaków w całości, tzn. wszystkie 128 możliwych do zdefiniowania znaków.
Wykorzystanie pamięci przy ekranie 32x24 znaki (bez Display Listy)

768 bajtów na dane ekranu
6144 bajty na definicje charsetów
----
6912 bajty (6,75 KB)

Porównujac z trybem graficznym (128x192 pixele)
6144 bajty na dane ekranu

Oczywiście jest to układ który wypełnia praktycznie cały ekran w pionie - wcale nie musi tak być :) i co za tym idzie, zmienia to wykorzystanie zestawów znaków (charsetów)

W innych trybach, np 40 znaków w linii, robią się już luki (gapy) w zestawach. z prostej przyczyny:
128 [zn/charset] / 40 [zn/ln] = 3, reszty 8

8 znaków jest nie wykorzystanych w zestawie.
```
0: zestaw znaków #0; znaki: #0 do #39
 1: znaki: #40 do 79
 2: #80 do #119
 3: zestaw znaków #1; znaki: #0 do #39
 4: znaki: #40 do 79
 5: #80 do #119
 6: zestaw znaków #2; znaki: #0 do #39
 7: znaki: #40 do 79
 8: #80 do #119
 9: zestaw znaków #3; znaki: #0 do #39
10: znaki: #40 do 79
11: #80 do #119
12: zestaw znaków #4; znaki: #0 do #39
13: znaki: #40 do 79
14: #80 do #119
15: zestaw znaków #5; znaki: #0 do #39
16: znaki: #40 do 79
17: #80 do #119
18: zestaw znaków #6; znaki: #0 do #39
19: znaki: #40 do 79
20: #80 do #119
21: zestaw znaków #7; znaki: #0 do #39
22: znaki: #40 do 79
23: #80 do #119
```
Naturalnie, zwiększa się też ilość wykorzystanych zestawów do 8, a łączna ilość niewykorzystanych znaków to
8 [zn] * 8 [charset] = 64 znaki * 8 [bajtów]= 512 bajtów

Wykorzystanie pamięci przy ekranie 40x24 znaki (bez Display Listy)

960 bajtów na dane ekranu
8192 bajty na definicje charsetów w tym 512 bajtów Gapów
----
9152 bajty (niespełna 9 KB, ~8,5 KB nie licząc Gapów)

Porównujac z trybem graficznym (160x192 pixele)
7680 bajty na dane ekranu

Jeszcze gorzej jest w trybie Wide, czyli 48 znaków na linie, gdzie Gapy sięgają 32 znaków na zestaw. To jest 256 bajtów, co przy 8 zestawach daje 2KB! - to bardzo dużo, teoretycznie zmarnowanej, praktycznie poszatkowanej pamięci.
Jak dla mnie, kompletnie niepraktyczne z punku widzenia pola gry. Dobre dla statycznych ekranów, jakie generuje G2F, o tam dochodzi optymalizacja, która częściowo zmniejsza/usuwa Gapy.

Jak to się ma do trybów graficznych?
Po pierwsze, powyższa organizacja ekranu jest nie liniowa, tzn. bardziej odpowiada układowi ekranu C64 w trybach graficznych (z tego co się orientuje).
```
col       1     2     3     4             39
wiersz 1
        $0000 $0008 $0010 $0018         $0138
        $0001 $0009 .     .             $0139
        $0002 $000a .     .             $013a
        $0003 $000b .     .     ... ... $013b
        .     .     .     .             $013c
        .     .     .     .             $013d
        .     .     .     .             $013e
        $0007 $000f $0017 $001f         $013f

wiersz 2
        $0140 $0148 $0150 $0158         $0278
        $0141 $0149 .     .             $0279
        $0142 $014a .     .             $027a
        $0143 $014b .     .     ... ... $027b
        .     .     .     .             $027c
        .     .     .     .             $027d
        .     .     .     .             $027e
        $0147 $014f $0157 $0157         $027f


        itd.
```
Po drugie, tryby graficzne są bardziej logiczne w dostępie do pamięci (co nie znaczy, że są szybsze!) Mają liniowy układ pamięci, przez co dostęp do pojedynczych linii ekranu (obrazu) odbywa się przez "prostą" kalkulację:
nr.linii * szer.ekranu w znakach

szerokość ekranu dla trybów:
Narrow 32 bajty = 128 pixeli (dla trybu 4/5 kolorów)
Normal 40 bajtów = 160 pixeli (j.w.)
Wide 48 bajtów = 192 pixele (j.w.)

Po trzecie, tryby graficzne nie oferują 5 koloru, wynikającego z trybu INVERS znaków.
Chociaż! Ten 5 kolor (w przypadku trybów tekstowych) może sporo namieszać w logice rysowania tilesów - złaszcza, jak będą nakładane na siebie.

Słowo ode mnie
Przedstawione powyżej informacje to TYLKO i wyłącznie moje spostrzeżenia, które mogą być w pewnym stopniu niezgodne z wiedzą osób bardziej zorientowanych w takich rozwiązaniach. Są oparte TYLKO na własnej wiedzy w zakresie możliwości małego Atari :)

Nigdy nie bawiłem trybem znakowym takim jak G2F i nie mam doświadczenia w jego programowaniu. Jednak z tego, co mi logika podsuwa, jest on wydajniejszy - zwłaszcza przy "składaniu" ekranu z tilesów, które są wyrównane co do znaku, tzn. gdzie nie trzeba "łamać" tilesa, by ustawić go co do pixela, tzn. ich pozycja x w pixelach jest podzielna przez 4 bez reszty :)

Podsumowując
Mogę spróbować pokusić się o zrobienie takiego Unita dla MAD Pascala. Sam z chęcią skorzystam z takiego frameworka przy próbie powrotu do tematu Archon Adventures - który (chcąc nie chcąc) ciągle siedzi w głowie :P
Jednak nie mogę obiecać, że taki framework powstanie na 100% :D
- 25: CommentAuthorastrofor
- CommentTime14 Sep 2021 23:09
Myślę że do gry wystarczy pewnie 1 zestaw znaków - tak 30 rodzajow klockow powinno wystarczyc zdecydowanie.
Ilosc klockow na ekranie byla by ok gdyby bylo tyle co w krecie, plus może jeden wiecej wiersz, tam gdzie jest teraz pasek bonus. Z kolorami to bedzie problem, w sensie implementacja kolorowego klocka bedzie trudna, wiec mysle zeby zrobic 2 kolorowe, z mozliwoscia zmianu koloru klocka - w sensie tlo plancszy niezmienne , a kolor klocka do wybory z 4 kolorow. To komplikuje tablice z danymi bo zamiast pojedynczych wartosci, bedzie struktura, albo 2 tablice.
Podsumowując sensowność to nie wiem. Nie wydaje mi się aby bylo jakies szczegolne zainteresowanie tym projektem, jak ktos cos tworzy na atari, to raczej robi takie rzeczy sam, ja lubie projektowac prototypy gier, a zupelnie nie mam czasu uczyc sie technikaliow atari, szczegolnie teraz jak niedawno urodził mi się mam nadzieje mały atarowiec ;) Jak cos takiego powstanie to postaram się zrobic jakiegos tutoriala - pewnie sokobana ktorego juz napisalem w mad pascalu ale na atascii.
- 26:
  
  CommentAuthorpebe
- CommentTime1 Nov 2021 20:11
Siema.

Praca skutecznie uszczupla wolny czas dla pasji, ale nie ma tego złego. Pozwala też zresetować umysł, poprzez wprowadzenie w życie pewnego rodzaju dysonansu.
Skutkiem tego, jest (miejmy nadzieję) ponowienie prac związanych z Krecikiem. Jednak nic na siłę. Powoli, ale do przodu.

Zobaczcie krótki filmik, a dowiecie się, co "zmontowałem" :P (gdzie nie gdzie, już napomknąłem o tym)

@astrofor: już się tłumaczyłem tu ->link<- ale, ponowię.
Jak na razie nie ruszyłem nic w temacie frameworku, ale ciągle pamiętam, więc, pewnie się kiedyś za to w końcu wezmę :)
- 27:
  
  CommentAuthormav
- CommentTime1 Nov 2021 20:11
Bardzo to brutalne "kret zdechł" ;) wcześniej wylatuje z niego aniołek, co jest takie słodziutkie i bardziej pokojowe, może by iść w tym kierunku jednak?
- 28:
  
  CommentAuthorpebe
- CommentTime1 Nov 2021 21:11 zmieniony
@mav: XD to się da zmienić. Pomyślę, a w między czasie, może ktoś coś zaproponuje w zamian za "Kret Zdechł" ? Będzie super.

PS. to jest tekst z oryginału.
- 29:
  
  CommentAuthorKaz
- CommentTime1 Nov 2021 22:11
Padł - jest bardziej dwuznaczne, bo może padł chwilowo (zmęczenie), a nie na zawsze.

Od 51 do 79 z 79