Deep Platformer – technologiczne demo prostej platformówki

Odpowiedz Nowy wątek
2018-09-18 22:33
9

Biorąc pod uwagę fakt, iż moje wpisy na blogu dotyczące projektu Deep Platformer cieszyły się jakimś zainteresowaniem i że gramolę się niemiłosiernie z wydaniem końcowej wersji, podjąłem decyzję, aby już teraz opublikować wczesną wersję platformersa.

title screen.png


Deep Platformer

Deep Platformer to otwartoźródłowy projekt prostej platformówki. Pierwotnie miał to być jedynie wizualny test paralaksy oraz efektu płynnej zmiany warstwy, jednak z ciekawości i chęci eksperymentów, szybko przerodził się w coś znacznie większego.

Celem gracza jest sterowanie bohaterem w kształcie sympatycznego klocka, pokonywanie wielowarstwowych labiryntów w poszukiwaniu świetlików i bramki wyjścia. Sterowanie ogranicza się raptem do kilku klawiszy, pozwalających na chodzenie i skakanie, a także na wykorzystywanie specjalnych bramek. Dzielą się one na cztery kategorie: do zmiany warstwy, do zmiany kierunku działania siły przyciągania, do zapisu pozycji gracza oraz do wyjścia z planszy. Tylko bramka do zapisu bieżącej pozycji bohatera nie potrzebuje interakcji – pozostałe wymagają wciśnięcia odpowiedniego klawisza.

Demo składa się z intra (długiego lub krótkiego), menu, ekranów tytułowych dla różnych światów, pierwszego świata jako tutoriala (bez ekranu tytułowego), czterech światów podstawowych i jednego dodatkowego, a także siedmiu outro i creditsów. Każdy ze światów docelowo zawierać będzie po kilka poziomów, a wiele z nich również będzie wyposażonych w tematyczne, animowane cutscenki (tym zajmuję się obecnie).


Klawiszologia

Podstawowa obsługa platformówki ogranicza się do kilkunastu klawiszy. Bohaterem na boki poruszamy strzałkami, skaczemy spacją, bramek używa się strzałkami w górę i w dół (w zależności od funkcjonalności danej bramki). Rozgrywkę pauzuje się i wznawia za pomocą Escape, klawiszem F3 się ją resetuje a F4 zamyka. Klawiszami + i - zwiększa się lub zmniejsza okno. Jeśli okno nie jest rozciągnięte na pełen ekran, możliwe jest jego przesunięcie za pomocą myszy, na dowolny ekran.

Klawisze Escape i Space służą też do przyspieszania (a raczej pomijania) animacji.

Pełna lista klawiszy (również tych służących do debugowania) znajduje się w pliku readme.txt. Docelowo ten plik będzie zawierał pełen opis gry, ale póki co posiada tylko listę klawiszy.


Technikalia

Projekt w całości został napisany we Free Pascalu (Lazarus 1.8.4) i dzieli się na sześć różnych aplikacji – pięciu generatorów oraz głównej gry. Gra służy do grania (a jakże), a generatory do tworzenia binarek z jej zawartością. Kod źródłowy wszystkich wymienionych aplikacji możliwy jest do skompilowania do postaci 32- i 64-bitowej. Niestety, z racji konstrukcji kodu obsługi okna, jedyną wspieraną platformą jest Windows. Szkoda… :/

Wiele informacji na temat niecodziennych założeń oraz historii tworzenia tego pojektu podałem w moim ciągu wpisów na blogu, więc zainteresowanych takimi informacjami odsyłam do tych materiałów. Na blogu znajdziecie też zrzuty ekranu oraz fragmenty kodu. Natomiast jeśli ktoś ma jakiekolwiek pytania na temat technicznych aspektów tego projektu to z chęcią odpowiem na każde z nich.

Demówka jest przenośna (portable) – nie wymaga żadnego instalowania i nie zapisuje żadnych informacji na dysku użytkownika. Można ją uruchamiać z dysku lokalnego, z pendrive'a, a nawet z CD (jeśli ktoś jeszcze pamięta co to).


Kod źródłowy

Źródła głównej aplikacji (docelowej gry) składają się z 33 modułów, o łącznej liczbie linii równej 11.133:

  • Platformer.Main.lpr – główny moduł projektu,
  • Platformer.Window.pp – zawiera klasę formularza i jego obsługi,
  • Platformer.CommandLine.pp – zawiera klasę do obsługi linii poleceń,
  • Platformer.UserInterface.pp – zawiera klasę do manipulacji rozmiarem i pozycją okna,
  • Platformer.Game.pp – zawiera główną klasę gry,
  • Platformer.Scenes.pp – zawiera zestaw klas dla wszystkich scen gry,
  • Platformer.Story.pp – zawiera zestaw klas do obsługi fabuły gry i zarządzania nazwami plików,
  • Platformer.Buffers.pp – zawiera obiekty tylnych buforów oraz klasę bufora cyklicznego z templatkami szumu,
  • Platformer.Renderers.pp – zawiera klasy służące do renderowania wszystkiego co widoczne na ekranie,
  • Platformer.Time.pp – zawiera klasę głównego zegara utrzymującego zadany klatkaż,
  • Platformer.Fonts.pp – zawiera klasy reprezentujące fonty,
  • Platformer.Input.pp – zawiera drzewko klas do obsługi klawiatury,
  • Platformer.Cheats.pp – zawiera klasę do manipulowania trybem cheatowania (debugowania),
  • Platformer.Animations.pp – zawiera klasy do opisu wszelkich animacji (cutscenek),
  • Platformer.TitleScreens.pp – zawiera bazową klasę dla ekranów tytułowych,
  • Platformer.Sprites.pp – zawiera klasy przechowujące sprajty bohatera i świetlików,
  • Platformer.Levels.pp – zawiera klasy reprezentujące wielowarstwowy poziom,
  • Platformer.Slots.pp – zawiera klasę przechowującą dane na temat pozycji gracza (save slot),
  • Platformer.Worlds.pp – zawiera klasę opisującą ekran tytułowy dla światów,
  • Platformer.Menu.pp – zawiera klasę obsługi głównego menu gry,
  • Platformer.Camera.pp – zawiera klasę przechowującą dane na temat kamery,
  • Platformer.Gates.pp – zawiera zestaw klas do opisu bramek zmiany warstwy, grawitacji, zapisu oraz wyjścia,
  • Platformer.Fireflies.pp – zawiera klasy reprezentujące pojedynczy świetlik oraz ich listę,
  • Platformer.Hero.pp – zawiera klasy przechowujące dane na temat pohatera,
  • Platformer.Pause.pp – zawiera klasę przechowującą dane na temat zapauzowań rozgrywki,
  • Platformer.Counters.pp – zawiera klasy z danymi na temat liczby zgonów oraz zebranych świetlików,
  • Platformer.Scores.pp – zawiera klasy przechowujące statystyki gracza dla danej sesji,
  • Platformer.Movements.pp – zawiera klasy służące do modyfikacji pozycji gracza oraz świetlików,
  • Platformer.Collectors.pp – zawiera klasy z wydzieloną logiką kolekcjonowania (póki co tylko świetlików),
  • Platformer.Utils.pp – zawiera zestaw uniwersalnych subrutyn do przetwarzania bitmap,
  • Platformer.Types.pp – zawiera kilka typów danych, wymaganych głównie do renderowania tekstu,
  • Platformer.Helpers.pp – zawiera klasy helperów dla typów prostych i klas z biblioteki standardowej,
  • Platformer.Constants.pp – zawiera mnóstwo stałych, służących do kalibrowania gry i wielu jej elementów.

Generatory to dość proste aplikacje konsolowe, o specyficznej budowie i sposobie użycia. Składają się raptem z kilku modułów, a kod każdego z nich napisany jest w takim samym stylu.

Kod źródłowy nie zawiera żadnych komentarzy (nie licząc informacji o twórcy i licencji w każdym module). Nigdy ich nie dodaję, wzamian staram się pisać kod w taki sposób, aby sam informował o swoim przeznaczeniu. W razie czego pytać o szczegóły.


Uniwersalne fragmenty kodu

Projekt nie zawiera zbyt wiele fragmentów kodu, które możnaby zastosować w innych projektach, np. w zwykłych aplikacjach okienkowych. Jedyne moduły, których zawartość może być faktycznie przydatna, to Platformer.Utils.pp oraz Platformer.Helpers.pp. Znajdziecie tam praktyczne przykłady użycia metody ScanLine i efektywnej obróbki bitmap, a także przykłady rozszerzania typów prostych o dodatkowe metody.


Dalsze plany

Prace będą kontynuowane jedynie do ukończenia pierwszej wersji z pełną, docelową zawartością. Jak już wszystkie binarki m.in. z poziomami i animacjami zostaną ukończone, projekt wyląduje na GitHub (który posłuży tylko jako taki backup, bo w przyszłości nie zamierzam go rozwijać). Przetestowałem to co chciałem przetestować (a nawet o wiele więcej), a to co trafi do repozytorium, najpewniej już nigdy nie będzie przeze mnie aktualizowane.

Źródła udostępniam na licencji GPL, więc każdy chętny będzie mógł forknąć repozytorium i stworzyć coś swojego. Ewentualni moderzy będą mieli prostą drogę do przeróbek, za sprawą otwartego kodu źródłowego i dostępu do narzędzi, z których i ja korzystam. Oczywiście informacje na temat używania generatorów i tworzenia plików konfiguracyjnych znajdą się docelowo w plikach readme.txt (póki co są puste, a uzupełnię je na samym końcu).


Załączniki

deep platformer – release.zip

Zawiera skompilowaną wersję platformówki, bez źródeł. Niektóre pliki są jeszcze nieuzupełnione. Do dyspozycji są dwa pliki wykonywalne i oba zawierają to samo, tyle że ten z postfiksem debug ma włączony stały tryb debugowania, dzięki czemu można się pobawić również dodatkowymi opcjami.

Pliki wykonywalne nie są podpisane cyfrowo, do tego są skompresowane za pomocą UPX, więc oprogramowanie antywirusowe oraz pewne usługi Windows mogą ostrzegać przed potencjalnie szkodliwą zawartością. Pliki te są jak najbardziej czyste, nie zawierają żadnych wirusów.

deep platformer – mirror.zip

Jest to kopia całego katalogu z projektem, zawiera pełne źródła wszystkich aplikacji, skompilowane pliki wykonywalne oraz pliki konfiguracyjne (i nie tylko) dla generatorów, do tworzenia testowej zawartości. Jednym słowem wszystko co potrzebne do zbudowania gry i tworzenia zawartości.

Zawiera też skróty do generatorów (*.lnk) z ustalonymi parametrami, tak aby móc tworzyć binarki dwuklikiem, bez koniczności otwierania konsoli i ręcznego podawania parametrów ze ścieżkami (a te są dość długie). Skróty powłoki zawierają ścieżki relatywne, więc śmiało można z nich korzystać.


Have fun. ;)


edytowany 21x, ostatnio: furious programming, 2019-01-28 21:48
Wiem wiem, dlatego o tym wspomniałem. W razie braku zaufania, zawsze można odpalić w antywirusowym sandboksie. ;) - furious programming 2018-09-18 22:56

Pozostało 580 znaków

2019-01-27 20:55
1

Chwilę trwało, zanim zajarzyłam, że jak nad głową pojawia się napis "exit", to trzeba nacisnąć strzałkę w górę.

Skakanie na krawędziach: Jak Kwadratek zbiega z krawędzi platformy (ale częścią podstawy jeszcze na niej stoi) to już nie może się odbić. Dlatego nie przeszłam 3-ciej planszy. (edit: dobra, przeszłam po podpowiedziach).

Oznaczyłabym jakoś inaczej miejsca, w które się wpada, bo czasem nie ma różnicy pomiędzy niższym poziomem a końcem świata, na którym nie da się stanąć.

Poza tym fajny oldskul :)


edytowany 1x, ostatnio: Freja Draco, 2019-01-27 21:05
Kwadratek :D :D :D - cerrato 2019-01-27 22:04
Klocek, Kwadratek – jak zwał tak zwał. ;) - furious programming 2019-01-27 22:06

Pozostało 580 znaków

2019-01-27 21:09
1
Freja Draco napisał(a):

Chwilę trwało, zanim zajarzyłam, że jak nad głową pojawia się napis "exit", to trzeba nacisnąć strzałkę w górę.

Musisz się zapoznać z treścią wszystkich moich postów w tym wątku, bo wszystko w nich wyjaśniłem.

Skakanie na krawędziach: Jak Kwadratek zbiega z krawędzi platformy (ale częścią podstawy jeszcze na niej stoi) to już nie może się odbić. Dlatego nie przeszłam 3-ciej planszy.

To już zostało dawno temu naprawione – poprawkę opisałem w tym posćie. Źródła zawierające poprawioną wersję znajdziesz z kolei w tym poście.

Ten poziom da się przejść i bez możliwości odbicia z samej krawędzi – wystarczy pamiętać o tym, aby przy skoku nie przywalić głową w platformę nad przepaścią (czyli aby użyć niepełnego skoku). No i wcześniej założenie tego poziomu było takie, aby w ogóle nie dało się tej przepaści przeskoczyć – dopiero sam przez przypadek znalazłem sposób i dlatego zmieniłem jej przeznaczenie. Ale o tym wszystkim dowiesz się z cutscenek i oczywiście z pozostałych postów tego wątku. ;)


edytowany 2x, ostatnio: furious programming, 2019-01-27 21:10

Pozostało 580 znaków

2019-01-27 22:45
0
furious programming napisał(a):

To już zostało dawno temu naprawione – poprawkę opisałem w tym posćie. Źródła zawierające poprawioną wersję znajdziesz z kolei w tym poście.

Pobrałam, uruchomiłam, nie widzę różnicy.

Da się skoczyć:

  • stojąc jedną nogą na krawędzi i wykonując sekwencję: prawo + skok,
  • stojąc jedną nogą na krawędzi i wykonując sekwencję: skok + prawo.

Nie da się skoczyć, biegnąc po platformie i wciskając skok, jak już nie całkiem na niej stoimy.

Ponadto nie wiem, czy rozpęd ma tu jakieś znaczenie czy może skok z miejsca da ten sam efekt.

W każdym razie po 2x próbach nie udało mi się przeskoczyć. Ale mogę zaakceptować jako rozkminnogenną wkurzawkę.


Pozostało 580 znaków

2019-01-27 23:03
2
Freja Draco napisał(a):

Pobrałam, uruchomiłam, nie widzę różnicy.

Musisz potrenować. ;)

Nie da się skoczyć, biegnąc po platformie i wciskając skok, jak już nie całkiem na niej stoimy.

No takiego bubla to bym dawno zauważył, gdyby istniał. Da się bez problemu skoczyć nawet wtedy, gdy bohater wystaje poza kafel. Ba, wystarczy że stoi na platformie tylko jednym pikselem (właściwie to dwoma, bo w każdej klatce ruchu poziomego pozycja aktualizowana jest o 2px).

Sama zobacz (w dalszej części spowolniłem odtwarzanie):

Błąd dotyczący skoku z krawędzi dotyczył sytuacji, w której skaczemy w ostatnim momencie. To właśnie poprawiłem za sprawą sugestii ze strony @several i @Spine. Tak więc możliwe jest odbicie z platformy, bez względu na to jak dużo ciała bohatera wystaje.

Nie ma znaczenia nawet to, że nad głową jest platforma – choć jest to bardzo trudny skok (wymaga perfekcyjnego wyczucia, co do klatki), to i tak jest możliwy do wykonania, zobacz jak to w zwolnieniu wygląda:

Jeśli w dalszym ciągu masz problem ze skokiem z krawędzi to na pewno nie jest to wina logiki gry, bo tę sprawdzałem wielokrotnie, każdy przypadek z osobna. Już naprawdę nie mam co tam poprawić.

Ponadto nie wiem, czy rozpęd ma tu jakieś znaczenie czy może skok z miejsca da ten sam efekt.

Po wprowadzonej dawno temu poprawce, rozpęd nie ma żadnego znaczenia. W sumie to wcześniej też nie miał – z wyjątkiem sytuacji opisanej wyżej. Ale ten dotyczył sytuacji, gdy skaczemy z samiutkiego kraju platformy.

W każdym razie po 2x próbach nie udało mi się przeskoczyć. Ale mogę zaakceptować jako rozkminnogenną wkurzawkę.

Pograj, poucz się kontroli bohatera. W razie czego czytaj to o czym cutscenki informują. ;)


edytowany 4x, ostatnio: furious programming, 2019-01-28 00:38

Pozostało 580 znaków

2019-01-30 19:09
4

Wrzucam do załączników aktualne źródła projektu do potestowania.

Wprowadziłem jedną modyfikację w klasie okna gry, dzięki której pozbyłem się dodawania własnego komunikatu LM_AFTERSHOW do kolejki komunikatów okna, w celu wymuszenia pokazania okna na ekranie. Wcześniej główny obiekt gry uruchamiał ją w metodzie obsługi tego komunikatu, a teraz robi to bezpośrednio w zdarzeniu TForm.OnShow, uprzednio wymuszając pokazanie okna za pomocą metody ShowWindow z bieżącego widgetsetu. Pozbyłem się też handlera komunikatu LM_LBUTTONDOWN, w którym obługiwane było przesuwanie okna za pomocą myszy – teraz dzieje się to w zdarzeniu TForm.OnMouseDown. Czyli ogólnie pisząc, zamieniłem obsługę komunikatów na zdarzenia.

Kod projektu już wcześniej dało się skompilować np. pod Linuksem, jednak okno gry nie pokazywało się na ekranie (gra działała na niewidocznym oknie). Nie zagłębiałem się w ten temat, jednak obstawiam, że albo problemem było dorzucanie własnego komunikatu do kolejki, albo brak modułu CThreads w głównym module (nie mam doświadczenia z programowaniem na uniksy, więc to jedynie przypuszczenia). W każdym razie całkiem możliwe, że teraz nie tylko da się ten projekt skompilować, ale też i uruchomić. Jeśli w dalszym ciągu będą problemy z uruchomieniem gry po kompilacji na innej platformie niż Windows, to cóż… zawsze pozostaje wine. ;)


Tak więc do załączników dodaję – tak jak wcześniej – wersję release oraz mirror ze źródłami i ze wszystkimi plikami potrzebnymi do kompilacji i tworzenia zawartości. Poziomy są takie jak wcześniej, więc tutaj nie należy się spodziewać nowości (nad nimi teraz pracuję), jednak możecie się pobawić nowym ficzerem, czyli przesuwaniem kamery podczas rozgrywki, a także zobaczyć jak wygląda nowe menu gry i nowy ekran staffu.


edytowany 1x, ostatnio: furious programming, 2019-01-30 19:40
@furious programming: dobry wpis nie może czekać na okejki :-) - Aryman1983 2019-01-30 19:11

Pozostało 580 znaków

2019-01-31 19:43
3

Jeszcze taka mała aktualizacja, bo dodałem kilka małych usrpawnień.

Pierwszą zmianą jest nieco inny sposób renderowania warstw poziomu. Do tej pory np. podczas renderowania klatki gry (podczas rozgrywki), najpierw malowany był poziom (wszystkie warstwy od razu), następnie na nim bohater, świetliki i bramki, dalej oświetlenie (przyciemnienie klatki) i na koniec liczniki. To powodowało, że bohater zawsze był widoczny, nawet jeśli przechodził przez ukryte przejście (przez platformy). Wygląd bohatera i platform powodował, że podczas takiego przechodzenia przez ścianę, ciało bohatera zlewało się z platformami (jedno i drugie ma ten sam, czarny kolor) i było widać jedynie oczy klocka. Takie było pierwotne założenie, bo wyglądało to całkiem fajnie (oczy w ścianie), ale nie oddawało fizycznych właściwości poziomu.

Dlatego też rozbiłem algorytm renderowania poziomu na dwa mniejsze. Jeśli animacja zmiany warstwy trwa, malowane są wszystkie warstwy, a na nich kolejne obiekty, czyli między innymi bohater. Natomiast w normalnej sytuacji (animacja zmiany warstwy jest wyłączona), najpierw malowane są wszystkie warstwy oprócz bieżącej (tej czarnej), następnie renderowane są obiekty takie jak bohater i świetliki, a na koniec malowana jest bieżąca warstwa. To powoduje, że przykrywa ona bohatera i świetliki, więc podczas przechodzenia bohatera przez ukryte przejście w ścianie, jest on całkowicie niewidoczny (w końcu jest w ścianie) i ma to większy sens. Drugą zaletą jest to, że teraz można lepiej ukryć świetliki, bo te też są renderowane pod bieżącą warstwą. Dzięki temu można je nieco zamaskować detalami platform i tym samym utrudnić ich odnalezienie. Wiele kodu to nie kosztowało – raptem kilka nowych linijek.


Drugą nowością są dwie nowe dyrektywy dla kompilacji warunkowej – jedna pozwala pominąć sceny intra światów (aby móc testować tylko poziomy), a druga pozwala pominąć wszystkie poziomy we wszystkich światach (aby móc testować same intra światów). Kilka linijek kodu, a pozwolą szybciej stworzyć zawartość.


Jeśli o mniejsze poprawki chodzi, to zmniejszyłem wagę ikon dla projektów i ustawiłem ikonkę dla formularza (co prawda i tak nie posiada on ramki, ale to na wypadek gdyby system w którymś swoim narzędziu z niej korzystał). Zreorganizowałem też nieco strukturę katalogów – wyciągnąłem katalog z pomocniczymi grafikami z katalogu źródeł gry.

Pozostałych pierdółek nie ma co wymieniać, bo nie mają większego znaczenia. ;)


edytowany 6x, ostatnio: furious programming, 2019-01-31 19:48

Pozostało 580 znaków

2019-02-09 16:31
1

Na dziwną rzecz natrafiłem.

Po uruchomieniu gry, czas renderowania klatki w pierwszym poziomie tutoriala wynosi mniej więcej 46% (rozmiar zoom3x). Zwiększam okno stopniowo aż do pełnego ekranu, następnie powracam stopniowo do rozmiaru początkowego i czas renderowania wynosi już około 56%. Jeśli to samo zrobię tylko że pomniejszając okno od rozmiaru początkowego do najmniejszego, a następnie powiększę do początkowego to nic się nie zmienia – przed zmianą i po niej utrzymuje się około 46%. Test w trybie debug, poza debuggerem. W wersji release jest podobnie (40% po uruchomieniu, 50% po zabawie z rozmiarem okna).

Problem polega na tym, że zmiana rozmiaru okna nie wpływa na proces renderowania – okno co prawda jest większe/mniejsze, ale rozmiar tylnych buforów cały czas wynosi 224x128 pikseli. Natomiast finalny obraz klatki malowany jest na płótnie okna za pomocą metody Canvas.StretchDraw, bez względu na rozmiar formularza.

Sprawdziłem jak to wyglądało wcześniej i tego typu narzut też istniał, tyle że wynosił góra 2%, a nie 10%. Przekompilowałem stare źródła (są dwa posty wyżej w załącznikach) i to samo – różnica po zabawie z rozmiarem okna wynosi aż 10%. Ustawienia projektu (starsze i obecne) są dokładnie takie same i pomiędzy tymi wersjami źródeł nie ma żadnych różnic w mechanizmie renderowania.


Wygląda na to, że kod wynikowy projektu kompilowanego w Lazarusie 1.8.4 jest inny niż w wersji 2.0.0, pomimo dokładnie takich samych ustawień kompilacji i tej samej wersji samego kompilatora. Najpewniej coś zostało zmienione w bibliotece LCL, czego efektem jest utrata wydajności mojej gry… :/


edytowany 5x, ostatnio: furious programming, 2019-02-10 04:37
czyli standard - coś dodadzą, coś poprawią, coś popsują ;) - cerrato 2019-02-09 16:34
Pytanie - czy to 10% ma dla Ciebie znaczenie, gra się przez to przycina albo występują jakieś dziwne zjawiska, czy bardziej wkurza Cię sam fakt, że wydajność spadła (ale mimo tego gierka i tak daje radę)? - cerrato 2019-02-09 16:39
Jeśli czas renderowania wynosi mniej niż 100% to gra działa płynnie. Głównie zastanawiam się nad tym, dlaczego po zmianie rozmiaru okna, czas malowania rozciągniętej bitmapy na płótnie formularza wydłuża się (bo do tego się to sprowadza). - furious programming 2019-02-09 16:41
Nie mam pojęcia, ale jak coś ustalisz to daj znać, chętnie się czegoś dowiem/nauczę :) - cerrato 2019-02-09 16:43
Najpewniej nigdy się nie dowiem co jest tego powodem – musiałbym pogrzebać w bibliotece i sprawdzić różnice w stosunku do poprzedniej wersji, a tego mi się nie chce… :/ - furious programming 2019-02-09 16:50

Pozostało 580 znaków

2019-02-11 12:38
1

Jeśli chodzi o efekty ekranu, o których wspominałeś we wpisie Dawno temu umieściłem wpis n... , sądzę, że zainteresowałaby Cię gra Riptale ( https://store.steampowered.com/app/616000/ ).
W opcjach można sobie zmieniać filtry obrazu ;) Mógłbyś do swojej gry dorzucić takie coś + opcje dotyczące scanlines.

screenshot-20190211123741.png
screenshot-20190211123753.png
screenshot-20190211123805.png
screenshot-20190211123813.png
screenshot-20190211123822.png

Pozostało 580 znaków

2019-02-11 17:05
1

@Spine: żeby dodać jakiekolwiek opcje, to najpierw musiałbym zrobić funkcjonalność menu i jego obsługi, a takiego w ogóle nie ma w całej grze. No i pozostaje też kwestia przechowywania ustawień – trzebaby użyć plików lub rejestru, a gra ma być tak skonstruowana, aby niczego nie zostawiała w komputerze użytkownika.

Żeby się za bardzo nie narobić to można dodać wsparcie takiej opcji do linii poleceń, ale ze względu na spore ograniczenia (brak wsparcia jakiegokolwiek post-processingu), nie będę implementować żadnego filtru, który miałby modyfikować końcowy obraz klatki (o rozmiarze okna).

Nie mogę w kółko dodawać nowych ficzerów – muszę w końcu skończyć tworzyć zawartość i puścić ten projekt w świat. Może kiedyś jak mnie najdzie ochota na jego rozwinięcie to rozszerzy się jego funkcjonalność o różne wodotryski. ;)


edytowany 1x, ostatnio: furious programming, 2019-02-11 17:05

Pozostało 580 znaków

2019-04-15 20:10
2

Dawno mnie tu nie było, więc pasuje odświeżyć informacje na temat projektu, bo trochę się zmieniło. :]


Pierwsza ważna rzecz – kod został przeportowany na Uniksy i daje się skompilować na innych platformach niż Windows. Portowanie kodu było kłopotliwe i szło jak krew z nosa, pomimo tego, że tego specyficznego dla innych platform było raptem kilkadziesiąt linii. Klatki nie były renderowane prawidłowo, za co odpowiadają metody wykorzystujące ScanLine do obróbki bitmap. Koniec końców okazało się, że załadowana bitmapa z pliku zmienia format pikseli z natywnego dla Uniksów 32-bitowego na 24-bitowy, przez co metody używające załadowanych z plików bitmap czytały śmieci z pamięci i malowały ”dziwne” kolorowe pasy (albo się wykrzaczał wyjątkiem). Trzeba było dodać prosty mechanizm konwertujący bitmapę tuż po załadowaniu.

Teoretycznie teraz można ten kod skompilować na innych systemach, takich jak Linuks, FreeBSD czy macOS, ale jest pewien haczyk – wydajność jest kilka razy gorsza niż na Windows, więc aby utrzymać płynność działania na tych systemach, trzeba mieć dobry pecet (wystarczy, że będzie w miarę współczesny). Gra została też przetestowana na Raspbianie i choć uruchamiała się i działała, to miała problem z wydajnością (27fps zamiast 60fps, parametry sprzętu nieznane) i z renderowaniem warstw większych poziomów, przez co jest raczej niegrywalna.

Ciekawe jest to, że testerom (jako graczom) wcale nie przeszkadza niski framerate, co mnie mocno zdziwiło.


Jeśli chodzi o samo renderowanie obrazu, to tutaj też pojawiły się zmiany. Pierwsza jest taka, że napisałem swój odpowiednik metody TCanvas.StretchDraw – musiałem to zrobić, bo linuchowa biblioteka do GUI nie umie rozciągać bitmap bez antialiasingu (używa go pomimo jego wyłączenia). Plus jest taki, że mój odpowiednik dość wiernie imituje zachowanie oryginału i przyczynił się do zwiększenia wydajności kodu renderującego o około 10%. Nie dlatego, że działa szybciej niż np. windowsowy StretchBlt, a dlatego, że dzięki niej proces renderowania warstw poziomu jest prostszy – teraz każda warstwa renderowana jest bezpośrednio na buforze ramki, zamiast najpierw na pomocniczym, z którego po pomalowaniu platform na wybrany kolor była kopiowana do głównego bufora. Bufor pomocniczy został całkowicie usunięty, bo już nie był potrzebny.

Zmieniłem też ustawienia projektu i usunąłem wszystkie własne symbole debuggera. Teraz można wyłączyć konkretne sceny podając odpowiednie parametry przy rozruchu, dzięki czemu nie trzeba ciągle rekompilować projektu, aby móc szybciej testować grę. W sumie to w ogóle nie potrzeba do tego źródeł. Tak więc linia poleceń daje o wiele więcej możliwości niż wcześniej.

Poprawiłem też tryb dla speedrunnerów – dodatkowa zawartość dla trybu speedrun jest zawsze dostępna i tryb ten ma osobne outra, w których zawsze pokazywany jest czas rozgrywki, liczony w milisekundach (zwykły zegar cyfrowy w formacie H:NN:SS.ZZZ) oraz w klatkach. Tryb podstawowy natomiast nadal wymaga przejścia gry perfekcyjnie, aby odblokować dodatkową zawartość.

Reszta zmian dotyczy organizacji klas i ogólnie zwiększenia czytelności kodu, tego raczej nie ma co opisywać.


Do załączników dodaję bieżące źródła gry (razem z windowsowym plikiem wykonywalnym) – można się pobawić. Jeśli jest tutaj ktoś, kto używa Lazarusa na innym systemie niż Windows, to fajnie by było gdyby skompilował źródła, sprawdził jak gra działa i dał znać. :]


edytowany 3x, ostatnio: furious programming, 2019-04-15 20:21
27 fps? Czy Ty w ogóle używasz GPU :P ? Wiesz.. takie coś, co wszystkie dzisiejsze gry wykorzystują :D - Spine 2019-04-15 23:57
Wiesz przecież, że założeniem jest jego nieużywanie. ;) - furious programming 2019-04-15 23:58
Ale to nie moja wina, że GTK działa tak a nie inaczej. Sprawdziliśmy testami jak wypada framerate bez odmalowywania okna i oczekiwania pomiędzy klatkami – mój dziadziusiowy laptop generuje ponad 150fps, a Rasbian (hardware nieznany) tylko 27fps – Ubuntu na Pentium 4 3GHz też nie wyrabia. Windows rulez. :D - furious programming 2019-04-16 00:01
No nie wiem... W czasach Visty, Compiz zjadał Aero na śniadanie ;) Jeśli chodzi o wyświetlanie okienek i operacje na nich. - Spine 2019-04-16 00:02

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0