jakiś czas temu bardzo mnie zainteresowała technika raycastingu
i postanowiłem się pobawić. Metoda ta pozwala na wydajne generowanie grafiki 3D/2,5D
co dodatkowo zacząłem rozpatrywać w kontekście "nowoczesnych" amigowych akceleratorów,
które mają zintegrowane RTG. Chciałem nie tylko poeksperymewntować z samym raycastingiem,
ale również z wydajnością na tych kartach i zobaczyć co można osiagnąć.
Przygodę zacząłem na PC, używając tylko języka C i projektując kod w taki sposób
aby silnik był niezależny systemowo i jedynie dostarczał "gotowy produkt"
w postaci wygenerowanej ramki którą to już dany system miał sobie wyświetlić.
Na Win korzystałem tylko z natywnej biblioteki do blitowania na ekran, na Ami chce w RTG.
Celem zabawy jest zaprojektowanie w miarę możliwości wydajnego i zoptymalizowanego silnika,
gdzieś pomiędzy Wolf 3D, a Doom. Nie chciałem tylko standardowych "klocków", ale również
dowolnie ukośne ściany i prostokątne, multitexturing i cieniowanie. Mam taki pomysł
żeby dodatkowo dodać możliwość używania wypalonych map intensywności, które by zawierały
realistyczne oświetlenie i cienie. Generalnie na razie skupiam się na samym tworzeniu
środowiska, próbując optymalizować co się da. Zrobiłem również edytor.
Poniżej dzielę się moimi bojami z tym tematem, które postaram się aktualizować jak
tylko zrobię coś nowego/ciekawego. Porady i uwagi mile widziane.
--- WYNIKI ---
Najlepszy wynik jaki do tej pory uzyskałem to płynna "rozgrywka" na V1200 (średnio 35-45 fps) w 320x200 w 32bit, gdzie:
- ściany, podłogi oraz sufity poza texturami mają "na sobie" wypalone lightmapy, które mogą symulować fajne oświetlenie.
- distance shading, dodający nieco "dynamiczności" do statycznego cieniowania
- mip-mapping, pozwala on głownie na redukcjie lub pozbycie się migotania textur podczas ich skalowania.
- "świecące pixele", pixele o dużej wartośći RGB które opierają się cieniowaniu przez co są widoczne jako "światła".
--- FILMIKI ---
12. Kolejny algorytm do renderu podłogi i sufitu:
11. Kolejny poziom demo:
10. Mip-mapy dalej:
09. Wszystkie warianty cieniowania:
08. Pierwsze próby z lightmapami:
07. Demo level
06. Nowy algorytm renderowania podłóg i sufitów. Informacje zebrane podczas renderowania ścian
są wykorzystywane aby wyrenderowac podłogi i sufity bez "nadrysowywania"
05. Jeszcze taka zabawa - test. Porównanie oryginału w true color, a potem z kwantyzacją kolorów do 8x8x8 czyli 256,
a potem jeszcze dithering metodą Floyda-Stainberga.. wychodzi fajna retro stylizacja
04. KOLEJNE AMIGOWE OPTYMALIZACJE (AMIGA)
Niech filmik mówi powie sam za siebie. To jest wersja z pixelami 1:1.
Na Vampirach w 320x240x32 nawet grywalne ok 15-18 fps.
Ja dodam, że samo texturowane ściany wraz z cieniowaniem
wyszły mi bardzo szybko. Sporo optymalizowałem. Na vampirach w 320x240x32 było szybko i płynnie,
przy 640x480x32 grywalnie. Problemy pojawiły się przy teksturowaniu podłóg i sufitów. Nie dało ich się już
tak ładnie zoptymalizować jak ścian, które mają swoją specyfikę.
Kombinowałem z co drugim rzędem i co drugą kolumną - był spory efekt przyśpieszenia, no ale
bez uzupełnienia tych "dziur" mieliśmy efekt "led". Próbowałem interpolować pomiędzy istniejącymi kolorami -
niestety efekt końcowy powodował brzydkie rozmycie textur.
Podsumowując bez ASM to raczej nie wyciągnę już z tego więcej tak mi się wydaje.
Przy lepszej optymalziacji powinno być możliwe przynajmniej 40-50 fps w 320x240x32
a przy wykorzystaniu instrukcji VAmpira AMMX pewnie jesszcze wiecej, a w 640x480x32
powinno byc grywalne - jakosciowo w 640x480 bardzo mi sie podoba:
03. PIERWSZY PORT NA AMIGĘ (PC -> AMIGA)
To mój pierwszy kontakt z RTG i systemowym programowaniem w C na Amidze.
Efekt dwóch dni pracy. Not great.. not terrible.. na uwagę zasługuje fakt,
że kod skompilował się od razu bez problemów i uruchomił - tak jak chciałem. Jednak ze względu na
różnicę kolejności bajtów PC-AMIGA, na Amidze mapa została wczytana z dziwnymi wartościami
co spowodowało tylko czarny ekran - ale nic się nie zawiesiło :D
Po tej poprawce pojawił się widok znany mi już z PC. Ze względu na jakiś bug w tworzeniu Screena,
nie dało się tego przetestować na Vampirze ani niczym innym niż winuae, więc nie mam żadnego
punktu odniesienia. W tym momencie używam api P96, ale przeniosę się na CGX i wtedy od razu poprawie okno.
I będzie można od razu przetestować całość w praniu. Ze względu na krótkie doświadczenie w systemowym
Amigowym programowaniu pewnie roi się tam od błędów, które wpływają też na wydajność.
02. EDYTOR (tylko PC)
Na razie podstawowe funkcje, ściany - kilka rodzajów, sufity, podłogi, itp.
Wszystkie elementy z edytora były już zaimplementowane w silniku, łącznie z ukośnymi
i nieregularnymi ścianami. Na razie jednak to wyłączyłem zostawiając tylko klocki,
aby skupić się na optymalizacji tej części i zrobić pierwszy port na Amigę.
01. PIERWSZE POSTĘPY (PC)
Warto tu zwrócić uwagę na efekt, którzy zupełnie przypadkiem udało mi się osiągnąć.
W jednym z filmików widać jakby efekt raytracingu, jakby sciany się odbijały
w podłodze.
----- DOWNLOAD -------
Zapraszam na mojego GitHub-a, wrzucam tu kolejne wersje na bieżąco
jeśli udało się zrobić jakiś większy postęp. Są tu źródła w C oraz frameworki do Amigi i Windows,
a także execi zarówno do Amigi i Windows (folder The Game Output)
*obecnie wersja na Amigę wymaga 32 bit RTG oraz szybkiego procesora.
Zalecane są "nowe" karty typu: Vampire1200, IceDrake, FireBird, Warp1260, TF1260 (+RTG),
Emu68, PiStrom, PiAmiga itp.
----- CIEKAWE ŹRÓDŁA DLA ZAINTERESOWANYCH (aktualizowane) -------
Wszystkim zainteresowanym tematem Raycastingu lub programowaniem grafiki, polecam poniższe źródła,
na które się natknąłem. Gdy będę znajdywał coś ciekawego, będę robił aktualizację.
Podstawowe założenia raycastingu pozostają te same. W zależności od autora, poradnika czy tutoriala,
można spotkać się z wieloma różnymi podejściami, gdyż niektóre rzeczy można obliczać na różne sposoby.
Można spotkać metody bardzo wydajne jak i bardzo obciążające nawet szybkie komputery.
Dlatego po zaznajomieniu się z tematem warto "szperać" w poszukiwaniu, np. bardziej wydajnego algorytmu obliczającego "to lub tamo".
1. Na początek polecam pierwsze 3 minuty tego filmiku. W fajny wizualny sposób pokazuje jak działa raycaster.
Potem autor koduje podstawy ale nie polecam tej metody, a sam kod jest okropny. Warto również przejrzeć inne
filmiki tego autora: https://www.youtube.com/watch?v=gYRrGTC7GtA
2. To chyba najczęściej spotykane źródło wiedzy o raycastingu, pełny tutorial Lode Vandevenne'a poruszający
chyba wszystkie kwestie raycastingu. Do tego źródła i optymalne algorytmy. Na tej stronie również inne
tematy związane z grafiką: https://lodev.org/cgtutor/index.html
Lodev opisuje i porównuje tutaj dwie metody rysowania podłóg i sufitów vertykalną i horyzontalna która jest nieporównywalnie szybsza.
Mój obecny raycaster, który jest już 3 podejściem do tego tematu - opiera się właśnie na tym poradniku,
gdyż po różnych próbach zauważyłem, że autor zastosował dobre podejście pozwalające uniknąć wielu obliczeń.
Warto zauważyć, że mimo iż Lodev generuje podłogę i sufit bardzo szybko, to niepotrzebnie zarysowauje nimi cały ekran
po to by następnie rysować same ściany.
3. Drugie najczęściej spotykane źródło wiedzy, tutorial Permadiego. Na tym poradniku operałem się po raz pierwszy, ze względu na bardzo obrazowe
wyjaśnienie i podejście. Jednakże jak pokazały kolejne testy i zabawy - to podejście jest gorsze wydajnościowo niż to poprzednie.
Warto zauważyć iż Permadi stosuje tutaj wertykalne rysowanie sufitów i podłóg, jest to bardzo nieoptymalny algorytm,
działający bardzo wolno nawet na szybkich maszynach:https://permadi.com/1996/05/ray-casting-tutorial-table-of-contents/
5. Polecam gorąco kanał YouTube tego Pana - javidx9 (aka One Lone Coder): https://www.youtube.com/channel/UC-yuWVUplUJZvieEligKBkA Wykorzystuje on chyba własny silnik rysujący działający w konsoli. Za jego pomocą,
tzn. zwykle prostych, podstawowych funkcji jak rysowanie pixela czy linii, pokazuje podstawowe rzeczy związane z tworzeniem grafiki, ale też różne algorytmy, kolumny itp.
Wiele rzeczy, pomysłów i rozwiązań z których można zaczerpnąć. Warto przejrzeć cały kanał w poszukiwaniu ciekawych rozwiązań i zagadnień, sporo również wytłumaczonych "oldskulowych i retro" rozwiazań, ale nie tylko. Poniżej kilka moich propozycji:
a) https://www.youtube.com/watch?v=ZQ8qtAizis4 to mi się bardzo przydało, np. do tworzenia edytora, ale nie tylko, tworzenie, skalowanie, przesuwanie "grida", który może być również bitmapą, planszą do gry itp:
b) https://www.youtube.com/watch?v=NbSee-XM7WA - tutaj nawiązanie i wytłumaczenie algorytmu z punktu 2. czyli tutoriala Lodev'a, (jak mówiłem często spotykany :) tutaj, jest on dokłądnei tłumaczony, jest też implementacja, ale implementacja Lodeva jest wydajniejsza moim zdaniem, nie ma sqrt(), a w tym są dwa.
c) generalnie jest to kanał pełen inspiracji, polecam..
7. Kursik Pikuma o raycastingu na bazie wolfa3d - płatny.. ciężko mi go ocenić, ogólnie taki sobie, choć gość tłumacz dość dokładnie pewne zagadnienia, podejście inne niż u Lodeva, bardziej oparte o trygonometrie. https://courses.pikuma.com/courses/raycasting-c. Cześć robi w java script a potem już w C.
9. Polecam też kanał tego Pana - choć jest mega wkurzający i dziwnie się zachowuje: w tym przykładowym filmiku implementuje kwantyzacje kolorów i dithering metodą Floyda-Stainberga wg algorytmu z Wikipedii: https://www.youtube.com/watch?v=0L2n8Tg2FwI
Robi wrażenie, gratki!
Super że udało się szybko sportować wersję amigową, bo czasem można utknąć na jakiejś pierdółce na długi czas (a materiałów/przykladow w sieci na temat API Amiga OS czasem trzeba długo szukać) i się traci czas, a tu efekt jest od razu i to jaki!
Że co? A Quake1 był w czym napisany? A Doom? Uciągnie bez problemu jedynie co pewnie trzeba bedzie zrobic to zejsc do 8bitów, ale tez tego nie jestem pewny.
Sprawdziłem, faktycznie. Adoom ma troche kodu w asemblerze, ale nadal nie rozumiem dlaczego przepisanie tego kodu na C zwolniło by Adooma więcej niz 1.5x. Adoom na karcie GFX z 060 ma jakieś 25-40fpsów (zależnie od karty i mhz w 060). Więc wersja w C miałaby 15-25fpsów.
Na razie tylko patrzę co można w ten sposób wyciągnąć, jest jeszcze wiele rzeczy które można zoptymalizowac - to taka pierwsza kompilacja po kilku dniach piereszeho kontaktu z amiga w c i systemie. Więc pewnie jeszcze masy rzeczy nie wiem. tez się boję że bez asm będzie kiepsko z tym, może potem Koledzy coś z tym pomogą ;) vampir dodatkowo ma instrukcje ammx.. fajnie by było zrobić chociaż benchmark z tego.. postaram się w ciągu kilku kolejnych dni poprawic poprawić babola z otwieraniem screena i porobic kilka typowo amigowych optymalizacji i udostępnię demko do testów, to zobaczymy w praniu jak to wygląda... jeśli wersja w C wtedy miałaby z 25fps to byłoby bardzo super jak 1fps to cienko to widzę:D
Ostatnia aktualizacja: 09.03.2021 11:47:26 przez mateusz_s
Rób swoje, zobaczymy co z tego wyjdzie. ;) Weź tylko pod uwage, że w tej chwili pętla gry to jest samo renderowanie - a dojdzie pewnie jakieś AI przeciwników, jakaś bardziej rozbudowana fizyka, itede, itepe. Jakoś to będziesz musiał w międzyczasie policzyć, więc FPSy jeszcze trochę spadną.
EDYT: a jak już się bawisz w raycasting, to byś mógł zrobić wersję pod czipset używającą copperchunky - rozdzielczość pozioma 40, pionowa ile sobie wymyślisz. Taka rozdziałka 40x40 to byłaby niezła abominacja. ;)
Ostatnia aktualizacja: 09.03.2021 14:50:41 przez teh_KaiN
Możesz założyć wątek na innym forum, a tutaj dać odnośnik i poprosić szybko o zamknięcie tematu, bo i pierwszego postu będzie po jakimś czasie w tym bałaganie ciężko znaleźć.
Ostatnia aktualizacja: 10.03.2021 03:41:20 przez san_u
kurde, to jest grube..
Quake 1 w 640x480, dropuje ale zupełnie grywalny.. ciekawe jaki to port?
I przede wszystkim jak Ktoś to zoptymalizował? Czy dużo tam asemblera, może tych AMMX z Vampira użyli.
Jeśli w pełnym 3d tak "śmiga" na 640x480 to raycster tym bardziej powinien, bo tam jest nieporównywalnie mniej obliczeń..
Ciekawe czy Quake używał fixed-point zamiast floatów? Nie przeglądałem tego kodu..
Jedni lubią chodzić po górach inni programować stare komputery, a jeszcze inni świecić p**zdą na showupie :)
Ja od czasu do czasu programuje różne aplikacje graficzne na PC, najczęściej do pomocy w pracy,
lubię poznawać triki optymalizacyjne, a praca nad takim raycasterem to dla mnie i hobby i nauka,
dodatkowo portowanie na zupełnie inny system i architekturę, to również dodatkowa wiedza.
Do tego dochodzi badanie wydajności nowych ciekawych podzespołów itp.. co kto lubi..
Ostatnia aktualizacja: 11.03.2021 17:22:00 przez mateusz_s
Oglądając Twoje raycasterowe prace przypomniałem sobie o UnderWare Design, swego czasu udało mi się wydębić linka do ekzeków, teraz widzę że są na stronie do zassania. Jak na A1200 z Fastem to nieźle to wygląda.
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies
(ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach.
Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy
niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki
internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.