01.04.2021 12:27
[#152]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #151
Normalnie mam tylko 32 bity do wyboru w okienkowym, ale oczywiście jak przełączyłem Work... Ambienta na 16 bit to się daje. I nawet przez chwilę działa podnoszenie/opuszczanie głowy. Ale jest innego rodzaju problem - tekstury na ścianach wyglądają cokolwiek przerażająco:
EDIT: Wrróć, na 32 bitach też w ograniczonym stopniu działa podnoszenie/opuszczanie głowy. Ale po chwili wszystko wraca do "normy" - za którymś z kolei ukłonem, albo zbyt gwałtownym ruchu myszą znikają ściany.
Ostatnia aktualizacja: 01.04.2021 12:30:48 przez recedent
EDIT: Wrróć, na 32 bitach też w ograniczonym stopniu działa podnoszenie/opuszczanie głowy. Ale po chwili wszystko wraca do "normy" - za którymś z kolei ukłonem, albo zbyt gwałtownym ruchu myszą znikają ściany.
Ostatnia aktualizacja: 01.04.2021 12:30:48 przez recedent
01.04.2021 15:20
[#155]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #154
Te szare kolory i częściowe powtarzanie się obrazu po prawej stronie są od samego początku przy trybie 16 bit. Jeśli przesadzę z ruszaniem głową (albo po prostu losowo po ruchu głową) znikają ściany i zostaje tylko szary ekran podzielony na dwie części - jasnoszarą u góry i lekko ciemniejszą na dole (z pamięci piszę, bo jestem poza domem aktualnie).
Co do FPSów - łatwo jest "podbić" sobie wynik stojąc sobie w miejscu daleko od ścian. Dlatego nie chcę tu z nikim iść na wojnę benchmarkową... póki nie pojawi się obiektywny test :D
Co do FPSów - łatwo jest "podbić" sobie wynik stojąc sobie w miejscu daleko od ścian. Dlatego nie chcę tu z nikim iść na wojnę benchmarkową... póki nie pojawi się obiektywny test :D
01.04.2021 16:22
[#156]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@recedent, post #155
spoko, dzięki..
tryb okienkowy 16 bit jest skopany ogólnie - bo w cgx nie ma takiego formatu dla okienka nie wiedzieć czemu,
pojawia się w cgx ale wersji na Arosa, ale to na potem..
te znikające ściany mnie ciekawią, tył który zostaje to cieniowany sufit i podłoga..
w morphosie jest CGX czy P96?
tryb okienkowy 16 bit jest skopany ogólnie - bo w cgx nie ma takiego formatu dla okienka nie wiedzieć czemu,
pojawia się w cgx ale wersji na Arosa, ale to na potem..
te znikające ściany mnie ciekawią, tył który zostaje to cieniowany sufit i podłoga..
w morphosie jest CGX czy P96?
01.04.2021 21:44
[#158]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #156
Odpaliłem z ciekawości na CybervisionPPC.
Programik cokolwiek pokazuje tylko w trybie okienkowym, w fullscreen widać tylko jasnoszary ekran. Ale jak pokazuje w okienku, to jakoś krzywo - dziury w ścianach, dziwne kolory itp. No ale to nie system docelowy więc sukces, że się odpaliło.
W 320x240x16 pokazuje 15fps, jeszcze 400x300 jest znośnie, a w wyższych jest już slideshow.
Programik cokolwiek pokazuje tylko w trybie okienkowym, w fullscreen widać tylko jasnoszary ekran. Ale jak pokazuje w okienku, to jakoś krzywo - dziury w ścianach, dziwne kolory itp. No ale to nie system docelowy więc sukces, że się odpaliło.
W 320x240x16 pokazuje 15fps, jeszcze 400x300 jest znośnie, a w wyższych jest już slideshow.
02.04.2021 02:29
[#160]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@pisklak, post #159
To trzeba w screen prefs sobie zmienić np. na 24, lub 32 bity,
bo okienko jest takie same jak WB, cgx nie miał tego formatu dla 16 bit dziwne,
wiec jest kaszana na razie..
ale trzeba się skupić na razie na jednym trybie, i robić optymalizacje algorytmów..
teraz jedyne co mi pozostało jeśli chodzi o ściany to liczenie co drugi promień zarówno w poziomie i w pionie,
przy czym nie dubluje pixeli a daje na razie o jeden pixel z textury dalej, robi sie jakby efekt rozproszenia,
ale daje bardzo duzego kopa... dodatkowo można ciekawe efekty uzyskać, jakby nałożenia siatki na całość
które nawet nieco niweluje pixeloze (cos jak scanline ale w kratke).. ale pewnie mozna to to nieco porawic, utrata jakosci niewielka, za to duzy przyrost FPS wiec warto, np. jak podejdziemy bardzo blisko textury
to widac jakby ich roztrzęsienie lub rodzaj "kratki".. ale to moze być nawet zaleta..
wieć tym sie zajme po Świętach..
podłoga nadal.. leży
ale też nie do końca, zastąpienie dodawania ułamków typu float na fixed point (czyli coś co zrobiłem tez przy ścianach) wywaliło fps z 5 do 30fps..
ale mam wtedy problem z dokładnością fixed pointów, bo są małe wartośći kroków np. 0.0003 wiec trzeba mnozyc przez duze wartosci co powoduje koniecznosc
siegania po long long, a wtedy jest kaszana i nie ma to sensu, wiec moze poprawa algorytmu alba jakies funkcje do fixed jeszcze nie wiem - no i tam tez chyba dodam co drugi promień.. także.. może wyjść
jakaś fajna kompozycja z tego zobaczymy, w przypadku Vampów może być możliwe płynna grywalność
w 640x480 patrząc po obecnych wynikach
na razie to chyba szkoda czasu na zabawę z innymi trybami, lepiej sie na jednym skupić i dopracować algorytm
jakby coś fajnego zaczęło wychodzić to można by potem spróbować i z 8bit..
w każdym razie.. jeszcze się kręci wszystko..
Ostatnia aktualizacja: 02.04.2021 02:32:50 przez mateusz_s
bo okienko jest takie same jak WB, cgx nie miał tego formatu dla 16 bit dziwne,
wiec jest kaszana na razie..
ale trzeba się skupić na razie na jednym trybie, i robić optymalizacje algorytmów..
teraz jedyne co mi pozostało jeśli chodzi o ściany to liczenie co drugi promień zarówno w poziomie i w pionie,
przy czym nie dubluje pixeli a daje na razie o jeden pixel z textury dalej, robi sie jakby efekt rozproszenia,
ale daje bardzo duzego kopa... dodatkowo można ciekawe efekty uzyskać, jakby nałożenia siatki na całość
które nawet nieco niweluje pixeloze (cos jak scanline ale w kratke).. ale pewnie mozna to to nieco porawic, utrata jakosci niewielka, za to duzy przyrost FPS wiec warto, np. jak podejdziemy bardzo blisko textury
to widac jakby ich roztrzęsienie lub rodzaj "kratki".. ale to moze być nawet zaleta..
wieć tym sie zajme po Świętach..
podłoga nadal.. leży
ale też nie do końca, zastąpienie dodawania ułamków typu float na fixed point (czyli coś co zrobiłem tez przy ścianach) wywaliło fps z 5 do 30fps..
ale mam wtedy problem z dokładnością fixed pointów, bo są małe wartośći kroków np. 0.0003 wiec trzeba mnozyc przez duze wartosci co powoduje koniecznosc
siegania po long long, a wtedy jest kaszana i nie ma to sensu, wiec moze poprawa algorytmu alba jakies funkcje do fixed jeszcze nie wiem - no i tam tez chyba dodam co drugi promień.. także.. może wyjść
jakaś fajna kompozycja z tego zobaczymy, w przypadku Vampów może być możliwe płynna grywalność
w 640x480 patrząc po obecnych wynikach
na razie to chyba szkoda czasu na zabawę z innymi trybami, lepiej sie na jednym skupić i dopracować algorytm
jakby coś fajnego zaczęło wychodzić to można by potem spróbować i z 8bit..
w każdym razie.. jeszcze się kręci wszystko..
Ostatnia aktualizacja: 02.04.2021 02:32:50 przez mateusz_s
02.04.2021 08:32
[#161]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #160
Zdajesz sobie sprawę, że krok 0.0003 oznacza, że potrzeba ponad 3 tysięcy kroków żeby przejść jeden piksel? Robisz coś źle. 32bit w zupełności wystarczą do liczenia teksturowania w fixedpoint, i to nawet z dokładnością 16:16, co oznacza, że potrzeba 64k pikseli na przejście jednego teksela...
02.04.2021 08:58
[#162]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@kiero, post #161
Ilość iteracji jest stała, te małe kroki występują najbliżej
Tam gdzie textura jest najbardziej rozciągnięta.
Rozważam ten zastąpienie tego algorytmu algorytmem mode7, w teorii jest wystarczający, ale nie wiem mozna go zastosowac jeśli moja podłoga składa się z różnych bitmap. Przykłady ktore widzialem manipulowały jedną texturą.. robilem nawet pierwsze podejscie, było nienajgorzej
Tam gdzie textura jest najbardziej rozciągnięta.
Rozważam ten zastąpienie tego algorytmu algorytmem mode7, w teorii jest wystarczający, ale nie wiem mozna go zastosowac jeśli moja podłoga składa się z różnych bitmap. Przykłady ktore widzialem manipulowały jedną texturą.. robilem nawet pierwsze podejscie, było nienajgorzej
02.04.2021 09:15
[#163]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #162
Ilość iteracji czy jest stała czy nie nie ma znaczenia. 0.0003 oznacza że musisz wykonać ponad 3333 iteracji (przejść np 3000 pikseli w poziomie) żeby przeskoczyć jeden teksel tekstury. Oznacza to, że JEDEN teksel musiałby być rozciągnięty na cały ekran w rozdzielczości 4k. Przy podłodze, gdzie zakres UV jest większy, używanie formatu 24:8 w zupełności powinno wystarczyć.
Nie wiem co w tym kontekście oznacza 'zastąpienie tego algorytmem mode7'. Tu masz jedynie 2 dodawania na piksel + sprowadzenie tego do normalnej postaci (2 przesunięcia) + obliczenie adresu...
Ostatnia aktualizacja: 02.04.2021 09:17:42 przez kiero
Ostatnia aktualizacja: 02.04.2021 09:17:51 przez kiero
Nie wiem co w tym kontekście oznacza 'zastąpienie tego algorytmem mode7'. Tu masz jedynie 2 dodawania na piksel + sprowadzenie tego do normalnej postaci (2 przesunięcia) + obliczenie adresu...
Ostatnia aktualizacja: 02.04.2021 09:17:42 przez kiero
Ostatnia aktualizacja: 02.04.2021 09:17:51 przez kiero
02.04.2021 09:45
[#164]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@kiero, post #163
Chodzi o probe zastąpienia obecnego algorytmu podłogi
Mode7 w sensie ogólnym jako wydajniejszego byc moze.
Obecny musze jakoś zmodyfikować żeby lepiej wykorzystać fixed point.
Obecnie liczę dwa skrajne promienie na linię, które przecinają podłogę. Do tego dystans od kamery. Mając te rzeczywiste punkty mapuje je na ekran poprzez interpolację oparta o dodawanie kroczków x i y, które mają właśnie różną dokładność.
Mode7 w sensie ogólnym jako wydajniejszego byc moze.
Obecny musze jakoś zmodyfikować żeby lepiej wykorzystać fixed point.
Obecnie liczę dwa skrajne promienie na linię, które przecinają podłogę. Do tego dystans od kamery. Mając te rzeczywiste punkty mapuje je na ekran poprzez interpolację oparta o dodawanie kroczków x i y, które mają właśnie różną dokładność.
02.04.2021 10:34
[#165]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #164
I obecnie robisz to dobrze:) Mając UV po lewej i prawej stronie (na tą chwilę ignorujemy ściany) robisz po prostu liniową interpolację która sprowadza się do operacji które opisałem wyżej. Zakres wartość niejako wynika z tego, że wynikiem jest zniekształcona tekstura, czyli w przybliżeniu na piksel ekranowy przypada pewnie or 100 (zmniejszenie, daleko od kamery, tutaj przydadzą się mipmapy) do 0.01 tekseli (ekstremalne powiększenie, blisko kamery). Nie trudno wyliczyć jaka jest do tego potrzebna dokładność i dlaczego 16 (8 które podałem wyżej jest błędne, i jest zbyt mało dokładne) bitów na część ułamkową powinno wystarczyć. Krok o wartości 0.0003 dla U lub V wystąpi w przypadku kiedy U lub V po obu stronach są praktycznie identyczne -> nie ma to znaczenia. Jeżeli U i V różnią się o jeden teksel to przy dokładności 16bit krok będzie miał wartość aż 65536/szerokosc_ekranu.
Oczywiście chcesz mieć dokładność UV większą niż tylko teksel/piksel, więc zjada to nieco z dokładności kroku, ale i tak będzie wystarczająco dokładne.
Oczywiście chcesz mieć dokładność UV większą niż tylko teksel/piksel, więc zjada to nieco z dokładności kroku, ale i tak będzie wystarczająco dokładne.
12.04.2021 00:36
[#172]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #171
Robiłem parę testów, żeby znaleźć jakiś kompromis między ilością wrzucanych pixeli do bufora, a wydajnością,
na razie jeszcze próbuje wycisnąć ze ścian jak najwięcej..
test na winuae, próbowałem zbliżyć wydajność do wyników Vampira i po prostu trzymam się cały czas tych ustawień, więc FPSy tylko referencyjnie
Obrazek trzeba powiększyć do 100% żeby jakieś różnice zobaczyć, obecnie najlepszy kompromis mam
z przedostania metodą, utrata jakości niewielka, a parę fps więcej.
na razie jeszcze próbuje wycisnąć ze ścian jak najwięcej..
test na winuae, próbowałem zbliżyć wydajność do wyników Vampira i po prostu trzymam się cały czas tych ustawień, więc FPSy tylko referencyjnie
Obrazek trzeba powiększyć do 100% żeby jakieś różnice zobaczyć, obecnie najlepszy kompromis mam
z przedostania metodą, utrata jakości niewielka, a parę fps więcej.
15.04.2021 21:44
[#173]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #1
Czołem!
***********************
UPDATE - PODSUMOWANKO
***********************
1. Pierwszy post zaktualizowany o nowe rzeczy: filmik, download źródel, exeka i nowe materiały -- [1]--
2. Najnowszy filmik z trochę bardziej konkretnymi tekturami.
Pixele 1:1, 320x240x32, 640x480x32, co prawda na winuae ale prędkość mniej więcej dostosowana do V2, V4.
Na prawdziwych V2 i V4 jest trochę szybciej:
- w 320x240x32 wychodzi jakies 15-18 fps - nawet płynnie
- w 640x480 już ok 4-5fps
- ale prawda jest taka, że to nie sa limity Vampira tylko moje :) w 320x240x32 powinno być na spokojnie 40-50fps
a w 640x480 moze i ze 20, a wykorzystujac AMMX pewnie i wiecej.
- jednak to chyba max co mogę wydusić w tym momencie - nie znam asm wiec tego nie zoptymalizuje.
3. Jeśli chodzi o rózne optymalizacje to tak:
- same ściany z texturami i shadingiem miałem bardzo szybko na Vampirach ponad 60fps, dodatkowe fpsy zyskiwałem trochę kombinując z co drugim rzędem kub kolumną, ale w końcu zostawiłem 1:1
- gorzej się zrobiło gdy doszły podłogi i sufity - pomimo grubej optymalizacji to razem ze ścianami wyszło jak wyszło.
Niestety tu nie można zrobić takich dobrych optymalizacji jak przy ścianach które mają swoją specyfikę. Tu też kombinowałem z co drugim rzędem i kolumną - wychodził wtedy efekt "led" ale było całkiem szybko. Próbowałem wypełnić puste przestrzenie poprzez interpolacje ale efekt był bardzo rozmyty i słabo to wyglądało.. zostawiłem finalnie 1:1
4. Jakie wnioski?
- jedyne co byłbym w w stanie teraz zrobić to silnik typu "bardziej wypasiony wold3f", tzn. bez tektur na suficie i podłogach, ale pewnie z cieniowaniem, przy 640x400x32 powinno być z 15 myślę..
- lub zdropować do 8 bitów to co jest (lub do 16). Gdyby jakimś cudem zrobić dithering przy wersji 8 bit była by ładna stylizacja, a przy 640x400 nie sprawiało by to róznicy i byłby ładny efekt.. ale nie wiem czy mozna taki efekt w realtime osiagnac..
- na pewno Vampire daje spoko możliwości, znacznie większe niż mi się udało osiągnąć w moich bojach - ja ogólnie jak na pierwszy podejście do tego tematu tj. RTG i systemowe programowanie Amigowe to jestem zadowolony z efektów..
- Warpy 1260 na razie wypadają ok 2-3razy wolniej od Vampirów, ale ponoć RTG nie jest tam jeszcze zoptymalizowane
- bez optymalizacji asm to chyba jest ściana.. ps. w w pierwszym poście sa źródła i pętla renderująca, jeśli Ktoś chce się pobawić w optymalizację albo zerknać co i jak..
- ponoć ma się pojawić Bebbo GCC 6.5 z Vampirowymi funkcjami AMMX
- pół roku temu zamówiłem książkę z kursem ASM od podstaw.. ale nie nigdy przyszła..
***********************
UPDATE - PODSUMOWANKO
***********************
1. Pierwszy post zaktualizowany o nowe rzeczy: filmik, download źródel, exeka i nowe materiały -- [1]--
2. Najnowszy filmik z trochę bardziej konkretnymi tekturami.
Pixele 1:1, 320x240x32, 640x480x32, co prawda na winuae ale prędkość mniej więcej dostosowana do V2, V4.
Na prawdziwych V2 i V4 jest trochę szybciej:
- w 320x240x32 wychodzi jakies 15-18 fps - nawet płynnie
- w 640x480 już ok 4-5fps
- ale prawda jest taka, że to nie sa limity Vampira tylko moje :) w 320x240x32 powinno być na spokojnie 40-50fps
a w 640x480 moze i ze 20, a wykorzystujac AMMX pewnie i wiecej.
- jednak to chyba max co mogę wydusić w tym momencie - nie znam asm wiec tego nie zoptymalizuje.
3. Jeśli chodzi o rózne optymalizacje to tak:
- same ściany z texturami i shadingiem miałem bardzo szybko na Vampirach ponad 60fps, dodatkowe fpsy zyskiwałem trochę kombinując z co drugim rzędem kub kolumną, ale w końcu zostawiłem 1:1
- gorzej się zrobiło gdy doszły podłogi i sufity - pomimo grubej optymalizacji to razem ze ścianami wyszło jak wyszło.
Niestety tu nie można zrobić takich dobrych optymalizacji jak przy ścianach które mają swoją specyfikę. Tu też kombinowałem z co drugim rzędem i kolumną - wychodził wtedy efekt "led" ale było całkiem szybko. Próbowałem wypełnić puste przestrzenie poprzez interpolacje ale efekt był bardzo rozmyty i słabo to wyglądało.. zostawiłem finalnie 1:1
4. Jakie wnioski?
- jedyne co byłbym w w stanie teraz zrobić to silnik typu "bardziej wypasiony wold3f", tzn. bez tektur na suficie i podłogach, ale pewnie z cieniowaniem, przy 640x400x32 powinno być z 15 myślę..
- lub zdropować do 8 bitów to co jest (lub do 16). Gdyby jakimś cudem zrobić dithering przy wersji 8 bit była by ładna stylizacja, a przy 640x400 nie sprawiało by to róznicy i byłby ładny efekt.. ale nie wiem czy mozna taki efekt w realtime osiagnac..
- na pewno Vampire daje spoko możliwości, znacznie większe niż mi się udało osiągnąć w moich bojach - ja ogólnie jak na pierwszy podejście do tego tematu tj. RTG i systemowe programowanie Amigowe to jestem zadowolony z efektów..
- Warpy 1260 na razie wypadają ok 2-3razy wolniej od Vampirów, ale ponoć RTG nie jest tam jeszcze zoptymalizowane
- bez optymalizacji asm to chyba jest ściana.. ps. w w pierwszym poście sa źródła i pętla renderująca, jeśli Ktoś chce się pobawić w optymalizację albo zerknać co i jak..
- ponoć ma się pojawić Bebbo GCC 6.5 z Vampirowymi funkcjami AMMX
- pół roku temu zamówiłem książkę z kursem ASM od podstaw.. ale nie nigdy przyszła..
15.04.2021 22:09
[#174]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #173
ps.
Dodałem do ściągnięcia źródła.
Jeśli Ktoś się interesuje programowaniem RTG to polecam.
Napisałem też własny Launcher w którym mamy własny requester trybów wyświetlania, który możemy dowolnie filtrować i formatować z możliwością wyświetlenia dostępnych trybów w fullscreen lub okienku.
Można skorzystać, poprawić lub się czegoś nauczyć
Dodałem do ściągnięcia źródła.
Jeśli Ktoś się interesuje programowaniem RTG to polecam.
Napisałem też własny Launcher w którym mamy własny requester trybów wyświetlania, który możemy dowolnie filtrować i formatować z możliwością wyświetlenia dostępnych trybów w fullscreen lub okienku.
Można skorzystać, poprawić lub się czegoś nauczyć
15.04.2021 23:17
[#176]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@pisklak, post #175
Dzięki,
Znając siebie to pewnie za niedługo znowu zacznę coś kombinować, ale chyba warto to na razie odstawić żeby się odleżało i spojrzeć potem od nowa. A w między czasie troche się dokształcić i doczytać to i owo.
Poza tym co noc śnią mi się pixele i promienie musze przystopować na chwile
Znając siebie to pewnie za niedługo znowu zacznę coś kombinować, ale chyba warto to na razie odstawić żeby się odleżało i spojrzeć potem od nowa. A w między czasie troche się dokształcić i doczytać to i owo.
Poza tym co noc śnią mi się pixele i promienie musze przystopować na chwile
17.04.2021 16:23
[#177]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #173
******
DODATKOWE TESTY i MATERIAŁY
******
1. dodałem do 1 postu jeszcze kilka ciekawych materiałów
2. chciałem zobaczyć jaki efekt przyniesie próba ditheringu całego obrazka w realtime..
W poniższym filmiku pokazuje różnicę między kwantyzacją kolorów z true color do 256 kolorów
a potem dithering metodą Floyda-Stainberga, sam algorytm jest dość prosty,
ale nie wiem czy jest do uciągnięcia w realtime na przyzwoitym poziomie: https://en.wikipedia.org/wiki/Floyd%E2%80%93Steinberg_dithering
Generalnie dithering z gotowego true color do 256 jest troche bez sensu, bo nie dość że tracimy wydajnosć pracując na 24 lub 32 bitach to jeszcze musimy zrobić wiele operacji per-pixel żeby to utracić na rzecz takiego stylizowanego renderingu. Plus jest taki, że gdyby to wszystko było bardzo optymalne i szybkie - to właśnie można uzyskać fajny retro efekt, a w wyższej rozdziale prawie nie widoczny a dający paletę 256 kolorów... no ale taka sztuka dla sztuki, byłem ciekawy jak to wyjdzie..
DODATKOWE TESTY i MATERIAŁY
******
1. dodałem do 1 postu jeszcze kilka ciekawych materiałów
2. chciałem zobaczyć jaki efekt przyniesie próba ditheringu całego obrazka w realtime..
W poniższym filmiku pokazuje różnicę między kwantyzacją kolorów z true color do 256 kolorów
a potem dithering metodą Floyda-Stainberga, sam algorytm jest dość prosty,
ale nie wiem czy jest do uciągnięcia w realtime na przyzwoitym poziomie: https://en.wikipedia.org/wiki/Floyd%E2%80%93Steinberg_dithering
Generalnie dithering z gotowego true color do 256 jest troche bez sensu, bo nie dość że tracimy wydajnosć pracując na 24 lub 32 bitach to jeszcze musimy zrobić wiele operacji per-pixel żeby to utracić na rzecz takiego stylizowanego renderingu. Plus jest taki, że gdyby to wszystko było bardzo optymalne i szybkie - to właśnie można uzyskać fajny retro efekt, a w wyższej rozdziale prawie nie widoczny a dający paletę 256 kolorów... no ale taka sztuka dla sztuki, byłem ciekawy jak to wyjdzie..
17.04.2021 19:10
[#178]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #177
Zrób to tak jak w Quake. Renderujesz teksturę 8-bit i masz do niej 8-bit jasność. W tablicy LUT 256*256 masz numer koloru z palety który najbardziej pasuje dla danego indeksu palety i docelowej jasności. Jeśli zrobisz paletę o ograniczonej liczbie barw ale za to z dużą liczbą poziomów jasności dla danej barwy to efekt będzie dużo lepszy niż jakieś kwantyzacje i szybszy niż rendering w 32 bitach.
20.04.2021 13:29
[#180]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #179
Nie wiem czy ci się to wpasuje w twój engine, ale na PhilipsCDI zrobili fajny motyw:
https://cdii.blogspot.com/2021/04/in-end-wolfenstein-3d-ran-too-slow-on.html
generują dolną połowę sciany sciany, a górę tylko kopiują. Oczywiście pasuje to tylko dla tekstur powtarzalnych i nie na całą scianę, ale pewnie mogloby dac duze przyspieszenie.
https://cdii.blogspot.com/2021/04/in-end-wolfenstein-3d-ran-too-slow-on.html
generują dolną połowę sciany sciany, a górę tylko kopiują. Oczywiście pasuje to tylko dla tekstur powtarzalnych i nie na całą scianę, ale pewnie mogloby dac duze przyspieszenie.