15.03.2021 13:03
[#61]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@Kefir_Union, post #59
@Kefir
Oczywiście, ale patrzę przez pryzmat poziomu wiedzy autora;)
@mateusz
Ehh, to takie oczywiste że kompilator to powinien zrobić a nie ty. Kompilatory robią to od lat o ile im nie utrudniasz życia. Jest to dokładnie ten sam przypadek jak w temacie o longach i intach (tam z jakiegoś powodu utrudnieniem była zmienna globalna określonego typu, ale widziałem że nikt nie chciał wnikać w temat). Moim zdaniem powinieneś zdobyć choćby minimalną umiejętność czytania (nie pisania) asemblera żeby ocenić 'na oko' czy kompilator zrobił dobrą robotę.
Oczywiście, ale patrzę przez pryzmat poziomu wiedzy autora;)
@mateusz
Ehh, to takie oczywiste że kompilator to powinien zrobić a nie ty. Kompilatory robią to od lat o ile im nie utrudniasz życia. Jest to dokładnie ten sam przypadek jak w temacie o longach i intach (tam z jakiegoś powodu utrudnieniem była zmienna globalna określonego typu, ale widziałem że nikt nie chciał wnikać w temat). Moim zdaniem powinieneś zdobyć choćby minimalną umiejętność czytania (nie pisania) asemblera żeby ocenić 'na oko' czy kompilator zrobił dobrą robotę.
15.03.2021 13:06
[#62]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@kiero, post #56
@kiero,
tzn. to jest cel tego ekperymentu, wydusić trochę z RTG, z Vampirzów i Warpów, ale Ludzie mają też inne szybsze procki PPC itp. I gdzie tego nie odpalą to mają po pare fps :)
np. RTG vampira nie ma problemu z pełnoekranowym rysowaniem 640x400x24 w 90 fps + filtrowaniem tekstur,
fakt Gunnar zrobił to demo w asm, ale to dowodzi że przepustowość jest OK..
wyświetlanie 32bit mi nie potrzebne, ale 24 wyświetla wolniej niż 32. Nie chcę się bawić w 256 kolorów - to już było :) chodzi o sprawdzenie nowych zabawek.
nie do końca tak jest z tymi 3x więcej obliczeń, tak czy owak muszę obliczam punkt przeciecia prostej z gridem,
na tej podstawie otrzymuje wspołrzede X textela w texturze, czyli defakto jego pozycje w tablicy, różnica jest taka że jeśli textura bedzie indeksowana to tablica bedzie typu BYTE a jeśli nie to INT, wiec zeżre wiecej pamięci i cache, pamięci jest pod dostatkiem, problem to ewentualnei cache.. ale z drugiej strony jak zmieniałem rozmiar textury z 128 na 64 to też różnicy nie było.. co ciekawe rozmiar textury 256,128 czy 64 praktycznie nie wpływa na złożoność obliczeń
no nie umiem w asemblera,
finalnie chciałem zrobić wstawki w kodzie w kluczowych miejsach celem optymalziacji
ale to jakbym miał sensowny wynik z 25 fps chociaż w C..
na razie zamienię te tekstury na 8bit może coś to pomoże..
tzn. to jest cel tego ekperymentu, wydusić trochę z RTG, z Vampirzów i Warpów, ale Ludzie mają też inne szybsze procki PPC itp. I gdzie tego nie odpalą to mają po pare fps :)
np. RTG vampira nie ma problemu z pełnoekranowym rysowaniem 640x400x24 w 90 fps + filtrowaniem tekstur,
fakt Gunnar zrobił to demo w asm, ale to dowodzi że przepustowość jest OK..
wyświetlanie 32bit mi nie potrzebne, ale 24 wyświetla wolniej niż 32. Nie chcę się bawić w 256 kolorów - to już było :) chodzi o sprawdzenie nowych zabawek.
nie do końca tak jest z tymi 3x więcej obliczeń, tak czy owak muszę obliczam punkt przeciecia prostej z gridem,
na tej podstawie otrzymuje wspołrzede X textela w texturze, czyli defakto jego pozycje w tablicy, różnica jest taka że jeśli textura bedzie indeksowana to tablica bedzie typu BYTE a jeśli nie to INT, wiec zeżre wiecej pamięci i cache, pamięci jest pod dostatkiem, problem to ewentualnei cache.. ale z drugiej strony jak zmieniałem rozmiar textury z 128 na 64 to też różnicy nie było.. co ciekawe rozmiar textury 256,128 czy 64 praktycznie nie wpływa na złożoność obliczeń
no nie umiem w asemblera,
finalnie chciałem zrobić wstawki w kodzie w kluczowych miejsach celem optymalziacji
ale to jakbym miał sensowny wynik z 25 fps chociaż w C..
na razie zamienię te tekstury na 8bit może coś to pomoże..
15.03.2021 13:25
[#63]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #62
Żebyś się nie zdziwił przy warpie. To tylko 060. Imo zapomnij o czymkolwiek poza 320x256 w takim przypadku. Ale ok, jeżeli w to celujesz to inna sprawa.
[Edit: Ok, może nieco przesadziłem. To tylko wolf + podłogi/sufity. Warp powinien pociągnąć. Jednak proponuję zwrócić uwagę że Quake1/2 chodzą w 8bitach]
Co do ilości obliczeń to serio, nie musisz mi pisać co i jak:) Widzę od razu że liczysz koszt nie tam gdzie się on znajduje:
- przy ścianach liczenie przecięcia robisz raz na kolumnę. Potem w kolumnie przy rysowaniu jedyne co robisz to dodawanie + przesunięcie dla adresu teksela (zmienia się tylko y, wartość fixedpoint). Reszta to liczenie koloru które kosztować cię będzie na oko 3x tyle co w przypadku 8bit + tablicy (mnożenie na 060 to 2 nieparowalne cykle procesora)
- przy podłodze liczenie pozycji teksela to 2 * (dodawanie + shift) + złożenie w adres. Reszta to liczenie koloru. Znowu spokojnie x3.
Oba przypadki dla kodu w C i 'na oko'. Przy asmie można użyć addx ale to tylko jeszcze bardziej przenosi koszt na liczenie koloru + składanie w 32bitowe słowo. Jeżeli robisz w swoim kodzie do interpolacji dla kolumn/wierszy coś więcej niż dodawania i przesunięcia bitowe na liczbach całkowitych to robisz to źle i szukasz optymalizacji nie tam gdzie trzeba.
Ostatnia aktualizacja: 15.03.2021 13:30:50 przez kiero
Ostatnia aktualizacja: 15.03.2021 13:31:48 przez kiero
[Edit: Ok, może nieco przesadziłem. To tylko wolf + podłogi/sufity. Warp powinien pociągnąć. Jednak proponuję zwrócić uwagę że Quake1/2 chodzą w 8bitach]
Co do ilości obliczeń to serio, nie musisz mi pisać co i jak:) Widzę od razu że liczysz koszt nie tam gdzie się on znajduje:
- przy ścianach liczenie przecięcia robisz raz na kolumnę. Potem w kolumnie przy rysowaniu jedyne co robisz to dodawanie + przesunięcie dla adresu teksela (zmienia się tylko y, wartość fixedpoint). Reszta to liczenie koloru które kosztować cię będzie na oko 3x tyle co w przypadku 8bit + tablicy (mnożenie na 060 to 2 nieparowalne cykle procesora)
- przy podłodze liczenie pozycji teksela to 2 * (dodawanie + shift) + złożenie w adres. Reszta to liczenie koloru. Znowu spokojnie x3.
Oba przypadki dla kodu w C i 'na oko'. Przy asmie można użyć addx ale to tylko jeszcze bardziej przenosi koszt na liczenie koloru + składanie w 32bitowe słowo. Jeżeli robisz w swoim kodzie do interpolacji dla kolumn/wierszy coś więcej niż dodawania i przesunięcia bitowe na liczbach całkowitych to robisz to źle i szukasz optymalizacji nie tam gdzie trzeba.
Ostatnia aktualizacja: 15.03.2021 13:30:50 przez kiero
Ostatnia aktualizacja: 15.03.2021 13:31:48 przez kiero
15.03.2021 13:37
[#64]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@kiero, post #63
@kiero
Dzięki za info.. no nic zobaczymy na razie tak..
Jak uda się zyskać bardziej przyzwoite fpsy w C, to dopiero bym pomyślał o asm..
Nie wiem za bardzo jak generować grafikę mając do dyspozycji np. zafiksowaną paletę 8bit,
czy nie trzeba wtedy szukać przez całą tablicę najbardziej pasującego koloru?
Teoretycznie też to jakoś tam rozważałem, ale color banding mnie wkurza ;p
co innego gdyby dało się zrobić dithering, bo efekt jest wtedy super i braki koloró się kompoensują,
ale dithering jest chyba za drogi żęby go robić w realtime..
Dzięki za info.. no nic zobaczymy na razie tak..
Jak uda się zyskać bardziej przyzwoite fpsy w C, to dopiero bym pomyślał o asm..
Nie wiem za bardzo jak generować grafikę mając do dyspozycji np. zafiksowaną paletę 8bit,
czy nie trzeba wtedy szukać przez całą tablicę najbardziej pasującego koloru?
Teoretycznie też to jakoś tam rozważałem, ale color banding mnie wkurza ;p
co innego gdyby dało się zrobić dithering, bo efekt jest wtedy super i braki koloró się kompoensują,
ale dithering jest chyba za drogi żęby go robić w realtime..
15.03.2021 13:48
[wyróżniony]
[#65]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #64
Ktoś ci chyba już opisywał jak zrobić wersję z paletą. Wszystkie odcienie liczysz sobie wcześniej i zapisujesz w tablicy tak:
uint8 tablica[256 * (1 << ile_bitow_dla_odcieni)];
tablica[(odcien << 8) | kolor] = wyszukaj_odcien_dla_koloru(kolor, odcien);
potem przy renderowaniu:
kolor_z_odcieniem = tablica[kolor | (odcien << 8)];
co dla ścian i cieniowania 'w głąb' uprawsza się do:
[po wyliczeniu odcienia ale przez petlą]
uint8* tablica_kolorow_dla_odcienia = tablica + (odcien << 8);
[w samej pętli]
kolor_z_odcieniem = tablica_kolorow_dla_odcienia[kolor];
i tyle. Cała kwestia to policzenie palety dla wszystkich używanych tekstur i ich odcieni przed renderingiem. Można napisać sobie jakiś prosty program który zbierze wszystkie tekstury do kupy, doda do tego potrzebne odcienie, zredukuje to do 256 wartości, zremapuje tekstury do nowej palety i jak trzeba wygeneruje od razu tablice cieniowania.
uint8 tablica[256 * (1 << ile_bitow_dla_odcieni)];
tablica[(odcien << 8) | kolor] = wyszukaj_odcien_dla_koloru(kolor, odcien);
potem przy renderowaniu:
kolor_z_odcieniem = tablica[kolor | (odcien << 8)];
co dla ścian i cieniowania 'w głąb' uprawsza się do:
[po wyliczeniu odcienia ale przez petlą]
uint8* tablica_kolorow_dla_odcienia = tablica + (odcien << 8);
[w samej pętli]
kolor_z_odcieniem = tablica_kolorow_dla_odcienia[kolor];
i tyle. Cała kwestia to policzenie palety dla wszystkich używanych tekstur i ich odcieni przed renderingiem. Można napisać sobie jakiś prosty program który zbierze wszystkie tekstury do kupy, doda do tego potrzebne odcienie, zredukuje to do 256 wartości, zremapuje tekstury do nowej palety i jak trzeba wygeneruje od razu tablice cieniowania.
15.03.2021 15:13
[#67]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #66
Z ciekawostek Ci napiszę, że kiedyś robiłem mapy do Quake I w programie o nazwie Quark dla PC. Jeżeli chodzi o światła to one były liczone przez specjalny program o nazwie "Light", który wyliczał światła dla całej planszy. Ten proces trwał nawet kilka minut, dlatego takie liczenie robiono przed rysowaniem mapy w grze.
Jak już dojdziesz w swoim silniku do obiektów typu przeciwnicy to napiszę Ci, że w kodzie źródłowym Quake realizowane jest to przez tzw. "Entities". Każdy obiekt na mapie ma przypisany taką strukturę z przypisaniem wartości do cech. Wydarzenia typu "Trigger" są realizowane przez cechy obiektów o nazwie "Trigger" i "Identifier".
Zaś co do zachowania się obiektów, to każdy z nich ma metodę "Think", która animuje dany obiekt i jest to wywoływane co pewien odcinek czasu.
Generalnie w takim silniku można sobie różne wydarzenia rozdystrybuować w czasie. Rysowanie jest oczywiście najpilniejsze. Ale obsługa obiektów może być realizowana dużo rzadziej.
Co do 8-bitowej palety to jeżeli skorzystasz z tego sposobu - wygeneruj sobie jakąś dla swojej gry. Nie musi zawierać wszystkich barw, bo przecież np. jakichś jaskrawych kolorów nie potrzebujesz. Podałem Ci metodę z kodowaniem HSV kolorów, której dystrybucja jest bardziej równomierna niż RGB na 8 bitach.
Nie wiem co do karty Warp1260 i jak Twój silnik będzie działać na tej karcie z RTG, ale może wyodrębnij sobie tę newralgiczną funkcję rysowania, żeby zoptymalizować sobie w razie czego. To co tam siedzi w środku - C czy asembler nie ma wtedy dużego znaczenia.
Sam nigdy nie robiłem tego typu silnika, i nie znam się zupełnie na 3D i mapowaniu tekstur, ale korzystałem z Picasso96API i generalnie najszybsze są akcelerowane funkcje na bitmapach, ale to raczej dla gier 2D.
P.S. W ważnych procedurach unikaj mnożenia i stablicuj sobie potrzebne wielokrotności liczb. Widzę, że w tamtym kodzie masz "intensity level". Mnożenie generalnie jest bardzo kosztowne dla CPU. Dlatego też pewnie trzyma się tekstury o szerokości będącej potęgą liczby 2.
FPSy są bardzo istotne, ale skoro wiesz że karta, dla której piszesz, ma taką przepustowość, że obsłuży Twoje algorytmy, to nie musisz się o nie bardzo martwić - zawsze pewnie ktoś pomoże w przypadku ewentualnych trudności.
Na razie może zmniejsz rozdzielczość na potrzeby testów (np. okienko), bo jednak to najbardziej wymagająca i kluczowa rzecz. Jak później zoptymalizujesz kod, będziesz mógł wrócić do oryginalnej rozdzielczości.
Dla informacji napiszę jeszcze, że z FPSami na Amidze walczyło już co najmniej dwoje programistów - Andy Clitheroe (Alien Breed 3D II) oraz Mark Sibly (Gloom). Kody źródłowe w asemblerze tych gier są dostępne. Gloom Deluxe potrafi skorzystać z CyberGraphX, tzn. działa na karcie graficznej. Zawsze można podejrzeć różne interesujące algorytmy.
Jak już dojdziesz w swoim silniku do obiektów typu przeciwnicy to napiszę Ci, że w kodzie źródłowym Quake realizowane jest to przez tzw. "Entities". Każdy obiekt na mapie ma przypisany taką strukturę z przypisaniem wartości do cech. Wydarzenia typu "Trigger" są realizowane przez cechy obiektów o nazwie "Trigger" i "Identifier".
Zaś co do zachowania się obiektów, to każdy z nich ma metodę "Think", która animuje dany obiekt i jest to wywoływane co pewien odcinek czasu.
Generalnie w takim silniku można sobie różne wydarzenia rozdystrybuować w czasie. Rysowanie jest oczywiście najpilniejsze. Ale obsługa obiektów może być realizowana dużo rzadziej.
Co do 8-bitowej palety to jeżeli skorzystasz z tego sposobu - wygeneruj sobie jakąś dla swojej gry. Nie musi zawierać wszystkich barw, bo przecież np. jakichś jaskrawych kolorów nie potrzebujesz. Podałem Ci metodę z kodowaniem HSV kolorów, której dystrybucja jest bardziej równomierna niż RGB na 8 bitach.
Nie wiem co do karty Warp1260 i jak Twój silnik będzie działać na tej karcie z RTG, ale może wyodrębnij sobie tę newralgiczną funkcję rysowania, żeby zoptymalizować sobie w razie czego. To co tam siedzi w środku - C czy asembler nie ma wtedy dużego znaczenia.
Sam nigdy nie robiłem tego typu silnika, i nie znam się zupełnie na 3D i mapowaniu tekstur, ale korzystałem z Picasso96API i generalnie najszybsze są akcelerowane funkcje na bitmapach, ale to raczej dla gier 2D.
P.S. W ważnych procedurach unikaj mnożenia i stablicuj sobie potrzebne wielokrotności liczb. Widzę, że w tamtym kodzie masz "intensity level". Mnożenie generalnie jest bardzo kosztowne dla CPU. Dlatego też pewnie trzyma się tekstury o szerokości będącej potęgą liczby 2.
FPSy są bardzo istotne, ale skoro wiesz że karta, dla której piszesz, ma taką przepustowość, że obsłuży Twoje algorytmy, to nie musisz się o nie bardzo martwić - zawsze pewnie ktoś pomoże w przypadku ewentualnych trudności.
Na razie może zmniejsz rozdzielczość na potrzeby testów (np. okienko), bo jednak to najbardziej wymagająca i kluczowa rzecz. Jak później zoptymalizujesz kod, będziesz mógł wrócić do oryginalnej rozdzielczości.
Dla informacji napiszę jeszcze, że z FPSami na Amidze walczyło już co najmniej dwoje programistów - Andy Clitheroe (Alien Breed 3D II) oraz Mark Sibly (Gloom). Kody źródłowe w asemblerze tych gier są dostępne. Gloom Deluxe potrafi skorzystać z CyberGraphX, tzn. działa na karcie graficznej. Zawsze można podejrzeć różne interesujące algorytmy.
15.03.2021 15:22
[#68]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@Hexmage960, post #67
Dzięki, za info.. tak tablicuje co to tylko mogę :)
Tymi zagadnieniami związanymi z 8bit wyświetlaniem to na razie odstawiłem i nie zagłębiałem się
bo jednak chciałem pobawić się w wygenerowanie trucolor, jak nie da rady.. to pewnie potem popróbuje z 8bit.
Intensity level biore już z tablicy, no ale trzeba pomożyć przez wartość pixela żeby mieć odcień..
Tymi zagadnieniami związanymi z 8bit wyświetlaniem to na razie odstawiłem i nie zagłębiałem się
bo jednak chciałem pobawić się w wygenerowanie trucolor, jak nie da rady.. to pewnie potem popróbuje z 8bit.
Intensity level biore już z tablicy, no ale trzeba pomożyć przez wartość pixela żeby mieć odcień..
15.03.2021 16:35
[#69]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #68
Nie tablicuj wszystkiego co możesz bo to bez sensu i na 060 pewnie będzie wolniej... Mnożenia wcale nie są bardzo wolne. na 060 to 2 cykle procesora gdzie najszybsza instrukcja to 0.5. Po prostu są wolniejsze niż większość innych instrukcji. Ale jeżeli zaczniesz je tablicować to obstawiam że będzie wolniej niż być po prostu pomnożył (zakładając że kompilator nie wstawi jakiegoś głupiego skoku do funkcji)
15.03.2021 16:46
[#70]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@kiero, post #69
Mnożenia wcale nie są bardzo wolne. na 060 to 2 cykle procesora gdzie najszybsza instrukcja to 0.5. Po prostu są wolniejsze niż większość innych instrukcji.
W porządku. Nie wiedziałem ile operacja mnożenia zajmuje na 060 - pisząc te słowa miałem na myśli generalnie 68020+.
Bo na 68020, jeśli się nie mylę, mnożenie (MUL.W) zajmuje od 25 do 28 cykli, zaś MUL.L zajmuje od 41 do 44 cykli.
15.03.2021 17:20
[#72]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #71
Praktycznie zawsze jest sens, ale oczywiście mówimy jedynie o najbardziej kluczowych pętlach bo inaczej nie warto. Manual dla 060. Rozdział 10
Nawet jeżeli nie znasz asemblera to sporo można się dowiedzieć.
Jeżeli chodzi o operacja na liczbach całkowitych to 040 jest tak samo szybkie ale nie ma 2 potoków. Z tego co pamiętam jedynie mnożenie jest zauważalnie wolniejsze. Nie pamiętam jak sprawa wygląda jeżeli chodzi o fpu.
Ostatnia aktualizacja: 15.03.2021 17:20:39 przez kiero
Nawet jeżeli nie znasz asemblera to sporo można się dowiedzieć.
Jeżeli chodzi o operacja na liczbach całkowitych to 040 jest tak samo szybkie ale nie ma 2 potoków. Z tego co pamiętam jedynie mnożenie jest zauważalnie wolniejsze. Nie pamiętam jak sprawa wygląda jeżeli chodzi o fpu.
Ostatnia aktualizacja: 15.03.2021 17:20:39 przez kiero
15.03.2021 23:43
[#73]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@kiero, post #72
******************
UPDATE - test do pobrania
Hej,
Jeśłi Ktoś ma chwilkę i chotę, to zapraszam do testu.
Pozbyłem się na razie tekstur, został sam kolor i cieniowanie
(trochę jak w Za Żelazną Bramą) wydajność oczywiśćie mocno
podskoczyła, chciałbym poznac wyniki na prawdziwych maszynach.
http://mstanisz.website.pl/tmp/other/ray-3.zip
Dostępne wersje 040, 060, 080
Z reguestera wybieramy rozdzialczość, np. 320x240, 640x480
i tryb KONIECZNIE 32 bity
ruszanie myszką obrót głowy.
WSAD poruszanie się
ESC wyjsćie i liczba FPS
Proszę wpisywać FPS-y oraz przy jakich parametrach był test i na jakiej wersji
DZIĘKUJĘ z GÓRY !!
***************
Ostatnia aktualizacja: 15.03.2021 23:43:40 przez mateusz_s
16.03.2021 00:40
[wyróżniony]
[#80]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #79
Jak to programista ogranal to juz nie wiem. Wg logu gra kozysta z funkcji WritePixelArray8() wiec zakladam ze nie kozysta z c2p.
Co do wynikow to dla rozdzielczosci 320x240x8 zaleznie od lokacji jest od 18 do 30+ FPS.
Ostatnia aktualizacja: 16.03.2021 00:42:04 przez Phibrizzo
Co do wynikow to dla rozdzielczosci 320x240x8 zaleznie od lokacji jest od 18 do 30+ FPS.
Ostatnia aktualizacja: 16.03.2021 00:42:04 przez Phibrizzo
16.03.2021 10:03
[#81]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@Hexmage960, post #70
@kiero @Hexmage960
Hej,
Nie rozumiem jednej rzeczy, może spróbujecie mi to wyjaśnić.
Dlaczego używanie textur 8 bitowych indexowanych ma być szybsze niż 32 bitowych RGBA?
Wiem, że pytanie brzmi trochę głupio, ale w moim przypadku wygląda to tak:
1. Promień przecina ścianę i znajduje współrzędne pixela w danej texturze, jako [x + y*tex_width]
2. Owszem jeśli jest to textura 8 bitowa indeksowana to mamy do czynienia z tablicą typu unsigned char, 1 bajtową i pod tymi współrzędnymi będzie znajdowac się index do kolor mapy. Ok, czyli na pewno taka tablica będzie wydajniejsza.
3. Ale... teraz jeśli już mamy ten index to i tak przecież muszę za jego pomocą odnaleźć kolor w postaci RGB, bo kolor mapa jest tablicą 3 bajtową - co chyba jest nawet gorsze niż gdyby była 4 bajtową.
4. Więc kod pobrania pixela by wyglądał tak w tym przypadku:
5. Czy źle to robię?
6. Bo przecież mniej zachodu mam przy texturach 32 bitowych, nie muszę dwa razy sięgać do tablicy:
7. w tym przypadku sięgam tylko raz do tablicy i mam już wszsykie kolory pixela od razu
Ostatnia aktualizacja: 16.03.2021 10:05:46 przez mateusz_s
Hej,
Nie rozumiem jednej rzeczy, może spróbujecie mi to wyjaśnić.
Dlaczego używanie textur 8 bitowych indexowanych ma być szybsze niż 32 bitowych RGBA?
Wiem, że pytanie brzmi trochę głupio, ale w moim przypadku wygląda to tak:
1. Promień przecina ścianę i znajduje współrzędne pixela w danej texturze, jako [x + y*tex_width]
2. Owszem jeśli jest to textura 8 bitowa indeksowana to mamy do czynienia z tablicą typu unsigned char, 1 bajtową i pod tymi współrzędnymi będzie znajdowac się index do kolor mapy. Ok, czyli na pewno taka tablica będzie wydajniejsza.
3. Ale... teraz jeśli już mamy ten index to i tak przecież muszę za jego pomocą odnaleźć kolor w postaci RGB, bo kolor mapa jest tablicą 3 bajtową - co chyba jest nawet gorsze niż gdyby była 4 bajtową.
4. Więc kod pobrania pixela by wyglądał tak w tym przypadku:
// index do kolor mapy znajdujący się w trafionym pixelu
unsigned int texture_pixel_index = texture_list[texture_id].pixels[x + y*tex_width] * 3;
// pobieram R,G,B z kolor mapy dla danego indexu,
output_buffer[output_pixel_index] =
texture_list[texture_id].color_map[texture_pixel_index] << 16 |
texture_list[texture_id].color_map[texture_pixel_index + 1] << 8 |
texture_list[texture_id].color_map[texture_pixel_index + 2]; 5. Czy źle to robię?
6. Bo przecież mniej zachodu mam przy texturach 32 bitowych, nie muszę dwa razy sięgać do tablicy:
// index do kolor mapy znajdujący się w trafionym pixelu unsigned int texture_pixel_index = x + y*tex_width; // pobieram R,G,B z kolor mapy dla danego indexu, output_buffer[output_pixel_index] = texture_list[texture_id].pixels[texture_pixel_index];
7. w tym przypadku sięgam tylko raz do tablicy i mam już wszsykie kolory pixela od razu
Ostatnia aktualizacja: 16.03.2021 10:05:46 przez mateusz_s
16.03.2021 10:13
[#82]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #81
Różnica jest jeżeli robisz rendering w 8bitach. I nie mówię tu tylko o finalnym obrazie tylko o liczeniu oświetlenia. Nigdzie ci nie napisałem, że tekstury 8bit w trybie 32bitowym mają jakikolwiek sens. Jeżeli renderujesz w 8bitach to nie musisz pobierać niczego z palety. Pobierasz bajt i wypluwasz bajt.
16.03.2021 10:34
[#84]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #73
******************
UPDATE - test do pobrania
Hej,
Jeśłi Ktoś ma chwilkę i chotę, to zapraszam do testu.
Pozbyłem się na razie tekstur, został sam kolor i cieniowanie
(trochę jak w Za Żelazną Bramą) wydajność oczywiśćie mocno
podskoczyła, chciałbym poznac wyniki na prawdziwych maszynach.
http://mstanisz.website.pl/tmp/other/ray-3.zip
Dostępne wersje 040, 060, 080
Z reguestera wybieramy rozdzialczość, np. 320x240, 640x480
i tryb KONIECZNIE 32 bity
ruszanie myszką obrót głowy.
WSAD poruszanie się
ESC wyjsćie i liczba FPS
Proszę wpisywać FPS-y oraz przy jakich parametrach był test i na jakiej wersji
DZIĘKUJĘ z GÓRY !!
***************
Odnośnie tego updejtu i testu, to przepraszam, oczywiście wrzuciłem wersję z błedem
jest co prawda requester ale niepotrzebnie sprawdza jeden parametr i wywala błąd, wrzuce nową jak wróce z roboty
16.03.2021 10:51
[#85]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #81
Jeżeli wklejasz w trybie 8-bitowym to korzyści są dwie:
1. Tak jak napisał Kiero, proste mapowanie kolorów za pomocą tablicy 256-elementowej. W przypadku 32-bitowym takie proste pojedyncze mapowanie nie jest możliwe,
2. Możesz wklejać po 4 piksele na raz. Nie jest to bez znaczenia. (Możesz użyć do tego standardowej funkcji WritePixelArray8).
Ostatnia aktualizacja: 16.03.2021 10:52:45 przez Hexmage960
1. Tak jak napisał Kiero, proste mapowanie kolorów za pomocą tablicy 256-elementowej. W przypadku 32-bitowym takie proste pojedyncze mapowanie nie jest możliwe,
2. Możesz wklejać po 4 piksele na raz. Nie jest to bez znaczenia. (Możesz użyć do tego standardowej funkcji WritePixelArray8).
Ostatnia aktualizacja: 16.03.2021 10:52:45 przez Hexmage960
16.03.2021 13:09
[#86]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@Hexmage960, post #85
**************
UPDATE - testy na V600 - filmiki
Wielkie podziękowania dla @Skipp (Discord Vampira) za testy
Platforma V600 - GOLD 2.11 x11 = 78MHz
ps. jakość trochę zmasakrowana ze względu na kompresje, a dominują gradienty, ale co ma być widac to widać :)
320x240x32 - ok. 100 fps (bez textur)
640x480x32 - ok. 25-27 fps (bez textur)
320x240x32 - ok 8-9 fps (z texturami)
640x480x32 - ok 2-3 fps (z texturami)
Ostatnia aktualizacja: 16.03.2021 13:13:57 przez mateusz_s
UPDATE - testy na V600 - filmiki
Wielkie podziękowania dla @Skipp (Discord Vampira) za testy
Platforma V600 - GOLD 2.11 x11 = 78MHz
ps. jakość trochę zmasakrowana ze względu na kompresje, a dominują gradienty, ale co ma być widac to widać :)
320x240x32 - ok. 100 fps (bez textur)
640x480x32 - ok. 25-27 fps (bez textur)
320x240x32 - ok 8-9 fps (z texturami)
640x480x32 - ok 2-3 fps (z texturami)
Ostatnia aktualizacja: 16.03.2021 13:13:57 przez mateusz_s
16.03.2021 14:34
[#88]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #73
Warp 1260 100 MHz
320x240 - 34.2 FPS
640x480 - 6.5 FPS
RTG Warpa jeszcze ma być zoptymalizowane, więc docelowo powinno być więcej efpeesów.
Wersja 320x240 jest przyjemnie płynna. 640x480 momentami dosyć szybka, po czym mocno klatkuje blisko ścian.
Jak włączyć tekstury? Jeśli było podane, to sorry, ale musiałem przeoczyć.
320x240 - 34.2 FPS
640x480 - 6.5 FPS
RTG Warpa jeszcze ma być zoptymalizowane, więc docelowo powinno być więcej efpeesów.
Wersja 320x240 jest przyjemnie płynna. 640x480 momentami dosyć szybka, po czym mocno klatkuje blisko ścian.
Jak włączyć tekstury? Jeśli było podane, to sorry, ale musiałem przeoczyć.
16.03.2021 14:44
[#89]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@Umpal, post #88
Wielkie dzięki!
tutaj jest starszy build z texturami, ale kaszana jest, mocno daje w kość fps spadają z 100 do 10 na vamprzie, jak możesz to przetestuj też proszę: http://mstanisz.website.pl/tmp/other/test-060-build-0.2.zip
generalnie podłoga i sufity wymagaja optymalizacji bo sa na chama rysowane, to jeszcze fps skoczy troche
Ostatnia aktualizacja: 16.03.2021 14:45:29 przez mateusz_s
tutaj jest starszy build z texturami, ale kaszana jest, mocno daje w kość fps spadają z 100 do 10 na vamprzie, jak możesz to przetestuj też proszę: http://mstanisz.website.pl/tmp/other/test-060-build-0.2.zip
generalnie podłoga i sufity wymagaja optymalizacji bo sa na chama rysowane, to jeszcze fps skoczy troche
Ostatnia aktualizacja: 16.03.2021 14:45:29 przez mateusz_s