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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthorgrafi71
   • CommentTime18 Sep 2026 13:26 zmieniony

    
   Witam serdecznie!
   
   Po niezwykle ciepło przyjętym "Dzikim Zgonie"
   ->link<-
   
   pomyślałem że szkoda by było by przygotowane dlań assety się marnowały więc zmajstrowałem nową grę:
   ->link<-
   
   Tym razem całkiem zręcznościową.
   
   Lecisz w prawo smokiem, unikasz przeszkód, strzelasz, zbierasz znajdźki.
   
   W grze są "efekty dźwiękowe" ale brakuje muzyki, może jakieś sugestie? (albo może ktoś chciałby popełnić muzyczkę do gry?).
   
   Oczywiście vibe coding, tym razem 100% kodu stworzonego przez Gemini Flash (w większości 3.8).
   
   
   Cały projekt:
   ->link<-
   
   Have Fun!
   
   ---
   
   Było smaszno, a jaszmije smukwijne
   Świdrokrętnie na zegwniku wężały,
   Peliczaple stały smutcholijne
   I zbłąkinie rykoświstąkały.

   • jabberwocky.png
     
     
     
     
2. • 2:
      
     CommentAuthorKaz
   • CommentTime18 Sep 2026 16:36

    
   Pomysł rozgrywki ciekawy, dobra robota. Podoba mi się pomysł "hamowania" smoka zamiast jego przyspieszania. Pomysł z różnym terenem też fajny. Interakcje z nim - pomysłowe. Nie podoba mi się "pixel perfect" - nietolerancja dotknięcia jednego piksela przez smoka, którego ruch jest nieco bezwładny, obniża przyjemność z gry.
   
   Zdecydowanie trzeba poprawić, żeby kolizje działały powtarzalnie - teraz czasem jest kolizja z drzewem, czasem nie. Zdarzyło mi się też, że pojemnik z wodą mnie zabił, a przecież gdzie indziej pomaga przeżyć.
   
   No i warto by stopniować trudność. Teraz od razu jest gęsto, wszystko wkoło zabija. Gracz nie ma jak nauczyć się rozgrywki, które przedmioty są zagrożeniem, a które nie. Szczególnie, że często są do siebie podobne. Przez to na początku gra się w jak niesłynną grę "Piekiełko". Przygoda i trudność powinna być stopniowana, klasyczne podejście z gier arcade byłoby tu najbardziej trafione.
3. • 3: CommentAuthorgrafi71
   • CommentTime18 Sep 2026 16:56

    
   @Kaz
   
   Dzięki za miłe słowa, Twoje uwagi mniej więcej pokrywają się z moimi odczuciami, będzie co poprawiać :)
   
   Pozdrawiam!
4. • 4:
      
     CommentAuthorKaz
   • CommentTime18 Sep 2026 22:01

    
   No to trzymam kciuki, a tutaj króciutka zajawka o grze:
   
   
5. • 5:
      
     CommentAuthormav
   • CommentTime18 Sep 2026 23:38

    
   Mnie pokonują pierwsze dwa drzewa :)
6. • 6: CommentAuthorVidol
   • CommentTime19 Sep 2026 06:16

    
   Proponowałbym dodać pasek energii.
7. • 7:
      
     CommentAuthorKaz
   • CommentTime19 Sep 2026 07:37

    
   Ale po co drugi pasek energii?
8. • 8: CommentAuthorgrafi71
   • CommentTime19 Sep 2026 07:39

    
   @Kaz
   Jestem w szoku :))
   
   @Vidol
   Pasek energii jest - od góry.
   
   @mav
   Ja dochodzę do końca, ale to naprawdę trwało długo, trzeba pamiętać jak trudne były wtedy gry (krótkie ale trudne).
   
   
   Pracuję teraz nad lepszym zbalansowaniem rozgrywki, wykrywanie kolizji jest teraz (trochę) bardziej wybaczające, docelowo chciałbym by trudność rosła stopniowo - do pobrania nowy release 0.2.0:
   
   ->link<-
9. • 9:
      
     CommentAuthorKaz
   • CommentTime19 Sep 2026 08:07

    

   grafi71:

   W grze są "efekty dźwiękowe" ale brakuje muzyki, może jakieś sugestie? (albo może ktoś chciałby popełnić muzyczkę do gry?).

   
   
   Jakby nikt się nie zgłosił, to z chęcią udostępnię Ci jedną z niewykorzystanych muzyczek Andrzeja Kidaja, bo mam na to zgodę. A któraś z nich będzie pasować klimatem. Andrzej robił naprawdę fajne rzeczy na Atari.
10. • 10: CommentAuthorgrafi71
    • CommentTime19 Sep 2026 08:34

     
    @Kaz
    
    Super, wielkie dzięki, to jesteśmy umówieni :)
11. • 11: CommentAuthorVidol
    • CommentTime19 Sep 2026 09:11

     
    Prawdę mówiąc nie zauważyłem, bo niby jest ten pasek ale nic z niego skoro i tak się ginie po dotknięciu drzewa.
12. • 12:
       
      CommentAuthormgr_inz_rafal
    • CommentTime19 Sep 2026 21:48

     
    Bardzo trudna gra.
13. • 13: CommentAuthorilmenit
    • CommentTime20 Sep 2026 08:43

     
    Odnośnie 0.2.0:
    - kolizje polecałbym zrobić z tułowiem a nie ze skrzydłami. Dobra praktyka w grach mających hit-boxy jest taka, że negatywne kolizje mają mały hit-box, pozytywne (jak zbieranie przedmiotów) większy.
    - perspektywa jest "dziwna". Smok jest widziany z góry, ale inne elementy z boku. Proponowałbym smoka też dać "z boku"
    - nie jest łatwo stwiedzić co powoduje kolizję a co nie. Dwa pomysły - 1. jeden z kolorów zarezerwować do podkolorowania obiektów, które powodują kolizje, albo 2. dać smokowi cień (jak w Blue Max) dzięki czemu będzie widać jak wysoko leci, co by wskazywało graczowi czy element tła jest wyższy lub niższy.
    - czasem od razu po starcie gry się umiera (kolizja). Powinien być "grace period" albo poprzez odpowiednie przygotowanie poziomu, albo poprzez "tymczasową nieśmiertelność" (mruganie gracza).
    - przedmioty do zbierania też powinny być bardziej charakterystyczne np. ustandardyzowana ramka. Teraz nie wiadomo co jest do zbierania. Ewentualnie - też dedykowany albo dominujący kolor na nich.
14. • 14: CommentAuthorgrafi71
    • CommentTime20 Sep 2026 10:09 zmieniony

     
    @ilmenit
    
    Poniżej najnowszy release który ma zaadresowany problem z kolizjami - są dużo bardziej wybaczające.
    Wg mnie gra jest teraz za prosta :)
    Umieściłem jeszcze 2 dodatkowe poziomy.
    
    Release: ->link<-
    
    co do perspektywy - jest taka bo tak jak wspominałem wykorzystałem grafikę z poprzedniej gry, może pomyślę by zmienić perspektywę smoka, choć podoba mi się teraz jego animacja.
    
    Co do "grace period" - starałem się by początek poziomu był w miarę wybaczający (by nie dało się od razu wbić w drzewo), pewnie będę to jeszcze poprawiał, pomysł z migotaniem - niezły :)
    
    Przedmioty do zbierania - jest ich dosłownie kilka (beczki/diamenciki/ludziki) - mogą być w różnych kolorach, ale nie ma to w tej chwili znaczenia pod kątem rozgrywki.
    
    Dziękuję za uwagi, motywują mnie do pracy :)
15. • 15: CommentAuthorilmenit
    • CommentTime20 Sep 2026 10:48

     
    Czy ma znaczenie pod kątem rozgrywki jak wyglądają elementy? Ma duże, szczególnie, gdy nie różnią się wyglądem te, które powodują kolizję, te nad którymi można przelecieć, oraz te które można zbierać. Jako autor masz w głowie model tego co jest bezpieczne a co nie, ale gracze tego nie wiedzą, a mało kto będzie miał cierpliwość metodą prób i błędów to odkrywać, szczególnie jak planujesz zmieniać z czasem scenerię aby zredukować monotonię.
    Przykładowo - jest teraz "mały krzak" raz mogę przez taki przelecieć, innym razem powoduje kolizję i nie rozumiem dlaczego.
    Nie uważam, że jest za prosto. To kolejny problem z większością gier - autor zagrał w grę setki razy testując ją, ale gracze grający po raz pierwszy powinni mieć "luz" aby nauczyć się gry. Jeżeli będą od razu karani za popełniane błędy, do gry nie wrócą. Przykład świetnego designu to River Raid, gdzie z biegiem czasu rozgrywka jest coraz trudniejsza. Bardzo trudno ocenić trudność będą twórcą gry bez obserwowania niezależnych testerów. Chyba, że chcesz aby ta gra była w stylu "Flappy Bird" gdzie extremalna trudność jest tym, co ma czynić grę przyciągającą, a sesja gry ma trwać średnio kilka(naście) sekund.
16. • 16: CommentAuthorgrafi71
    • CommentTime20 Sep 2026 11:08

     
    Powiem szczerze - początkowo zastanawiaem się czy nie zrobić pewnego rodzaju "instrukcji" gdzie było by jasno pokazane jakie są przeszkody/jakie są secret'y, ale chciałem by gra miała swego rodzaju "look-and-feel" produkcji z lat 80-tych, którą kupowało się na giełdzie bez żadnego opisu i samemu było trzeba wszystko "rozkminiać" ;)
    
    Spróbuj ostatniego release'u - naprawdę gra już sporo wybacza (ale bez przesady...)
17. • 17: CommentAuthorilmenit
    • CommentTime20 Sep 2026 11:26 zmieniony

     
    Może wybacza, mnie się nie udaje przejść 1 poziomu :-)
    Odnośnie designu gry i czy powinna być jak w latach 80-tych? To już zależy od autora, ale można też wziąć pod uwagę najlepsze praktyki z gamedevu wytworzone w ciągu ostatnich 40 lat testowania co działa, co nie (świetne widea na ten temat ma ->link<- )
18. • 18: CommentAuthorgrafi71
    • CommentTime20 Sep 2026 11:29

     
    Pro-tip: gdy musisz przelecieć przez wąską szczelinę to zwalniaj :)
19. • 19: CommentAuthorilmenit
    • CommentTime20 Sep 2026 12:18

     
    pro-tip, pro tipem, ale ja wciąż nie rozumiem dlaczego czasem ginę.

    • game.mp4
20. • 20: CommentAuthorilmenit
    • CommentTime20 Sep 2026 12:45 zmieniony

     
    albo tutaj:

    • game-2.mp4
21. • 21: CommentAuthorgrafi71
    • CommentTime20 Sep 2026 13:10 zmieniony

     
    Spróbuj z najnowszą wersją.
    
    
    ->link<-
22. • 22: CommentAuthorilmenit
    • CommentTime20 Sep 2026 13:18 zmieniony

     
    bez zmian w v0.5.0, wciąż ginę w tych samych miejscach jak na załączonych nagraniach. Coś jest nie tak z kolizjami.
23. • 23:
       
      CommentAuthorKaz
    • CommentTime20 Sep 2026 16:08

     
    Gra się już trochę łatwiej, ale może to dlatego, że nabrałem wprawy. Jednak problem z kolizjami pozostał, jak zauważył też Ilmenit. Raz dane drzewo można przelecieć bez problemu, a raz zabija. I nie tylko chodzi o drzewa, bo zabiły mnie raz trawy (te z pojawiającą się wodą).
    
    A w ogóle skąd pomysł, żeby nawiązać do wiersza Lewisa Carrolla? Bo to fajny pomysł, ale dlaczego akurat taki?
24. • 24: CommentAuthorgrafi71
    • CommentTime20 Sep 2026 17:19

     
    @Kaz
    
    Tak naprawdę to początkowo inspiracją był film Jabberwocky
    

    
    stworzony przez grupę Monty Python'a.
    Miało się latać smokiem i zjadać uciekających wieśniaków.
    No i nic z tego pożerania nie wyszło, ale tytuł został (zresztą tytuł filmu był inspirowany wierszem).
    
    @ilmenit
    Wiem gdzie jest problem - sprzętowe wykrywanie kolizji zgłasza kolizję (z krzakiem który nie jest przeszkodą), ale faktycznie test obiektu "pod spodem" odbywa się trochę później przez co drzewo jest wykrywane jako obiekt z którym zachodzi zderzenie. Na razie nie widzę innego pomysłu niż lekkie przeprojektowanie poziomów by obiekty "non-blockable" nie występowały zaraz przed tymi "blockable".
25. • 25: CommentAuthorilmenit
    • CommentTime20 Sep 2026 17:50

     
    Hm... Dlaczego wykrywanie kolizji miałoby być problemem, nawet jak jest sprzętowe?
26. • 26: CommentAuthorgrafi71
    • CommentTime20 Sep 2026 17:58

     
    @ilmenit
    
    Algorytm wykrywa zderzenie (jesteś nad krzakiem), ale algorytm który sprawdza z jakim obiektem zaszło zderzenie zgłasza drzewo - bo obszar smoka się z nim częściowo pokrywa (mimo że fizycznie jeszcze go nie dotyka).
27. • 27: CommentAuthorilmenit
    • CommentTime20 Sep 2026 19:08

     
    Dlatego hit-boxy negatywne w grach zwykle są mniejsze, czasami dla gracza wielkości 1 piksela w środku.
28. • 28:
       
      CommentAuthorKaz
    • CommentTime20 Sep 2026 20:58 zmieniony

     

    grafi71:

    No i nic z tego pożerania nie wyszło, ale tytuł został (zresztą tytuł filmu był inspirowany wierszem).

    
    
    Tytuł filmu Monty Pajtonów nie tylko był inspirowany tytułem wiersza, ale po prostu był jego kopią :) To bardzo znany wiersz absurdalny, bo zabawiający się konwencją i przy okazji wprowadzający masę neologizmów trudnych do tłumaczenia:
    ->link<-
    
    Tłumaczeń tego wiersza na polski też było wiele i są fascynujące, nawet Janusz Korwin-Mikke wykonał własne:
    ->link<-
    
    Dodam, że Jabberwocky to nie jest imię/nazwa smoka/potwora, tylko tytuł wiersza. Smok/potwór ma na imię/nazwę Jabberwock. W polskich tłumaczeniach są piękne propozycje. Komputerowe głowy pewnie eksplodują, że nie ma "jednego jedynie słusznego tłumaczenia". No nie ma:
    
    Dziaberłak
    Dżabrokłap
    Żabrołak
    Dziaberlak
    Dżabbersmok
    Żabrołak
    Żubrowołk
    Paplołak
    Dżabrojad
    Paplostwór
    Trajkotun
    Dżabedżok
    Dżaberłok
    Dziwolęk
    Ostrogarp
    Dziabeniec
29. • 29: CommentAuthorbartgo
    • CommentTime21 Sep 2026 09:25

     
    Wiele lat temu też zrobiłem dość luźne tłumaczenie fragmentu, świetna zabawa, o:
    
    Blaskogrzało, kiedy brzętwy garmącone
    Małośmichnie na trąwie piękwiały
    Prostoszczoły rękły się w zegwale
    A chrumwoły w kwiczu oprąciały
    
    Lo! Ostrogarpa lękaj się!
    Brzdonów jak gryn i egzopręg!
    Zmykłaj, wierzguje złogas ten,
    Co śmiercią wygnak - bezmu, hen!
    
    Szlachnie wnet scymir krwiożłopy
    I łeb ostrogarpa - odmórg!
    Ganu, tonop! Garrop! Garrop!
    W chwale pattu na wzgórg!
    
    (wszelkie prawa zastrzeżone itp)
30. • 30:
       
      CommentAuthorKaz
    • CommentTime21 Sep 2026 14:51 zmieniony

     
    Piękne. Dokończ i wyślij do tej strony gościa z AGH z różnymi wersjami: ->link<- Dopisuję "Ostrogarpa" :)
    Mi się podobają wszystkie wersje odchodzące od "Dż". Ostrogarp - bardzo ładne. Tak samo Trajkotun czy Żubrowołk.
31. • 31: CommentAuthorbaskak
    • CommentTime21 Sep 2026 21:29

     
    Dzieńdoberek,
    
    To ja się też dołączę z tłumaczeniem. Gość z AGH już nie dodaje przekładów ze względu na wątpliwości co do praw autorskich.
    
    Noszę się też z zamiarem napisania eksplikacji tłumaczenia, bo jest dość pedantycznie wierne.
    
    Dziabeniec
    
    O piekłej ożywłe kropuchy
    Wiroryjodrężały na zmoczu,
    Omogłe snały czaplowiki
    I żanośnie wyprychnął szczurotur.
    
    „Dziabeńca się, mój synu, strzeż!
    Kąśliwych szczęk, łapczywych szpon!
    Unikajżeż Gulgula też,
    Od Wyrwidziora stroń!”
    
    Jął brzeszczot świdry, błysnął niem,
    Za górdnym wrogiem dążył wciąż,
    Aż spoczął pod skrytoni pniem,
    Myślami spowił skroń.
    
    I gdy w sękatej smucie tkwił,
    Dziabeniec, prażąc ogniem z ócz,
    Wyprysnął z boru ile sił,
    Gwargocząc rwał na wprzód!
    
    Sztorc kosą koś! Na wskroś, na wskroś!
    Szwargolił świdry miecz,
    Trzasnęło: jeb! Trzymając łeb
    Podumniepędził wstecz.
    
    „Ty żeś Dziabeńca dźgnął, łeb zżął?
    W ramiona pódź na skos!
    O radosławny dzień, he-heń!”
    Mlaskając chrumśmiał w głos.
    
    O piekłej ożywłe kropuchy
    Wiroryjodrężały na zmoczu,
    Omogłe snały czaplowiki
    I żanośnie wyprychnął szczurotur.
    
    Prawa itp. jak wyżej ;)
    
    Powodzenia z grą! Odpaliłem na emulatorze, ale póki co śmierć się ściele gęsto.
32. • 32:
       
      CommentAuthorKaz
    • CommentTime21 Sep 2026 21:53

     
    Rewelacja! Wielkie dzięki za podzielenie się wierszem, Antoni! Dziabeniec brzmi ładnie, taki dziabiący kaczeniec :).
    
    

    baskak:

    Gość z AGH już nie dodaje przekładów ze względu na wątpliwości co do praw autorskich.

    
    
    Hmmm... Ale jak autor chce dodać to chyba nie powinien mieć wątpliwości? Oświadczenie dołączyć i tyle. Zresztą napisał, że autorzy pozwolili...
33. • 33: CommentAuthorbaskak
    • CommentTime21 Sep 2026 22:13

     
    Bardzo mi miło. Kaczeniec to może zbyt "miękkie" skojarzenie, zastanawiałem się nad tym, więc: szaleniec.
    
    P. Szymon Sokół (z AGH) napisał do mnie: "Bardzo mi przykro, ale podjąłem decyzję, że nie będę już zamieszczał przekładów, które nie były nigdzie dotąd publikowane - chodzi m. in. o kwestie atrybucji i praw autorskich." Chyba mogę upublicznić.
    
    Szkoda.
34. • 34: CommentAuthorgrafi71
    • CommentTime29 Sep 2026 21:39

     
    Miło mi napisać że jest nowe wydanie Jabberwocky, gra posiada już muzykę (całe 3 utwory).
    Jej autorem jest Andrzej "Andy" Kidaj.
    
    ->link<-
    
    @Kaz
    Wielkie dzięki za udostępnienie muzyki!
35. • 35: CommentAuthorilmenit
    • CommentTime29 Sep 2026 22:15

     
    ale system kolizji wciąż nie poprawiony? Przykładowo, umiera się już na samym początku przy wleceniu w ten krzak na prawo od smoka.

    • kolizje.png
      
      
      
      
36. • 36: CommentAuthorgrafi71
    • CommentTime30 Sep 2026 06:28

     
    @ilmenit
    
    Nie, zdecydowałem że nie będę tego poprawiał - tym bardziej że daje ciekawą możliwość cheat'owania (działa w pewnych okolicznościach na korzyść gracza, ale kiedy - nie będę zdradzał ;))
    
    Na razie postaram się tak przeprojektować poziomy by obiekty nie-blokujące nie były w bezpośrednim sąsiedztwie obiektów blokujących, a w ostateczności po prostu te nie-blokujące usunę.
37. • 37: CommentAuthorilmenit
    • CommentTime30 Sep 2026 06:41 zmieniony

     
    Czemu tak? Nie lepiej poprawić algorytm i obszary kolizji? Teraz jest wrażenie, że gra ma bugi uniemożliwiające sensowne granie. To jakby w River Raid czasem przelecenie obok wrogiego statku powodowało śmierć a czasem nie.
38. • 38: CommentAuthorgrafi71
    • CommentTime30 Sep 2026 07:12

     
    @ilmenit
    
    Ponieważ uważam że rozwiązanie może przynieść negatywne skutki jeśli chodzi o wydajność (z tym naprawdę dość mocno walczyłem).
    
    Lepiej będzie albo przeprojektować poziomy albo usunąć obiekty "non-blocking".
39. • 39: CommentAuthorilmenit
    • CommentTime30 Sep 2026 09:23 zmieniony

     
    Z ciekawości - czemu wydajność jest problemem? Nie ma tu ruchomych obiektów, grafika w w trybie 5 ANTICa, scroll w jedną stronę, smok jest zawsze w tym samym miejscu poziomo więc mapa kolicji by mogła być na poziomie znaków.
40. • 40: CommentAuthorgrafi71
    • CommentTime30 Sep 2026 09:35 zmieniony

     
    @ilmenit
    
    Poniżej wklejam raport z optymalizacji/usuwania wąskich gardeł.
    
    Raport optymalizacji wydajnościowych silnika gry Jabberwocky / Atari 8-bit
    
    Podczas prac nad silnikiem rozwiązano szereg krytycznych wąskich gardeł wydajnościowych wynikających z ograniczeń procesora MOS 6502 (1.77 MHz) oraz układów ANTIC i GTIA. Poniżej znajduje się zestawienie kluczowych problemów oraz zastosowanych rozwiązań.
    
    1. Eliminacja zacięcia animacji przy zmianie ekranów (Screen Transition Stutter)
    
    - Problem: Co 40 kroków przewijania (pełna szerokość ekranu) pojawiało się wyraźne szarpnięcie i opóźnienie klatki (stutter).
    
    - Przyczyna: W pojedynczej klatce CPU wykonywało jednocześnie przesunięcie pamięci VRAM (shift_vram_left, jabberwocky/scenes/game.asm#L2588, ~4 900 cykli) oraz synchroniczne wypiekanie kafelków i masek kolizji kolejnego ekranu (bake_screen, jabberwocky/scenes/game.asm#L2026, ~3 000–6 000 cykli). Łączny koszt 9 000–12 000 cykli drastycznie przekraczał budżet klatki PAL (zmniejszony dodatkowo przez DMA ANTIC), opóźniając obsługę VBLANK.
    
    - Rozwiązanie: Wprowadzono odroczone wypiekanie bufora (Deferred Screen Bake). Po dojechaniu do krawędzi ustawiana jest flaga bake_pending (jabberwocky/scenes/game.asm#L2512), a faktyczny wypiek (execute_pending_bake, jabberwocky/scenes/game.asm#L2516) realizowany jest w następnej klatce, w której akumulator przewijania nie wykonuje przesunięcia koarsowego.
    
    
    2. Likwidacja rwania obrazu (Screen Tearing)
    
    - Problem: Poziome rozrywanie obrazu (tearing) pojawiające się co ~5 klatek przy przesuwaniu kolumn playfieldu.
    
    - Przyczyna: Kopiowanie 528 bajtów pola akcji następowało wprost w aktywnym buforze VRAM w trakcie rysowania linii przez wiązkę elektronów ANTIC.
    
    - Rozwiązanie: Wdrożono sprzętowe podwójne buforowanie VRAM (Double Buffering):
    
    - Zaalokowano dwa symetryczne bufory: Buffer A ($6000) i Buffer B ($6400).
    
    - Przebudowano procedurę na dwa zoptymalizowane warianty: shift_vram_a_to_b (jabberwocky/scenes/game.asm#L2592) oraz shift_vram_b_to_a (jabberwocky/scenes/game.asm#L2621) (z unrollowanymi odczytami i odliczaniem DEX/BPL), zapisujące wynik wyłącznie do bufora tylnego.
    
    - Przełączenie aktywnego adresu VRAM następuje atomowo w Display List (dlist_game_action_lms, jabberwocky/scenes/game.asm#L1303) w przerwaniu VBLANK.
    
    
    3. Usunięcie drgań i mikroskoków przewijania (Scrolling Jitter)
    
    - Problem: Skoki obrazu o 3–4 zegary koloru w przód/tył oraz mikrodrgania rastra.
    
    - Przyczyny:
    
    1. Asynchronia fazowa – rejestr HSCROL był aktualizowany od razu w pętli głównej, podczas gdy wskaźnik LMS Display List zmieniał się dopiero w kolejnym przerwaniu VBLANK (1-klatkowa rozbieżność).
    
    2. Wielokrotne, zbędne modyfikacje rejestru sprzętowego HSCROL w przerwaniach linii DLI w trakcie aktywnego rastra.
    
    - Rozwiązanie: Wprowadzono zmienną pośrednią hscrol_next (jabberwocky/scenes/game.asm#L2585). Rejestr sprzętowy HSCROL ($D404) oraz adres LMS są przepisywane ściśle atomowo w przerwaniu VBLANK (vblank_game, jabberwocky/scenes/game.asm#L1290), gdy wiązka znajduje się poza widocznym obrazem, a zapisy HSCROL z procedur DLI całkowicie usunięto.
    
    
    4. Wielopoziomowy silnik detekcji kolizji (Hierarchical $O(1) Gatekeeper)
    
    - Problem: Ciągłe testowanie geometrii obiektów planszy, płomienia i smoka w 50 Hz doprowadziłoby do natychmiastowego zdławienia procesora 6502.
    
    - Rozwiązanie (engine/flame_collision.asm):
    
    - Tier 1 (Bramkarz sprzętowy GTIA): Zamiast testować geometrię co klatkę, odczytywane są sprzętowe rejestry kolizji GTIA (dragon_p0pf, jabberwocky/scenes/game.asm#L1208 oraz flame_m_pf, jabberwocky/scenes/game.asm#L1213). Jeśli sprzęt nie wykrył przecięcia barw, procedura kończy pracę w czasie O(1) (< 10 cykli).
    
    - Tier 2 (Siatka przestrzenna kolumny): Smok porusza się w stałych kolumnach ekranu (kolumny 8 i 9). Zamiast przeszukiwać obiekty, w locie strumieniowane są 11-bajtowe bufory kolumn blocking_col8 (jabberwocky/engine/flame_collision.asm#L73) i blocking_col9.
    
    - Tier 3 (Bitmaska zniszczonych obiektów): 256-bajtowa tablica bitmasek screen_obj_destroyed (jabberwocky/engine/flame_collision.asm#L70) pozwala w pojedynczym teście bitowym pominąć obiekty zniszczone bądź zebrane.
    
    - Tier 4 (Early-out dla obiektów litych): Wprowadzono flagę bitu 7 (has_empty_tiles). Dla obiektów litych kolizja prostokątna jest akceptowana od razu (bpl, 2 cykle); kosztowna weryfikacja pojedynczych kafli (fc_calc_tile_offset) odbywa się wyłącznie dla obiektów o nieregularnych kształtach.
    
    
    5. Architektura Ping-Pong Staging Buffers i kompresja świata (>20 KB RAM)
    
    - Problem: Przechowywanie statycznych matryc VRAM oraz masek kolizji dla 20+ ekranów pochłaniało ~18 KB RAM, uniemożliwiając rozbudowę etapów poniżej granicy OS ROM ($C000).
    
    - Rozwiązanie (scripts/labirynt_builder.py, main.asm):
    
    - Zastąpiono surowe matryce zwięzłymi listami instancji w formacie Structure-of-Arrays (codes, coords, obj_count). Rozmiar 20 ekranów spadł z 31,5 KB do zaledwie ~1,5 KB kodu maszynowego.
    
    - Zaalokowano podwójny bufor roboczy ping-pong (2 × 440 B) generowany w czasie rzeczywistym.
    
    - Uwolniono ponad 20 KB pamięci RAM, a moduły pomocnicze przeniesiono do segmentu Low RAM (LOW_CODE_ADDR = $0800), stabilizując margines pamięci do ROM.
    
    
    6. Rygorystyczny podział budżetu przerwań (VBLANK vs DLI vs Main Loop)
    
    - Problem: Ryzyko nakładania się przerwań i gubienia cykli audio/wideo.
    
    - Rozwiązanie:
    
    - DLI: Ograniczone wyłącznie do krytycznych czasowo zmian palety barw, synchronizacji linii za pomocą WSYNC oraz zmiany rejestru czcionki CHBASE (minimalna liczba cykli, brak logiki gry).
    
    - VBLANK: Obsługuje wyłącznie atomowe przełączenie wskaźników LMS/HSCROL, rejestrów pozycji PMG oraz lekki tick sterownika muzyki CMC (50 Hz).
    
    - Pętla główna (game_run): Przejęła całą logikę wejścia, fizykę lotu smoka, kalkulację prędkości przewijania oraz odroczone renderowanie buforów.
41. • 41: CommentAuthorilmenit
    • CommentTime30 Sep 2026 10:09 zmieniony

     
    Nie wydaje Ci się to mocno przekombinowane?
    Jak widzę największy bottleneck jest w tym, że kopiujesz całą pamięć ekranu przy każdym przesunięciu o znak. To nie C64, my mamy ANTICa ;-)
    
    Przy scrollu w jedną stronę można zrobić osobny LMS dla każdego wiersza i przesuwać adres odczytu o jeden bajt, a ruch pomiędzy znakami nadal robić przez HSCROL. Do tego bufor kołowy z powielonym fragmentem na końcu, żeby ANTIC mógł czytać przez miejsce zawinięcia. Wtedy wystarczy dopisywać nową kolumnę poza ekranem. Po dojściu do końca bufora zawijają się adresy LMS, bez kopiowania całego ekranu. To mogłoby zastąpić obecne przesuwanie VRAM i może nawet podwójne buforowanie.
    
    Podobnie z kolizjami: skoro smok ma stałą pozycję poziomą, mapa flag lub raczej indeksów obiektów na poziomie znaków wydaje się wystarczająca. Dwie buforowane kolumny już idą w tym kierunku. Dla płomienia można by trzymać przy komórkach identyfikator obiektu, żeby od razu wiedzieć, co zostało trafione i co trzeba usunąć, bez przeglądania listy obiektów.
    
    Najpierw zrobiłbym test samego scrolla z LMS-ami - jeśli zniknie koszt kopiowania, może się okazać, że kilka pozostałych optymalizacji nie będzie już potrzebnych, przez co zwolni się jeszcze sporo miejsca na inny kod/grafikę/dźwięki/mechanikę.
    
    W skrócie:
    
    Masz 11 wierszy planszy i bufor ekranu x2 w poziomie. Każdy wiersz zapisujemy w pamięci dwukrotnie po sobie:
    
    ABCDEFGHABCDEFGH
    ^-OKNO-^
    
    Każdy wiersz DLISTy ma w tym przupadku własny LMS. Wszystkie wskazują na początek swojego wiersza plus wspólne przesunięcie. Więc przy scrollowaniu LMS nie musimy nigdy kopiować pamięci. Jedynie co musimy zrobić to to, że przy zapisie do takiej pamięci ekranu musimy zrobić zapis w 2 miejsca. Dla 11 wierszy ekranu to 11 x2 zapisy tego samego znaku.
42. • 42: CommentAuthorgrafi71
    • CommentTime30 Sep 2026 10:21 zmieniony

     
    @ilmenit
    
    Dlaczego obecna architektura wygląda tak, a nie inaczej? Wynika to z ewolucji projektu i innych ograniczeń sprzętowych, z którymi się mierzyłem (a raczej agent mierzył ;))
    Tu problem jest też taki że w grze poziomy mają po 8–10 ekranów (łącznie 20–30 ekranów w grze). Przechowywanie ich w pamięci RAM w postaci gotowych kafelków wymagałoby ponad 18–25 KB RAM (nie ma fizycznej możliwości trzymania rozpakowanych ekranów w RAM).
    Na ten moment silnik działa (w miarę) płynnie, i nie chcę destabilizować przetestowanej bazy kodu.
43. • 43: CommentAuthorilmenit
    • CommentTime30 Sep 2026 10:37

     
    W tym co zaproponowałem nie trzeba trzymać całości rozpakowanej - jedynie co trzeba, to robić dwa zapisy do 2x szerszej pamięci ekranu.
44. • 44: CommentAuthorgrafi71
    • CommentTime30 Sep 2026 10:53

     
    @ilmenit
    
    OK, już rozumiem - proponujesz bufor lustrzany/podwojony o szerokości 2 ekranów RAM.
    Tak jak napisałem - obecny silnik ma po prostu historyczny dług technologiczny – zaczynał od prostego bufora liniowego i był rozwijany stopniowo.
    Kiedy pojawił się problem z wydajnością najszybszą łatką było dodanie drugiego bufora i rozbicie "wypieku" na osobną klatkę co pozwoliło utrzymać stałe FPS bez przepisywania reszty podsystemów. Jest sporo zależności (np testów) które by trzeba przerobić, ale nie wykluczam tego jak będę miał trochę czasu to spróbuję to zrobić - wpisuję pomysł na moją listę "rzeczy do zrobienia w wolnym czasie" ;)
    Dzięki.
45. • 45: CommentAuthorgrafi71
    • CommentTime30 Sep 2026 12:47

     
    @ilmenit
    
    A co mi tam, to tylko dwa prompty dla agenta ;)
    Zrobione.

    • jabberwocky.xex
46. • 46: CommentAuthorilmenit
    • CommentTime30 Sep 2026 15:13

     
    to teraz jeszcze poprawić tego buga w kolizjach i gitara :-P