19.03.2021 15:37
[#121]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@Kefir_Union, post #113
@Kefir_Union dobry pomysł na optymalizację.. liczyć co drugi promień czy to przy ścianach lub suficie i a wartości pomiędzy nimi uśredniać a nie duplikować.. posprawdzam potem, można wtedy pętle mniejsze porobić..
Ogólnie starałem się unikąc tego pomysłu żeby nie robił się pixel 2x2, ale nie musze ich duplikować, uśrednianie może też dobrze wyjsć..
Ogólnie starałem się unikąc tego pomysłu żeby nie robił się pixel 2x2, ale nie musze ich duplikować, uśrednianie może też dobrze wyjsć..
19.03.2021 16:05
[#123]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #116
Do kompilowania w GCC do kodu asemblerowego wybierz flagę -S (wielka litera S).
Tutaj informacja:
https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall-Options
GCC -S filename.c
Tutaj informacja:
https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall-Options
19.03.2021 16:51
[#125]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@lef, post #120
@lef
Hej.. dzięki !!
Skoczyło z 270 fps do 470 fps.. Przy czym przekazanie przez parametr ani lokalna kopia nie pomogły jeśli chodzi o width i height trzeba je było zamienić na zafixowane czyli stałe.. pewnie wtedy może on użyć tych unroll-loops
Minus jest taki, że mogę się pożegnać z dowolnym wyborem rozdzielczości z requestera - żeby inne były dostęne muszę skompilować takie zafiksowane wersje np. 320x240, 640x480 itp...
lokalna kopia wskaźnika bufora też pomogła!
I tu ciekawostka, to samo zrobiłem dla funkcji rysowania sufitu i podłogi, tzn. zrobiłem stałe i lokalną kopię wskaźnika
ale już nic nie podskoczyło zostało tak jak było ok. 417 fps.
Także dzięki za pomoc :)
Tak to zostawię jednak - czyli zafixuje rozmiary, zrobie po prostu kilka wersji, ktre bedzie można wybierać z Launchera,
szkoda tracić tyle wydajnośći..
Hej.. dzięki !!
Skoczyło z 270 fps do 470 fps.. Przy czym przekazanie przez parametr ani lokalna kopia nie pomogły jeśli chodzi o width i height trzeba je było zamienić na zafixowane czyli stałe.. pewnie wtedy może on użyć tych unroll-loops
Minus jest taki, że mogę się pożegnać z dowolnym wyborem rozdzielczości z requestera - żeby inne były dostęne muszę skompilować takie zafiksowane wersje np. 320x240, 640x480 itp...
lokalna kopia wskaźnika bufora też pomogła!
I tu ciekawostka, to samo zrobiłem dla funkcji rysowania sufitu i podłogi, tzn. zrobiłem stałe i lokalną kopię wskaźnika
ale już nic nie podskoczyło zostało tak jak było ok. 417 fps.
Także dzięki za pomoc :)
Tak to zostawię jednak - czyli zafixuje rozmiary, zrobie po prostu kilka wersji, ktre bedzie można wybierać z Launchera,
szkoda tracić tyle wydajnośći..
19.03.2021 16:52
[#126]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@Hexmage960, post #123
@Hexmage
hej, tak zadziałało mi to poprzednie nawet, tylko chyba trzeba było chyba wykonać plik - tak jak przy robieniu profilera, wtedy się pojawiło..
Ostatnia aktualizacja: 19.03.2021 16:53:03 przez mateusz_s
Ostatnia aktualizacja: 19.03.2021 16:53:20 przez mateusz_s
hej, tak zadziałało mi to poprzednie nawet, tylko chyba trzeba było chyba wykonać plik - tak jak przy robieniu profilera, wtedy się pojawiło..
Ostatnia aktualizacja: 19.03.2021 16:53:03 przez mateusz_s
Ostatnia aktualizacja: 19.03.2021 16:53:20 przez mateusz_s
19.03.2021 18:28
[#129]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@Kefir_Union, post #128
nie, pewnie dlatego że przekazuje ją potem do kilku modułów po drodze a tam są typu int nie const, ale to by i tak nie zadziałało przy niewiadomej wielkości width x height, możliwe że bardziej opłacalne będzie nawet
zafixowanie przy wysowaniu ścian, wartosci 0-240 w pętli niż podanie zakresu w zmiennych któe są liczone czyli
for (y = wall_Start; y <wall_end; y++), bo wtedy on nie rozwinie tych funkcji a jak mu dam stałe wartosci
i tylko będę sprawedzał wysokość za pomocą "if" to może być optymalnie, ale jeszcze nie sprawdziałem, dopiero usiadłem i będę dłubał dalej..
zafixowanie przy wysowaniu ścian, wartosci 0-240 w pętli niż podanie zakresu w zmiennych któe są liczone czyli
for (y = wall_Start; y <wall_end; y++), bo wtedy on nie rozwinie tych funkcji a jak mu dam stałe wartosci
i tylko będę sprawedzał wysokość za pomocą "if" to może być optymalnie, ale jeszcze nie sprawdziałem, dopiero usiadłem i będę dłubał dalej..
19.03.2021 19:25
[#131]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@Kefir_Union, post #130
@Kefir_Union
noo.. też daje rade to rozwiazanie, troche jakby wolniej ale też jest OK, dzięki..
myślałem, że nie przejdzie
EDIT: jeszcze do @lef
zmienne iteracyjne w pętli muszą być u_int32, jest szybciej niż gdy były u_in16,
kurczę, teraz muszę praktycznie testować każdą zmienną, bo w niektróych przypadkach wychodzą duże
róznice między int 8,16,32.. a teraz mam tak, że dostosowuje wielkosc int do max wartosci ktora moze miec zmienna, ale jak widać roznie z tym bywa..
noo.. też daje rade to rozwiazanie, troche jakby wolniej ale też jest OK, dzięki..
myślałem, że nie przejdzie
EDIT: jeszcze do @lef
zmienne iteracyjne w pętli muszą być u_int32, jest szybciej niż gdy były u_in16,
kurczę, teraz muszę praktycznie testować każdą zmienną, bo w niektróych przypadkach wychodzą duże
róznice między int 8,16,32.. a teraz mam tak, że dostosowuje wielkosc int do max wartosci ktora moze miec zmienna, ale jak widać roznie z tym bywa..
19.03.2021 21:09
[#132]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #131
To ze jest wolniej akurat jest dziwne (moze kwestia tego, ze symulujesz cpu jednak?). Na prawdziwym m68k, jesli do krecenia petla uzyjesz zmiennej short, to kompilator jest w stanie uzyc znacznie szybszej instrukcji DBxx:
Jesli uzyjesz unsigned short, lub czegokolwiek wiekszego niz 16 bitow, to DBxx juz sie nie da uzyc i wtedy gcc generuje wolniejszy kod:
Dlatego, jak juz ktos tu wczesniej wspomnial, takie rzeczy powinienes testowac na prawdziwym cpu. Bo emulowany nie tylko nie pokaze roznic pomiedzy roznymi instrukcjami 68k, ale moze nawet zaklamywac wyniki - wszystko zalezy od tego w jaki sposob dana instrukcja jest emulowana.
.L3:
move.l #6579300,(a0)
add.l d1,a0
dbra d0,.L3Jesli uzyjesz unsigned short, lub czegokolwiek wiekszego niz 16 bitow, to DBxx juz sie nie da uzyc i wtedy gcc generuje wolniejszy kod:
.L4:
move.l #6579300,(a0)
add.l d1,a0
subq.l #1,d0
jcc .L4Dlatego, jak juz ktos tu wczesniej wspomnial, takie rzeczy powinienes testowac na prawdziwym cpu. Bo emulowany nie tylko nie pokaze roznic pomiedzy roznymi instrukcjami 68k, ale moze nawet zaklamywac wyniki - wszystko zalezy od tego w jaki sposob dana instrukcja jest emulowana.
19.03.2021 21:41
[#135]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@michal_zukowski, post #134
coś pomiędzy wolf3d a doom,
generalnie wszystkie elementy do których doszedłem do tej pory to:
- rozglądanie się za pomocą myszki
- cieniowanie ścian = distance shading + simple directional shading
- ściana typu zwykły klocek z jedną texturą oraz z dowolną texturą na każdej stronie
- ściana "cienka" - dowolnie ukośna z texturą
- ściana nieregularna - czyli coś ala kolumna o dowolnychh prostokątnych rozmiarach i położeniu, która jest mniejsza od standardowej ściany, jedna lub wiele textur.
- cieniowanie podłogi i sufitów przez distnace shading
- multi texturing sufitów i podłóg czyli dowolna textura per-tile
- edytor (ze wspomnianymi ficzerami)
Przy czym, portując na Ami, wywaliłem wszystkie pozostałe typy ścian,
żeby po prostu zobaczyć jak to będzie działać.. ogólnie jest jakiś tam potencjał
przynajmniej na Vampirach, ale jak pokazują moje pytania optymalizacja idzie dość topornie,
choć do przodu,
Mogę tylko liczyć na to co uzyskam w C, w asm nie potrafię, ale i tak jest nie najgorzej.
Praca w toku. Jak widać babole czają się w szczegółach, brak Vampira utrudnia sprawę.
Testuje raz na jakiś czas dzięki uprzejmości Kolegów.
Jest jeszcze pare sposobów optymalizacji, których nawet nie ruszyłem, są różne triki C,
których jeszcze nie stosowałęm, albo których nie znam.. praca w toku po prostu..
Jeśli chcę dodać kolejne elementy typowo growo/enginowe to muszę uzyskać jakieś dobre
wyniki w planie minimum, czyli o teksturowane ściany i sufity.. to można potem coś dalej myśleć..
Wszsytko co wspomniałem możesz obejrzeć w tym filmiku z edytorem, robie tam pseudo level, z użyciem tych wszsytkich elementów
generalnie wszystkie elementy do których doszedłem do tej pory to:
- rozglądanie się za pomocą myszki
- cieniowanie ścian = distance shading + simple directional shading
- ściana typu zwykły klocek z jedną texturą oraz z dowolną texturą na każdej stronie
- ściana "cienka" - dowolnie ukośna z texturą
- ściana nieregularna - czyli coś ala kolumna o dowolnychh prostokątnych rozmiarach i położeniu, która jest mniejsza od standardowej ściany, jedna lub wiele textur.
- cieniowanie podłogi i sufitów przez distnace shading
- multi texturing sufitów i podłóg czyli dowolna textura per-tile
- edytor (ze wspomnianymi ficzerami)
Przy czym, portując na Ami, wywaliłem wszystkie pozostałe typy ścian,
żeby po prostu zobaczyć jak to będzie działać.. ogólnie jest jakiś tam potencjał
przynajmniej na Vampirach, ale jak pokazują moje pytania optymalizacja idzie dość topornie,
choć do przodu,
Mogę tylko liczyć na to co uzyskam w C, w asm nie potrafię, ale i tak jest nie najgorzej.
Praca w toku. Jak widać babole czają się w szczegółach, brak Vampira utrudnia sprawę.
Testuje raz na jakiś czas dzięki uprzejmości Kolegów.
Jest jeszcze pare sposobów optymalizacji, których nawet nie ruszyłem, są różne triki C,
których jeszcze nie stosowałęm, albo których nie znam.. praca w toku po prostu..
Jeśli chcę dodać kolejne elementy typowo growo/enginowe to muszę uzyskać jakieś dobre
wyniki w planie minimum, czyli o teksturowane ściany i sufity.. to można potem coś dalej myśleć..
Wszsytko co wspomniałem możesz obejrzeć w tym filmiku z edytorem, robie tam pseudo level, z użyciem tych wszsytkich elementów
19.03.2021 23:38
[#139]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@lef, post #132
@lef
Dzięki uprzejmości Kolegów, zrobiliśmy te próby z int typu 16 i 32 w pętlach i niektórych zmiennych,
przy czym dorzuciłem już resztę kodu, czyli było rysowanie ścian, sufitów i podłóg, a ściany były już z teksturami.
- Warp 060 - ok 16 fps - w obu przypadkach
- V 080 - 56 fps w obu przypadakch
- ja na winuae miałem ok 40 fps w obu przypadkach
Czyli chyba się to jakoś skompensowało gdy dodałem reszte kodu, albo kompilator porobił optymalniejszy kod,
a ten wcześniejszy przy "pustych" pętlach był zafałszowany jak wspominał @kiero..
Na wszelki wypadek powrócę do tych 16 bitowych intów tam gdzie mogę,
tak jak mówiłeś..
Ostatnia aktualizacja: 19.03.2021 23:39:52 przez mateusz_s
Dzięki uprzejmości Kolegów, zrobiliśmy te próby z int typu 16 i 32 w pętlach i niektórych zmiennych,
przy czym dorzuciłem już resztę kodu, czyli było rysowanie ścian, sufitów i podłóg, a ściany były już z teksturami.
- Warp 060 - ok 16 fps - w obu przypadkach
- V 080 - 56 fps w obu przypadakch
- ja na winuae miałem ok 40 fps w obu przypadkach
Czyli chyba się to jakoś skompensowało gdy dodałem reszte kodu, albo kompilator porobił optymalniejszy kod,
a ten wcześniejszy przy "pustych" pętlach był zafałszowany jak wspominał @kiero..
Na wszelki wypadek powrócę do tych 16 bitowych intów tam gdzie mogę,
tak jak mówiłeś..
Ostatnia aktualizacja: 19.03.2021 23:39:52 przez mateusz_s
26.03.2021 00:32
[#141]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #140
trochę sobie dobierałem parametry do cieniowania:
- cieniowanie dystansu
- lekkie cieniowanie boczne, bo bez tego sciany są za mdłe
przy czym dodaje to takie ciemne placki daleko w tle
- dlatego dodalem przycinanie czerni w dali żeby zrównać intensywnosc
- ciemniejszy sufit, podloga bez zmian
wszystkie wartości są prekalkulowane, razem z przemnożeniem więc dużo oszczędzam w pętli..
taki tam filmik:
- cieniowanie dystansu
- lekkie cieniowanie boczne, bo bez tego sciany są za mdłe
przy czym dodaje to takie ciemne placki daleko w tle
- dlatego dodalem przycinanie czerni w dali żeby zrównać intensywnosc
- ciemniejszy sufit, podloga bez zmian
wszystkie wartości są prekalkulowane, razem z przemnożeniem więc dużo oszczędzam w pętli..
taki tam filmik:
26.03.2021 13:58
[#143]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@stefkos, post #142
Uruchomi się na wszystkim co ma RTG, na vampirzach na
Razie najlepiej, na warpie dużo gorzej, na morphosach
Jeszcze nie testowane, I na tych piamigach czy czym takim tez nie.
W tym trybie cieniowanym to np. Na v600 śmiga w 320x240x32 a w 640x480x32 tez jest płynnie.
Jak się włączy textury na ścianach to w 320x240x32 nadal jest płynnie, a w 640x480x32 powiedzmy że grywalne
Niestety narazie jeśli włączę textury podlog i sufitów
To nawet 320x240 dropuje do jakiś 10fps od razu, jeszcze nie optymalizował tej części.. zobaczę ile uda mi się wycisnąć
Ostatnia aktualizacja: 26.03.2021 14:01:57 przez mateusz_s
Razie najlepiej, na warpie dużo gorzej, na morphosach
Jeszcze nie testowane, I na tych piamigach czy czym takim tez nie.
W tym trybie cieniowanym to np. Na v600 śmiga w 320x240x32 a w 640x480x32 tez jest płynnie.
Jak się włączy textury na ścianach to w 320x240x32 nadal jest płynnie, a w 640x480x32 powiedzmy że grywalne
Niestety narazie jeśli włączę textury podlog i sufitów
To nawet 320x240 dropuje do jakiś 10fps od razu, jeszcze nie optymalizował tej części.. zobaczę ile uda mi się wycisnąć
Ostatnia aktualizacja: 26.03.2021 14:01:57 przez mateusz_s
31.03.2021 12:58
[#144]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #143
****************
UPDATE..
demko ray5
http://mstanisz.website.pl/tmp/other/ray5.zip
Cześć, podsyłam do przetestowania nowe demko.
Można wybrać tryb pełnoekranowy lub okienkowy
np. dla użytkowników MorphOSa lub innych konfiguracji.
Dostępne tryby 16, 24 i 32 dla pełnego ekranu
i 24, 32 dla okienkowych (w zależności w jakim trybie mamy pulpit)
ESC - wyjscie, WSAD - poruszanie się, myszka rozglądanie,
fps pojawia się na końcu po wyjsciu, w shell
Obecnie są texturowane ściany, podłoga cieniowana. Wykrywa format pixela
więc kolory zawsze powinny się zgadzać.
Kilka testów:
1) V4 z ApolloOS
- tryb okienkowy 320x240x24 ok. 60-68 fps
- tryb okienkowy 640x480x24 ok. 17-18 fps
2) Warp 100mhz
- okienkowy i fullscreen w 320x240x32 ok 30 fps
Z racji na dostepne tryby 16/24/32 w tym momencie najbardziej mnie interesują
platformy typu Vampire V2, V4, Warp, piAmigi, NG, i co tam jeszcze jest i różne systemy..
a także chciałem zobaczyć czy są jakieś znaczące różnice między trybami 16/24 i 32..
Z góry dzięki za testy..
UPDATE..
demko ray5
http://mstanisz.website.pl/tmp/other/ray5.zip
Cześć, podsyłam do przetestowania nowe demko.
Można wybrać tryb pełnoekranowy lub okienkowy
np. dla użytkowników MorphOSa lub innych konfiguracji.
Dostępne tryby 16, 24 i 32 dla pełnego ekranu
i 24, 32 dla okienkowych (w zależności w jakim trybie mamy pulpit)
ESC - wyjscie, WSAD - poruszanie się, myszka rozglądanie,
fps pojawia się na końcu po wyjsciu, w shell
Obecnie są texturowane ściany, podłoga cieniowana. Wykrywa format pixela
więc kolory zawsze powinny się zgadzać.
Kilka testów:
1) V4 z ApolloOS
- tryb okienkowy 320x240x24 ok. 60-68 fps
- tryb okienkowy 640x480x24 ok. 17-18 fps
2) Warp 100mhz
- okienkowy i fullscreen w 320x240x32 ok 30 fps
Z racji na dostepne tryby 16/24/32 w tym momencie najbardziej mnie interesują
platformy typu Vampire V2, V4, Warp, piAmigi, NG, i co tam jeszcze jest i różne systemy..
a także chciałem zobaczyć czy są jakieś znaczące różnice między trybami 16/24 i 32..
Z góry dzięki za testy..
01.04.2021 12:14
[#150]
Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..
@mateusz_s, post #149
Zauważyłem, że FPSy zależą od tego jak blisko ścian się trzymasz - przy ścianach jest wolniej, dalej od ścian - szybciej. Musisz jakieś timedemo zaimplementować to będzie można się ścigać w klatkach na sekundę.
Tymczasem - beat this:
Ostatnia aktualizacja: 01.04.2021 12:18:52 przez recedent
Tymczasem - beat this:
Ostatnia aktualizacja: 01.04.2021 12:18:52 przez recedent