c64scene.pl

Gordian pisze: ↑

02 lip 2023, 08:41

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".

Do gier najchętniej wykorzystuję bank 3 I tak jest w tym wypadku. Ma to dla mnie dwie zalety:
1) bank 3 nie jest zaśmiecony character ROMem
2) bardzo ułatwia mi to zarządzanie pamięcią podczas kodowania gry, tj tworzę sobie segment na dane które będą relokowane i relokuję tam dane na starcie (z reguły są to sprajty i charsety, ew bitmapa, czasami też muzyka)

Niestety w tej grze muzyka musi być w innym miejscu (konkretnie w drugiej części banku 2). Bank 3 prawie w całości zajmują dane graficzne: dwa charsety, dwie strony ekranu (druga tylko po to, aby obciąć hipka przy przechodzeniu między komnatami góra dół, reszta to sprajty, często poupychane po screen ramie i charsetach) No I negocjacje z muzykiem w kwestii rozmiaru pamięci na dane muzyczne były bardzo trudne

Zgodnie z oczekiwaniami, ta część implementacji była już łatwa.
Poziom do wersji demo nie używa więcej niż 4 takich obiektów na raz, więc mam jednego sprajta w zapasie.

Dlaczego muzyka musi być w drugiej części banku 2?
Czy możesz wyjaśnić problem obcinania postaci i wykorzystania dwóch ekranów?

Gordian pisze: ↑

05 lip 2023, 12:13

Dlaczego muzyka musi być w drugiej części banku 2?
Czy możesz wyjaśnić problem obcinania postaci i wykorzystania dwóch ekranów?

Hej, musi być w drugim, bo się nie mieści w trzecim . Muzyka zajmie minimum 8kb, nawet jakbym zrobił ten myk z obracaniem duszków, to i tak nie pomieszczę.

A obcinanie postaci to coś, o czym kiedyś czytałem ale zapomniałem. Chodzi o to, że jak postać wychodzi poza ekran z lewej, prawej lub od góry to oczywiście Vic 2 sobie elegancko sprite's obcina, tak że jest efekt wychodzenia poza ekran. No ale ten efekt oczywiście trzeba zrobić ręcznie przy wyjściu na dół, bo po drodze jest jeszcze ten dashboard. Pierwotnie w tej pozycji rastra po prostu przełączałem charset na inny ale pamięć ekranu pozostawała bez zmian. Myślałem, że wystarczy wyłączyć sprajty wtedy i po krzyku. No i okazało się, że to tak nie działa. Jak vic-2 zacznie już Sprite wyświetlać to już wyświetla pełne 21 linii niezależnie od flagi w rejestrze SPRITE ENABLE. Wiec jedyna sensowna metoda, jaką znalazłem to przerzucenie całego dashboarda do drugiej strony ekranu i podmiana wszystkich wskaźników Sprite na tej drugiej stronie na duszka "przeźroczystego". I oczywiście rekonfiguracja rejestru memory Control.

thevoid pisze: ↑

05 lip 2023, 20:52

No ale ten efekt oczywiście trzeba zrobić ręcznie przy wyjściu na dół, bo po drodze jest jeszcze ten dashboard. Pierwotnie w tej pozycji rastra po prostu przełączałem charset na inny ale pamięć ekranu pozostawała bez zmian. Myślałem, że wystarczy wyłączyć sprajty wtedy i po krzyku. No i okazało się, że to tak nie działa. Jak vic-2 zacznie już Sprite wyświetlać to już wyświetla pełne 21 linii niezależnie od flagi w rejestrze SPRITE ENABLE. Wiec jedyna sensowna metoda, jaką znalazłem to przerzucenie całego dashboarda do drugiej strony ekranu i podmiana wszystkich wskaźników Sprite na tej drugiej stronie na duszka "przeźroczystego".

Możesz to zrealizować poprzez zmianę w danej linii rastra koloru postaci na czarny oraz zmianę priorytetu wyświetlania względem tła (czyli schować sprite pod znaki).

Gordian pisze: ↑

06 lip 2023, 08:26

Możesz to zrealizować poprzez zmianę w danej linii rastra koloru postaci na czarny oraz zmianę priorytetu wyświetlania względem tła (czyli schować sprite pod znaki).

Rzeczywiście to zadziała, bo muszę zrobić to maks dla dwóch sprajtów. Spróbuję

Gordian pisze: ↑

06 lip 2023, 08:26

Możesz to zrealizować poprzez zmianę w danej linii rastra koloru postaci na czarny oraz zmianę priorytetu wyświetlania względem tła (czyli schować sprite pod znaki).

Choć jednak moje rozwiązanie ma jedną wielką zaletę. Ukrycie sprajtów i zmiana charsetu robiona jest zapisem do tej samej komórki pamięci ($D018). Dodatkowo zmieniam tam kolor tła na czarny (bo dashboard jest na czarnym tle, a pole gry na odwrót) i wszystko ładnie mam wycyklowane (busy waiting na $D012). Zmiana kolorów wymagałaby pisania do trzech dodatkowych rejestrów, więc prawdopodobnie wyszłoby trochę mniej estetycznie.

thevoid pisze: ↑

06 lip 2023, 14:56

Choć jednak moje rozwiązanie ma jedną wielką zaletę. Ukrycie sprajtów i zmiana charsetu robiona jest zapisem do tej samej komórki pamięci ($D018). Dodatkowo zmieniam tam kolor tła na czarny (bo dashboard jest na czarnym tle, a pole gry na odwrót) i wszystko ładnie mam wycyklowane (busy waiting na $D012). Zmiana kolorów wymagałaby pisania do trzech dodatkowych rejestrów, więc prawdopodobnie wyszłoby trochę mniej estetycznie.

W danej linii rastra możesz zmienić kolor tylko sprajta, który się chowa (albo jakiś warunek, albo samodyfikujący się kod), linię dalej już obydwu.
Dzięki temu zwolniłby Ci się dzięki temu jeden screenram, bo niepotrzebne są już puste sprajty pod dashboardem.

Gordian pisze: ↑

06 lip 2023, 15:07

W danej linii rastra możesz zmienić kolor tylko sprajta, który się chowa (albo jakiś warunek, albo samodyfikujący się kod), linię dalej już obydwu.
Dzięki temu zwolniłby Ci się dzięki temu jeden screenram, bo niepotrzebne są już puste sprajty pod dashboardem.

Tam wciąż zmieści się 12,5 kształtu sprajta

Ale jak mówiłem, dzięki za sugestię, na pewno rozważę. W pełnej wersji będzie jeszcze gorzej z pamięcią

thevoid pisze: ↑

06 lip 2023, 19:40

Tam wciąż zmieści się 12,5 kształtu sprajta

Ach, rozumiem. Część pierwszego screenram gdzie byłby dashboard oraz część drugiego, gdzie byłaby plansza i tak wykorzystujesz:)

Można pomyśleć też o zupełnie innym rozwiązaniu, mianowicie cookie-cut. W pozycji Y gdzie startuje dashboard, a X gdzie schodzi postać, ustawić sprite zapełnionego $ff z priorytetem wyświetlania wyższym niż duszki postaci, ale schowanym pod background.
Wtedy obcinanie jest "za darmo". Nie trzeba zmieniać kolorów duszków, ani $d01b.

Dużo jestem w stanie tego wrzucić na planszę

https://drive.google.com/file/d/1zvv9Kf ... drive_link

Trochę było cicho w temacie ale tylko dlatego, że było sporo pracy . Efekty zobaczycie już wkrótce. Na razie kilka screenów.

Wersja demo już we wrześniu. Jest to kompletny poziom "Zamek Montezumy", dwa utwory muzyczne i zaimplementowana niemalże kompletna mechanika gry. Jest dostępne kilka schematów kolorystycznych oraz trainer, tak, aby ułatwić pracę crackerom z CSDB

Mówią w TV.
https://youtu.be/TqEFHbix6G0?si=egGzantOFlb2vj-D

Gratulacje!

Prace nad pełną wersją gry toczą się na 100%. Przy okazji jest bardzo duża szansa, że wersja na C64 wyjdzie poza ograniczenia sprzętowe innych platform

O, kurdę! Grafika wygląda świetnie:)
Może będą szanse na ścieżkę muzyczną + efekty dźwiękowe.

WOW

no w końcu. teraz to to wygląda bardzo fajnie, ale...

wiecie, że to oznacza że teraz amigowcy, a pewnie i atarowcy/spectrumowzy powiedzą, ale jak to? to my mamy niekolorowe a c64 ma mieć kolorowe? przerabianie wersji na inne platformy za 3..2..1...
tak czy siak. powodzenia z grą!

Gordian pisze: ↑

30 sty 2024, 11:24

O, kurdę! Grafika wygląda świetnie:)
Może będą szanse na ścieżkę muzyczną + efekty dźwiękowe.

Mam plan że będzie albo tylko Muzyka od Sami, albo Sound/FX ode mnie. Zamiast muzyki dałbym jakiś ambient sound zależny od komnaty plus odgłosy. Zobaczymy jak to wyjdzie. Nie chcemy zmuszać muzyka do komponowania muzyki na dwa kanały albo z wyłączaniem jednego wbrew jego woli.

carrion pisze: ↑

30 sty 2024, 11:46

no w końcu. teraz to to wygląda bardzo fajnie, ale...

wiecie, że to oznacza że teraz amigowcy, a pewnie i atarowcy/spectrumowzy powiedzą, ale jak to? to my mamy niekolorowe a c64 ma mieć kolorowe? przerabianie wersji na inne platformy za 3..2..1...
tak czy siak. powodzenia z grą!

Hires w 16 kolorach na Atari, jasne