19.04.2023 17:05
[#391]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #386
Dobra robota. Przyjrzę się źródłom w wolnej chwili. interesuje mnie szczególnie inicjowanie i obsługa RTG.
Więc jeśli można to mam pytanie: w jaki sposób wstawia się pixele na RTG? czy masz zmapowany jakiś obszar w pamięci i poprostu wstawiasz "na chama" bajty czy jest jakieś API? czy może coś na kształt C2P?
Więc jeśli można to mam pytanie: w jaki sposób wstawia się pixele na RTG? czy masz zmapowany jakiś obszar w pamięci i poprostu wstawiasz "na chama" bajty czy jest jakieś API? czy może coś na kształt C2P?
19.04.2023 18:19
[#392]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@c64portal, post #391
Ja korzystam ze zwykłego bufora 4 bajtowego na ARGB o rozmiarze ekranu i tam generuje pixel po pixelu
wszsytko swoimi funkcjami - no to wynika z uroku generowania grafiki 3d ze musisz poobliczać te wartości.
korzystam z funkcji LockBitaMap z API cybergraphics.library i rysuje od razu na ekran,
ale żeby nie mogało to korzystam z double albo triple buffer - tak jest chyba najszybciej bo nic nie kopiujezs po drodze
wszsytko swoimi funkcjami - no to wynika z uroku generowania grafiki 3d ze musisz poobliczać te wartości.
korzystam z funkcji LockBitaMap z API cybergraphics.library i rysuje od razu na ekran,
ale żeby nie mogało to korzystam z double albo triple buffer - tak jest chyba najszybciej bo nic nie kopiujezs po drodze
19.04.2023 18:28
[#393]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #392
ale ten bufor który allokujesz to jest w RAMie? jeśli tak to potem chyba jakieś przekopiowanie tego do pamięci karty następuje?
... i tak jestem gotów ;) na robienie całych obliczeń samemu na pixelach w buforze (choć pewnie zacząłbym od 8bitowego koloru indeksowanego)
... i tak jestem gotów ;) na robienie całych obliczeń samemu na pixelach w buforze (choć pewnie zacząłbym od 8bitowego koloru indeksowanego)
20.04.2023 09:38
[#398]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #395
[Nie wiem czy ty nieco zakręciłeś czy ja po prostu rano wolno myślę, to trochę wygląda jakbyś renderował od razu do pamięci karty graficznej. Jeżeli tak jest to czytać dalej, jeżeli masz bufor w pamięci systemowej a potem po prostu kopiujesz do pamięci karty to reszta tego co napisałem jest nieistotna]
Używanie bufora ramki (ekranu) jako bufora do renderingu jest niebezpieczne z punktu widzenia wydajności. Czytanie czegokolwiek z pamięci karty będzie dużo wolniejsze niż z pamięci systemowej. Tu będzie też nieco spekulacji więc bez zmierzenia nie dam głowy, ale jest jeszcze jedna kwestia. W zależności od procesora (nie wiem czy 040 ma mechanizm buforowania zapisów) oraz od tego jak zmapowana jest pamięć karty graficznej (tryb cache) przy nieuważnym podejściu do zapisu (brak ciągłości oraz zapisywania każdego piksela) można płacić też koszt odczytu danych w celu pobrania linii cache przez procesor.
Ogólnie polecałbym jednak pośredni bufor w pamięci systemowej. W przypadku kart graficznych i koloru >8bit dochodzi też kwestia formatu pikseli a to łatwiej ogarnąć podczas przewalania danych na kartę. Nie zawsze rendering = kopiowanie pikseli gdzie można sobie format ogarnąć już w danych źródłowych.
Używanie bufora ramki (ekranu) jako bufora do renderingu jest niebezpieczne z punktu widzenia wydajności. Czytanie czegokolwiek z pamięci karty będzie dużo wolniejsze niż z pamięci systemowej. Tu będzie też nieco spekulacji więc bez zmierzenia nie dam głowy, ale jest jeszcze jedna kwestia. W zależności od procesora (nie wiem czy 040 ma mechanizm buforowania zapisów) oraz od tego jak zmapowana jest pamięć karty graficznej (tryb cache) przy nieuważnym podejściu do zapisu (brak ciągłości oraz zapisywania każdego piksela) można płacić też koszt odczytu danych w celu pobrania linii cache przez procesor.
Ogólnie polecałbym jednak pośredni bufor w pamięci systemowej. W przypadku kart graficznych i koloru >8bit dochodzi też kwestia formatu pikseli a to łatwiej ogarnąć podczas przewalania danych na kartę. Nie zawsze rendering = kopiowanie pikseli gdzie można sobie format ogarnąć już w danych źródłowych.
20.04.2023 11:12
[#401]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@kiero, post #400
O ile się orientuję (nie patrzyłem w kod) to silnik otwiera ekran (RTG) oraz allokuje jeszcze jedną bądź 2 bitmapy na buforowanie. Prawdopodobnie bitmapy z flagą BMF_DISPLAYABLE (czyli w pamięci vram karty graficznej ale normalnie powinna ta pamięć być widziana przez CPU). Po czym następuje rendering bezpośredni do tych bitmap własnymi funkcjami (LockBitmap/UnLock) i podmiana gotowej bitmapy podczas VBL, oraz rozpoczęcie rysowania w następnym buforze.
Dane w buforach są typu chunky 32bit ARGB. W przypadku renderingu do trybów planarnych c2p ogarnia sprawę jak widać całkiem nieźle
Dane w buforach są typu chunky 32bit ARGB. W przypadku renderingu do trybów planarnych c2p ogarnia sprawę jak widać całkiem nieźle
20.04.2023 11:36
[#404]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@pisklak, post #401
O ile się orientuję (nie patrzyłem w kod) to silnik otwiera ekran (RTG) oraz allokuje jeszcze jedną bądź 2 bitmapy na buforowanie. Prawdopodobnie bitmapy z flagą BMF_DISPLAYABLE (czyli w pamięci vram karty graficznej ale normalnie powinna ta pamięć być widziana przez CPU). Po czym następuje rendering bezpośredni do tych bitmap własnymi funkcjami (LockBitmap/UnLock) i podmiana gotowej bitmapy podczas VBL, oraz rozpoczęcie rysowania w następnym buforze.
No to niezbyt dobrze. Może to działa spoko na vampire gdzie pamięć jest i tak ta sama i nie leci przez wolną szynę. Na "normalnej" karcie graficznej będzie słabo. Pomijam już kwestię potencjalnej konwersji formatów.
W przypadku renderingu do trybów planarnych c2p ogarnia sprawę jak widać całkiem nieźle OK
Tutaj nie ma problemu bo zakładam że autor nie renderuje do chip-ramu żeby potem z niego czytac podczas robienia konwersji c2p:)
20.04.2023 11:41
[#405]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@c64portal, post #402
to czy takie pisanie do pośredniego bufora a potem do karty będzie szybsze czy wolniejsze od c2p w 8bitach?
W przypadku karty nie masz c2p. To po pierwsze. Jeżeli nie potrzebujesz c2p i jesteś w stanie napisać renderer który zapisuje dane tylko sekwencyjnie (liniami poziomymi) zapisując każdy punkt tylko raz, to jesteś w stanie renderować dane bezpośrednio do pamięci karty szybciej niż pośrednio do pamięci i potem kopiowanie. Da się napisać takie coś też używając c2p ale zakładam że nie schodzimy tak nisko.
Wszystko inne (łącznie z twoim punktem #2) wyjdzie lepiej jeżeli będziesz miał bufor w pamięci. Na karcie po prostu kopiowanie na kartę a na aga c2p.
13.10.2023 20:45
[#409]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@kiero, post #408
cześć,
od jakiegoś czasu chciałem przetestować pewien swój pomysł
na wersję 8-bitową tak żeby można było pod AGA wyświetlać szybko
i przy okazji sprawdzić czy byłby jakiś wzrost FPS.
Zrobiłem to w ten sposób:
1.
Jest jedna główna, statyczna paleta 256 kolorów [P].
Od jej zawartości zależy też jakość i efekt końcowy,
w tym przykładzie dałem 224 odcieni szarości i 32 odcienie niebieskości.
Docelowo oczywiście trzeba by dodać kilka dodatkowych innych odcieni więcej,
żeby nie było tak smutno.
2.
Celem jest utworzenie tablicy intensity_indexes[k]
gdzie i - to intensywność od 0-255, a k - to index to głownej palety P, też 0-255.
Kolory w palecie P odpowiadają kolorom oryginalnych tekstur czyli gdy jest największa intensywność == 255.
I np. jeżeli w oryginlnej palecie P (tj. intensywności = 255) mam kolor niebieski pod indexem 150 i potrzebuję go w wersji
o intensywności np. 100 czyli sporo ciemniejszej to dzięki tablicy mogę go znaleźć w taki sposób:
niebieski_i100 = intensity_indexes[100][150];
3.
Jak utworzyłem taką tablicę.
- najpierw zduplikowałem oryginalną paletę P w ilości 256 razy, gdzie dla 0 wszytskie koloryu są czarne a dla 255 są oryginalne jak juz pisałem.
- pozostałe palety w zakresie 1-254 zostały krok po kroku ściemnione
- teraz cała sztuka polega na tym żeby dla każdego koloru znaleść jego odpowiednik (jak najbliższy kolor) w głownej Palecie P
- tutaj można na rózne sposoby. ja zamieniełem dane kolory z RGB na CIELAB i obliczyłem deltę ( ta metoda chyba sie nazywa CIE73 czy jakoś ale są inne),
poniżej cały algorytm ktory znalezłem na stockoverflow:
https://stackoverflow.com/questions/1678457/best-algorithm-for-matching-colours/1678498?fbclid=IwAR0FGXiyL2aq3u3tY-KA6WaxGDfP601khvshAMha7a2qtG4XP-9Bz_eNanY#1678498
Efekty końcowe nienajgorsze...
jak powiedzialem dużo zależy od tego jak zostaną dopasowane kolory w Palecie,
ten algorytm CIE73 poradzil sobie nie najgorzej, ale pewnie recznie by sie przydalo pare poprawek porobić.
pod AGA na TV CRT nawet spoko wygląda, z użyciem C2P Kalmsa jest bardzo szybko i w pełni grywalne (V1200)
niestety przy Kalmsie chyba mi indeksy troche pomieszał wiec tylko spradzilem predkosć, przetestowałem też systemowy WriteChunkyPixel
tu kolory są dobre, ale jest oczywiscie troceh wolniej niż Kalms C2P.
W wersji RTG 8-bit miałem na V1200 38 fps a w wersji 32bit 42 fps xDDD czyli zamiast szybciej to wolniej hehe
Poniżej dodatki:
- wykorzystana paleta kolorów
- 8-bit na TV CRT z użyciem systemowej funkcji WriteChunkyPixels
- 8 bit na TV CRT i LCD z użyuciem c2p Kalmsa (kolorki zrypane, a raczej indeksy)
[i]Ostatnia aktualizacja: 13.10.2023 20:48:01 przez mateusz_s
od jakiegoś czasu chciałem przetestować pewien swój pomysł
na wersję 8-bitową tak żeby można było pod AGA wyświetlać szybko
i przy okazji sprawdzić czy byłby jakiś wzrost FPS.
Zrobiłem to w ten sposób:
1.
Jest jedna główna, statyczna paleta 256 kolorów [P].
Od jej zawartości zależy też jakość i efekt końcowy,
w tym przykładzie dałem 224 odcieni szarości i 32 odcienie niebieskości.
Docelowo oczywiście trzeba by dodać kilka dodatkowych innych odcieni więcej,
żeby nie było tak smutno.
2.
Celem jest utworzenie tablicy intensity_indexes[k]
gdzie i - to intensywność od 0-255, a k - to index to głownej palety P, też 0-255.
Kolory w palecie P odpowiadają kolorom oryginalnych tekstur czyli gdy jest największa intensywność == 255.
I np. jeżeli w oryginlnej palecie P (tj. intensywności = 255) mam kolor niebieski pod indexem 150 i potrzebuję go w wersji
o intensywności np. 100 czyli sporo ciemniejszej to dzięki tablicy mogę go znaleźć w taki sposób:
niebieski_i100 = intensity_indexes[100][150];
3.
Jak utworzyłem taką tablicę.
- najpierw zduplikowałem oryginalną paletę P w ilości 256 razy, gdzie dla 0 wszytskie koloryu są czarne a dla 255 są oryginalne jak juz pisałem.
- pozostałe palety w zakresie 1-254 zostały krok po kroku ściemnione
- teraz cała sztuka polega na tym żeby dla każdego koloru znaleść jego odpowiednik (jak najbliższy kolor) w głownej Palecie P
- tutaj można na rózne sposoby. ja zamieniełem dane kolory z RGB na CIELAB i obliczyłem deltę ( ta metoda chyba sie nazywa CIE73 czy jakoś ale są inne),
poniżej cały algorytm ktory znalezłem na stockoverflow:
https://stackoverflow.com/questions/1678457/best-algorithm-for-matching-colours/1678498?fbclid=IwAR0FGXiyL2aq3u3tY-KA6WaxGDfP601khvshAMha7a2qtG4XP-9Bz_eNanY#1678498
Efekty końcowe nienajgorsze...
jak powiedzialem dużo zależy od tego jak zostaną dopasowane kolory w Palecie,
ten algorytm CIE73 poradzil sobie nie najgorzej, ale pewnie recznie by sie przydalo pare poprawek porobić.
pod AGA na TV CRT nawet spoko wygląda, z użyciem C2P Kalmsa jest bardzo szybko i w pełni grywalne (V1200)
niestety przy Kalmsie chyba mi indeksy troche pomieszał wiec tylko spradzilem predkosć, przetestowałem też systemowy WriteChunkyPixel
tu kolory są dobre, ale jest oczywiscie troceh wolniej niż Kalms C2P.
W wersji RTG 8-bit miałem na V1200 38 fps a w wersji 32bit 42 fps xDDD czyli zamiast szybciej to wolniej hehe
Poniżej dodatki:
- wykorzystana paleta kolorów
- 8-bit na TV CRT z użyciem systemowej funkcji WriteChunkyPixels
- 8 bit na TV CRT i LCD z użyuciem c2p Kalmsa (kolorki zrypane, a raczej indeksy)
[i]Ostatnia aktualizacja: 13.10.2023 20:48:01 przez mateusz_s
14.01 16:19
[#410]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #409
czołem,
jakiś czas temu engine znów zaczal mnie nawiedzać nie dając spokoju.
Przyszły mi do glowy pewne optymalizacje ktore chciałem sprawdzic z ciekawości,
ale w miedzyczasie natknałem się na taki artykuł. Chodzi o to że Carmack zanim zrobił Dooma
za pomocą BSP stowrzył wolf3d na SNESa właśnie za pomocą BSP - bo standardowy Raycasting okazał się za wolny na tą platformę - a z BSP dał radę: https://retro-system.com/super.htm
polecam przeczytac
No i tez trochę zaczałem czytać bardziej o BSP, miałem na studiach, ale wtedy nie czaiłem tego za bardzo,
i dopiero teraz wiem z grubsza o co chodzi. No i pomyślałem, że skoro chcilem przestestować pewne optymalizacje to czemu by nie pojsc jeszcze dalej i sprawdzić renderowanie scianek za pomocą BSP niż raycastingu.. Musialem dopiero jakiś wykład jeszcz po angielsku obczić zeby
z grubsza pojąc jak to dzielić ico to daje :P
Póki co zaczlem przerabiać edytor i zanimilem mapę z klocków na ścianki. funkcja sprawdza"wypukłość" pomieszczeń a natępnie w razie konieczności dzieli je na dwa mniejsze aż uzyska pomieszczenia bez wypukłości. Mam już też utworzone drzewka binarne.
Jestem bardzo ciekawy jak zmieni się wydajność porównując rendering identycznych map za pomocą raycastingu i BSP.
Tu jest troceh wiecej roboty - na razie mam połowe zrobione czyli podział mapy i stworzenie drzewa
teraz trzeba się zająć samym renderingiem. Dzięki BSP bede dostawał kolejność scian do renerowania od najbliższej do najdlaszej - w porownanu dop raycastera w sten sposób uniknie się konieczności przechodzania przez siatkę dla każdego pixela w poziomie - rozdzielczosc pozioma bedzie wiec miala nieco mniejszy wplyw na wydajność.
o ile dobrze wszsytko ogarne i zaprogramuje - to piersszy raz gdy bawie sie BSP, wiec mam nadzieje ze nic nie sknocę..
Pytanie czy dam rade osiagnac faktycznie jakis sensowny przyrost wydajnosci czy nie, jak nie to pewnie wroce do raycastingu.
Jak cos bede miał to postaram sie wkleić wyniki :)
ps. na razie scianki i podzialy są proste poziome i pionowe - bo jak wspomnialem robie to dla testu
zeby po prostu zobaczyc co i jak..
ps. Może macie jakieś fajne źródła albo informaje, albo inne pomysly na optymalizacja np. podejscia do BSP?
wiec ze w Doom jeszcze są bounding boxy wokół pomieszczeń zeby szybciej je odrzucić.. dopiero bede zasiadał do drugiej czesci czy samego renderingu
no i tu duzo zalezy jak sie to wykona - jak szybko odrzucić scianki ktore nie są w polu widzenia itp..
Wykrywanie wklesłych / wypukłuch pomieszczeń:
Pogrupowane ścianki po podziale:
Podglad drzewek, zeby sprawdzic czy wszsytko gra i czy są "grubsza" zbalansowane
Ostatnia aktualizacja: 14.01.2024 16:25:40 przez mateusz_s
jakiś czas temu engine znów zaczal mnie nawiedzać nie dając spokoju.
Przyszły mi do glowy pewne optymalizacje ktore chciałem sprawdzic z ciekawości,
ale w miedzyczasie natknałem się na taki artykuł. Chodzi o to że Carmack zanim zrobił Dooma
za pomocą BSP stowrzył wolf3d na SNESa właśnie za pomocą BSP - bo standardowy Raycasting okazał się za wolny na tą platformę - a z BSP dał radę: https://retro-system.com/super.htm
polecam przeczytac
No i tez trochę zaczałem czytać bardziej o BSP, miałem na studiach, ale wtedy nie czaiłem tego za bardzo,
i dopiero teraz wiem z grubsza o co chodzi. No i pomyślałem, że skoro chcilem przestestować pewne optymalizacje to czemu by nie pojsc jeszcze dalej i sprawdzić renderowanie scianek za pomocą BSP niż raycastingu.. Musialem dopiero jakiś wykład jeszcz po angielsku obczić zeby
z grubsza pojąc jak to dzielić ico to daje :P
Póki co zaczlem przerabiać edytor i zanimilem mapę z klocków na ścianki. funkcja sprawdza"wypukłość" pomieszczeń a natępnie w razie konieczności dzieli je na dwa mniejsze aż uzyska pomieszczenia bez wypukłości. Mam już też utworzone drzewka binarne.
Jestem bardzo ciekawy jak zmieni się wydajność porównując rendering identycznych map za pomocą raycastingu i BSP.
Tu jest troceh wiecej roboty - na razie mam połowe zrobione czyli podział mapy i stworzenie drzewa
teraz trzeba się zająć samym renderingiem. Dzięki BSP bede dostawał kolejność scian do renerowania od najbliższej do najdlaszej - w porownanu dop raycastera w sten sposób uniknie się konieczności przechodzania przez siatkę dla każdego pixela w poziomie - rozdzielczosc pozioma bedzie wiec miala nieco mniejszy wplyw na wydajność.
o ile dobrze wszsytko ogarne i zaprogramuje - to piersszy raz gdy bawie sie BSP, wiec mam nadzieje ze nic nie sknocę..
Pytanie czy dam rade osiagnac faktycznie jakis sensowny przyrost wydajnosci czy nie, jak nie to pewnie wroce do raycastingu.
Jak cos bede miał to postaram sie wkleić wyniki :)
ps. na razie scianki i podzialy są proste poziome i pionowe - bo jak wspomnialem robie to dla testu
zeby po prostu zobaczyc co i jak..
ps. Może macie jakieś fajne źródła albo informaje, albo inne pomysly na optymalizacja np. podejscia do BSP?
wiec ze w Doom jeszcze są bounding boxy wokół pomieszczeń zeby szybciej je odrzucić.. dopiero bede zasiadał do drugiej czesci czy samego renderingu
no i tu duzo zalezy jak sie to wykona - jak szybko odrzucić scianki ktore nie są w polu widzenia itp..
Wykrywanie wklesłych / wypukłuch pomieszczeń:
Pogrupowane ścianki po podziale:
Podglad drzewek, zeby sprawdzic czy wszsytko gra i czy są "grubsza" zbalansowane
Ostatnia aktualizacja: 14.01.2024 16:25:40 przez mateusz_s
15.01 17:09
[#412]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #410
Na studiach uparłem się ze na zaliczenie z grafiki komputerowej (która na moim kierunku była delikatnie mówiąc - wciśnięta na sile) zrobię program renderujący mapy z Quake’a. I właśnie jak napisałeś o BSP to mi się przypomniało i nostalgia się załączyła.
Ale piszę o tym dlatego ze źródła quake’a tez są ciekawym źródłem wiedzy o renderowaniu świata 3D, nie wiem co wszyscy z tym Doomem. Doom był 2.5D bo nie dało się pomieszczenia nad pomieszczeniem zbudować bo był jeden floor i ceiling :)
Ale piszę o tym dlatego ze źródła quake’a tez są ciekawym źródłem wiedzy o renderowaniu świata 3D, nie wiem co wszyscy z tym Doomem. Doom był 2.5D bo nie dało się pomieszczenia nad pomieszczeniem zbudować bo był jeden floor i ceiling :)
01.02 10:55
[#418]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #417
No jestem lekko w szoku 
Zrobiłem TEST korzystając z tej samej mapy dla raycastera i BSP (w winuae i na V1200)
W rozdzielczości standardowej tj. 320x.. BSP jest ok. 100fps szybszy od raycastera
Natomiast w rozdzielczości 800x600, raycaster ok 33fps a BSP ok 43fps.
Więc dość mocny wynik. A moja implementacja BSP jest póki co od czapy i bez żadnych optymalizacji.
Więc zapowiada się to bardzo ciekawie. Dodam tylko że ściany mają tylko same kolory.
Ciekawostka:
Swoją implementację oparłem "tradycyjnie" o równania lini, punkty przecięć badanie po ktorej stronie lini jest punkt itp. oraz o "tradycyjne "rzutowanie" x/z. Więc jest sporo dzielenia tu i tam.
Natomiast w Doom używają tylko kątów do tego wszystkiego - dodatkowo zeby uzyskać rzut punktu na ekranie korzystają tez z kątów i tablicy z już przeliczonymi wartościami - więc moim zdaniem są to całkiem grube optymalizacje..
Dla zainteresowanych technikaliami Dooma, podrzucam fajny szczegółowy artykuł:
https://github.com/amroibrahim/DIYDoom?tab=readme-ov-file&fbclid=IwAR3vZya291CNpCIwkNR2oQIz1NhvBKLVEY826oKcrRdd6KsM-8jTYpysS1k
Zrobiłem TEST korzystając z tej samej mapy dla raycastera i BSP (w winuae i na V1200)
W rozdzielczości standardowej tj. 320x.. BSP jest ok. 100fps szybszy od raycastera
Natomiast w rozdzielczości 800x600, raycaster ok 33fps a BSP ok 43fps.
Więc dość mocny wynik. A moja implementacja BSP jest póki co od czapy i bez żadnych optymalizacji.
Więc zapowiada się to bardzo ciekawie. Dodam tylko że ściany mają tylko same kolory.
Ciekawostka:
Swoją implementację oparłem "tradycyjnie" o równania lini, punkty przecięć badanie po ktorej stronie lini jest punkt itp. oraz o "tradycyjne "rzutowanie" x/z. Więc jest sporo dzielenia tu i tam.
Natomiast w Doom używają tylko kątów do tego wszystkiego - dodatkowo zeby uzyskać rzut punktu na ekranie korzystają tez z kątów i tablicy z już przeliczonymi wartościami - więc moim zdaniem są to całkiem grube optymalizacje..
Dla zainteresowanych technikaliami Dooma, podrzucam fajny szczegółowy artykuł:
https://github.com/amroibrahim/DIYDoom?tab=readme-ov-file&fbclid=IwAR3vZya291CNpCIwkNR2oQIz1NhvBKLVEY826oKcrRdd6KsM-8jTYpysS1k