Tony na C64

[thevoid]

Zaczynam osobny wątek. Powoli widać światełko w tunelu. Mam nadzieję, że w przyszłym tygodniu dojdą sprajty, bo na razie to, poza głównym bohaterem, wszystko inne leci na softwarze

https://drive.google.com/file/d/19qvFeU ... drive_link
https://drive.google.com/file/d/1d8OCqR ... drive_link

Muzyka do gry wciąż się komponuje, to co jest podpięte, to placeholder, abym się nie rozpędził z konsumpcją pamięci

[Gordian]

Dobra robota.

Czy wszystkie animowane elementy/przeszkody będziesz zmieniał na sprajty? Według mnie te, których każda klatka animacji mieści się mniej więcej w stałym i maksymalnym obszarze znaków, mogłaby zostać na znakach.

Ile sprajtów zużyłeś na postać?

[thevoid]

Czy wszystkie animowane elementy/przeszkody będziesz zmieniał na sprajty? Według mnie te, których każda klatka animacji mieści się mniej więcej w stałym i maksymalnym obszarze znaków, mogłaby zostać na znakach.

Hej nie, nie. To co jest, zostaje na znakach. Tam dochodzą jeszcze trzy rodzaje obiektów, które poruszają się po ekranie i do których użyję sprajtów. Póki co obiektów na raz jest tak mało, że nie muszę nawet multipleksera robić.

Ile sprajtów zużyłeś na postać?

Tam są trzy sprajty: góra i dół plus jeden na tło (rozciągnięty w pionie). Jak widać na filmie, brakuje kilku pixeli po prawej stronie postaci, gdyż grafika powstała głównie z myślą o Atari i Amidze, i nie wszystkie klatki mieściły się w 24 pixelach na szerokość. Temat ten planuję zaadresować softwareowo rysując te piksele na specjalnie zostawionych dwóch znakach z charsetu. Mam sporo czasu CPU wolnego, więc myślę że dam radę. Nie chciałem do tego wykorzystywać dodatkowego sprajta, gdyż jeden i tak by nie wystarczył a do tego nie mam już pamięci w banku VIC (wszystkie klatki animacji zajmują obecnie 120 slotów). Dlatego mam wciąż 5 sprajtów wolnych, które na pewno wykorzystam na "nietoperze" itp.

Podsumowując, mimo bogatej animacji, gra ta nie jest problemem jeśli chodzi o czas CPU. Natomiast problemem poważnym jest brak pamięci. Już teraz stosuję kompresję map. Dodatkowo przechodząc między planszami przebudowuję dynamicznie generator znaków, gdyż za każdym razem muszę wygospodarować przestrzeń na "software'owe" sprajty. Np głazów nie jestem w stanie użyć w każdej komnacie, gdyż w niektórych komnatach zróżnicowanie grafiki jest tak duże, że po prostu brakuje mi miejsca na charsecie.

[Gordian]

A czy "lewa" i "prawa" strona animacji postaci to odrębne klatki w pamięci?

[carrion]

Wygląda fajnie i działa chyba też dobrze. W jaki sposób robisz kolizje z podłogą i ścianami?
Czy hipek przy spadaniu przyspiesza czy ma stałą prędkość? pytam bo nie umiem powiedzieć na podstawie filmiku.

Dobra robota tak czy tak

[thevoid]

Wygląda fajnie i działa chyba też dobrze. W jaki sposób robisz kolizje z podłogą i ścianami?
Czy hipek przy spadaniu przyspiesza czy ma stałą prędkość? pytam bo nie umiem powiedzieć na podstawie filmiku.

Hej,

Po pierwsze dzięki za namówienie do powrotu na Hires Text, to był strzał w dziesiątkę.

Kolizja jest robiona software'owo przy pomocy dość skomplikowanego kodu (z którego do końca nie jestem dumny). Mechanika jest a'la Montezuma, czyli de facto jest trudniej niż byłoby normalnie (skoki głową przez sufit, brak wskakiwania / zeskakiwania z drabin). Stosuję materiały z Charpada, gdzie każdy ze znaków ma przypisaną wartość (powietrze, ściana/podłoga, drabina, zabijanie) i skanuję raz na ramkę co jest pod hipkiem (właściwie to dwa razy, trochę mnie czas goni i jeden problem tak zafiksowałem). Dodatkowo skanuję wiersz poniżej, kolumnę po lewej, po prawej - generalnie masakra.

Zaimplementowałem też maszynę stanów z dozwolonymi przejściami między stanami, przez co uprościłem sobie mocno ifologię w kodzie. Stany potem skojarzyłem sobie z jednej strony z sterowaniem, z drugiej z animacją i jakoś to działa. Są jeszcze drobne błędy w fizyce, będę to korygował na końcu.

Diagram stanów poniżej (średnio aktualny, doszedł stan deathLeft|Right):

physics.excalidraw.png (345.48 KiB) Przejrzano 13017 razy

Fizyka skoku jest uproszczona - standardowa parabola, a gdy w miejscu lądowania nie ma gruntu, leci ruchem jednostajnym. Podobnie rozwiązane jest spadanie z drabiny.

[Gordian]

Ponawiam moje pytanie:)

[thevoid]

A czy "lewa" i "prawa" strona animacji postaci to odrębne klatki w pamięci?

Tak, to osobne klatki w pamięci. Generuję je (odbicie lustrzane) w trakcie budowania softu. Wielka szkoda, że VIC-II nie umie sobie zrobić mirrora sprzętowo.

[Gordian]

A czy nie mógłbyś ich budować w locie? Do "przeflipowania" byłoby 189 bajtów w jednej ramce. Skoro masz dużo wolnego czasu CPU, to może udałoby się, zyskując na wolnej pamięci.

[carrion]

Dodatkowo skanuję wiersz poniżej, kolumnę po lewej, po prawej - generalnie masakra.

hehe masakra ale ja też tak robię i nie wymyśliłem nic lepszego na razie. jak ktoś zna inny spoób niech się podzieli. z drugiej strony to nie jest jakoś bardzo rasterożerne, a że działa to czemu nie ...
aha w nowyej mojej procedurce zrobiłem jeszcze tak że sprawdzam inne kolumny znaków w zależności czy idę w lewo czy prawo góra/dół, ale to chyba oczywiste.

Fizyka skoku jest uproszczona - standardowa parabola, a gdy w miejscu lądowania nie ma gruntu, leci ruchem jednostajnym. Podobnie rozwiązane jest spadanie z drabiny.

ciekawe.... u mnie przyspieszał (do pewnej wartości prędkości) i to powodowało masę problemów z kolizjami z podłągą przy spadaniu. następnym razem przetestuję Twoje podejście.

[thevoid]

hehe masakra ale ja też tak robię i nie wymyśliłem nic lepszego na razie. jak ktoś zna inny spoób niech się podzieli. z drugiej strony to nie jest jakoś bardzo rasterożerne, a że działa to czemu nie ...

No właśnie ja coś spieprzyłem i u mnie to ciągnie dużo rastra, szczególnie że odpalam to dwa razy. Jak będę miał trochę czasu to siądę do tego. Na szczęscie w demo levelu nie muszę sprajtów multiplexować I działa w NTSC!

Wstydliwy screen poniżej

tony-raster-time.png (57.7 KiB) Przejrzano 13000 razy

ciekawe.... u mnie przyspieszał (do pewnej wartości prędkości) i to powodowało masę problemów z kolizjami z podłągą przy spadaniu.

Dokładnie z tego powodu nie zrobiłem tam Newtona - żeby nie komplikować jeszcze bardziej kodu fizyki a w szczególności precyzyjnego osadzania hipka na podłodze.

[Gordian]

To ja znów ponawiam moją propozycję z postu #9:)

[thevoid]

A czy nie mógłbyś ich budować w locie? Do "przeflipowania" byłoby 189 bajtów w jednej ramce. Skoro masz dużo wolnego czasu CPU, to może udałoby się, zyskując na wolnej pamięci.

Zapamiętam ten pomysł, teoretycznie do zrobienia, nawet jakbym miał napisać speed code z tablicą 256 bajtów z odwróconymi wartościami, to wciąż odzyskam ponad 3kB. Czas oceniam na 40-50 linii rastra, gdzieś może to wcisnę na overscanie (ale NTSC!). Generalnie wolę to, niż robić multiload w wersji demo.

[carrion]

ta fizyka i kolizje faktycznie dużo zajmuje.
w jaki sposób odczytujesz bloczek do kolizji z ekranu? może to da się jakoś przyspieszyć? np ja miałem tablicę wszystkich początków lini znakowych czyli 0400 0428 0450 0478... itd więc Y to było odczytanie pozycji z tej tablicy. i to mi najbardziej oszczędziło czas na wskazanie który znaczek na ekranie mam brać do kolizji.

[thevoid]

W tej grze wszystko co się da jest stablicowane, nie uznaję innego podejścia do mnożenia na 6502

Nie, to nie to. Ten kod kosztował mnie sporo nerwów, więc jak zaczęło działać to już to zostawiłem I zająłem się innymi rzeczami. Zapewne coś co mogłem robić w jednym przebiegu pętli robię w kilku. Podczas detekcji wykrywam także drabinę i automatycznie do niej centruję przy próbie wejścia.

Plus detekcja odpalana jest dwa razy, bo czegoś tam nie przemyślałem do końca i bez tego nie działało w 100% dobrze. Jak będzie czas, naprawię to.

Dodatkowo, ten szeroki pas rastra odpowiada za całą fizykę ruchu począwszy od obsługi joya, poprzez detekcję kolizji, wyliczanie nowej pozycji postaci (w tym za fizykę skoku), przejścia między stanami, przestawianie animacji na inną (innymi słowy wszystko, co nie zmienia zawartości ekranu). Obecnie poza rastrem wykonywane są tylko dwie czynności: wykrywanie przejścia między komnatami (wraz z obsługą tegoż) oraz obracanie węży w zależności od pozycji bohatera.

[Gordian]

Zapamiętam ten pomysł, teoretycznie do zrobienia, nawet jakbym miał napisać speed code z tablicą 256 bajtów z odwróconymi wartościami, to wciąż odzyskam ponad 3kB. Czas oceniam na 40-50 linii rastra, gdzieś może to wcisnę na overscanie (ale NTSC!).

Można podejść do tego na dwa sposoby, albo trzymać tylko klatki animacji z jedną stroną i odwracać je w tym samym obszarze pamięci. Wtedy w banku zwalnia się połowa pamięci zajętej przez animację minus jedna klatka.
Można też trzymać klatki (jednej strony) w zupełnie innym obszarze pamięci i kopiować zawsze tylko jedną klatkę. Przy czym tu kopiować trzeba by było zawsze, niezależnie, którą stronę postaci potrzebujemy. Ale zysk pamięci w banku jest dużo większy. Być może mógłbyś tu zmieścić charsety, które generujesz poprzez CPU.

Sprawdziłem odwracanie jednego duszka w pętli (nie speedcode). W przypadku pierwszej metody to 21 linii rastra (pętla 39 bajtów), w przypadku drugiej 17 linii rastra (pętla 34 bajty).

[Hornet]

Wygląda WYBORNIE!

Bardzo mi się podoba grawitacja hipka, hiresik też pięknie się komponuje - kolory docelowe czy przewidujesz coś innego? I takie pytanko laika - te trzy kamienia opadające na łańcuchach - czemu to tak skokowo wędruje?

Powodzenia i wytrwałości!

[thevoid]

Można podejść do tego na dwa sposoby, albo trzymać tylko klatki animacji z jedną stroną i odwracać je w tym samym obszarze pamięci. Wtedy w banku zwalnia się połowa pamięci zajętej przez animację minus jedna klatka.
Można też trzymać klatki (jednej strony) w zupełnie innym obszarze pamięci i kopiować zawsze tylko jedną klatkę. Przy czym tu kopiować trzeba by było zawsze, niezależnie, którą stronę postaci potrzebujemy. Ale zysk pamięci w banku jest dużo większy. Być może mógłbyś tu zmieścić charsety, które generujesz poprzez CPU.

Sprawdziłem odwracanie jednego duszka w pętli (nie speedcode). W przypadku pierwszej metody to 21 linii rastra (pętla 39 bajtów), w przypadku drugiej 17 linii rastra (pętla 34 bajty).

Chyba zapomniałem dodać, że właściwie to brakuje mi pamięci wszędzie, nie tylko w banku VIC. Właściwie to w banku VIC jest ok, nawet planuję trzymać tam coś jeszcze. Wszystko trzyma się jeszcze jako tako kupy dlatego, że wszystkie sprajty wędrują do pamięci VIC.

[thevoid]

Wygląda WYBORNIE!

Bardzo mi się podoba grawitacja hipka, hiresik też pięknie się komponuje - kolory docelowe czy przewidujesz coś innego? I takie pytanko laika - te trzy kamienia opadające na łańcuchach - czemu to tak skokowo wędruje?

Powodzenia i wytrwałości!

Dzięki!

Jeśli chodzi o kamienie, to ich animacja będzie jeszcze dopracowana. Pamiętaj, że do tej animacji nie wykorzystuję sprajtów, animacja zrobiona jest na odpowiednio wygenerowanym charsecie. Skokowości w związku z tym nie uniknę (jestem w stanie przesuwać to co 4 pixele, tylko takim charsetem dysponuję). Pojedynczy kamień animowany jest z prędkością 50/8 = 6fps co wynika z tego, że w pojedynczej ramce ekranu animuję tylko część elementów, a jest ich sporo w grze: płomienie, węże, przedmioty, kolce i kamienie właśnie. Animacje mam pogrupowane na osiem slotów stąd 50/8. W tej chwili jeden slot mam wolny, więc mógłbym dodać 4-ty kamień. Mam wręcz wrażenie, że mógłbym robić po dwa kamienie na slot, czyli max 8 kamieni na ekran.

Pracuję nad ostatnimi 4-ma rodzajami animacji (te będą już opierać się na sprajtach), potem razem z autorem gry będziemy decydować, czy np animację przyspieszać, spowalniać itp.

Kolorystyka zapewne będzie utrzymywana w stylistyce mono, aczkolwiek planuję dodać więcej odcieni na dashboardzie. Gra powstaje także na Amigę, Atari i ZX Spectrum i te dwie ostatnie maszyny troszkę wyznaczają trend. Zdaję sobie sprawę, że wersja na C64 spokojnie mogłaby używać 16 kolorów i wyglądałoby to także dobrze, ale np tego już sie nie uzyska na Atari.

[Gordian]

Chyba zapomniałem dodać, że właściwie to brakuje mi pamięci wszędzie, nie tylko w banku VIC. Właściwie to w banku VIC jest ok, nawet planuję trzymać tam coś jeszcze. Wszystko trzyma się jeszcze jako tako kupy dlatego, że wszystkie sprajty wędrują do pamięci VIC.

Nie wiem czy to coś zmienia, ale jeśli używasz banku 0, to postać możesz trzymać na stronie zerowej, a zwolnioną przestrzeń wykorzystać na "coś jeszcze".