@kiero, post #300

• Odpowiedz

@mateusz_s, post #301

• Odpowiedz

@kiero, post #302

• Odpowiedz

@mateusz_s, post #303

robota na 4-5 dni, ale zeszło mi chyba ze 3 miesiące hehe..
poprawiłem a właściwie przepisywałem edytor poziomów wraz ze strukturą poziomu,
tak żeby ogarnięte były mip-mapy i lightmapy, teraz bede pod to poprawial silnik
tak zeby optymalnie ogarniał i mixował mipmapy, lightmapy, cieniowanie itp,
zmiejszyłem ilość odcieni tabel kolorow i lightmap ze 256 do 128, roznica zadna raczej
a sporo mniej pamieci bede uzyte..

pare zrzutow z edytora, robilem w winapi wiec dodatkowo masochizm level 100 ;p

• Odpowiedz

@mateusz_s, post #304

• Odpowiedz

@mateusz_s, post #305

• Odpowiedz

@mateusz_s, post #305

No bardzo fajnie to wygląda! Lightmapy i mipmapy robią różnicę.Na Vampie w lowresie chodzi nawet całkiem OK.Dobra robota

• Odpowiedz

@mateusz_s, post #305

• Odpowiedz

@mateusz_s, post #305

Pomysł 1.
Mam znowu pomysł do przetestowania, który może przyśpieszyć podlogi/sufity.
- W edytorze każdy kafelek na który może wejsc gracz podzieliłbym np. na 8 cześci po 45*.
a następnie przypisał każdej cześci listę potencjalnie widocznych kafelków tworzących podloge/sufit.
podział na 8 cześci powinien dać w miare krótkie listy wiec mniej sprawdzania.
- listy bylyby zapisane do pliku z poziomem.
- w enginie w zalezności od pozyucji gracza oraz kątowi obrotu korzystamy a danej listy.
- wierzcholki kafelkow sa rzutowane na nasz projection plane.
- renderujemy tak jak obecnie z tym że poczatek i koniec każdej linii znajdujemy wcześniej poprzez interpolację (tak jak przy rasteryzacji trojkatów)

Jesli ten sposób okazałby się nie wolniejszy niż obecny to już by był lepszy bo łatwiej byłoby rysować potem nie regularne ściany, drzwi, kolumny itp.

W obecnym algorytmie rysuje podlogi/sufity po narysowaniu wszsytkich ścian. W momencie rysowania ścian zbieram informacje na temat tego gdzie zaczyna się i kończy kazdy kafelek podlogi/sufitu. Więc nigdy nie rysuję niepotrzebych rzeczy (ktore np. bedą zasłonięte). Ale to zabiera sporo czasu i musze robic obliczenia dla kazdego kafelka az do uderzenia w ścianę.

W nowym algorytmie najpierw rysowałbym podlogi/sufity, potem sciany. Minus to nadrysowywanie przez sciany czesci podlogi lub sufitów.. ale to nie wcale koniecznie musi bardzo dać się we znaki ostatecznie..

Tutaj na razie myślę, jak zrobić listę widocznych kafelków dla danegej cześci danego kafelka.. chyba wykorzystam jakiś "brute force" po prostu przejde przez dany kafelek krokiem 0.1 wzdłuż i wszerz i dla każdego raycasting dla szerokości np. 640 i krok obrotu co 9 stopni.. powinno być w miare dokladnie


Pomysł 2.
Jeśli bym się uporał z pomysłem nr 1 to pomyslalem czy by nie przenieść do 8 bit. W 32 bitach generalnie zrobiłem co chciałem. Natomiast przy 8 bitach można by uruchomić też na maszynie bez RTG tylko pod AGA. Jednak tutaj była by jakas już styliacja, tj. textury zrobiłbym w palecie szarości 128, dzieki czemu utrzymałbym ładne cieniiowanie i lightmapy. Ale mialbym też 128 miejsc na inne kolory. Np. światła na texturach (tj. swiecace pixele) moga być dowolnego koloru, krew byla by czerwona, bron czy info panel bylbym kolorowy, wiec nie byłoby zupełnie szaro i smutno.. coś jak Super Hot na VR..


Na razie, powoli zacznę etapami robić pomysł 1, jest tu troszkę roboty już z utworzeniem samego generatora tych list w edytorze..

• Odpowiedz

@mateusz_s, post #309

• Odpowiedz

@mateusz_s, post #309

Udało mi sie na razie zrobić generator list potencjalnie widoczych kafelków PVC,
chyba jest OK.. dorzuciłem "wizualizator" - zeby podejrzec czy wszsytko jest ok - bez tego by byla lipa - w ciemno ciezko by to bylo robić

teraz najgorsze, weź to do pliku zapisz ;p

poniżej przyklady, kafelek jest dzielony na 8 czesci i dla kazdej czesci jest lista, dzieki temu krótsza..


edit:
kurła jak tak liczę na szybko, to te dane mogą zajać z 5-6 MB w zależnosci od rozbudowania levelu,
ale załóżmy te RAM to nie problem żaden, w latach pod koniec lat 90 sam mailem 64MB, wiec bez przesady



















Ostatnia aktualizacja: 20.07.2022 19:36:34 przez mateusz_s

• Odpowiedz

@mateusz_s, post #311

• Odpowiedz

@mateusz_s, post #312

• Odpowiedz

@mastaszek, post #313

• Odpowiedz

@mateusz_s, post #314

ok, jest dużo lepiej..

zostały jeszcze 2 małe glicze, i powinno być OK..

jak dopracuje to postaram się zrobić video jak to jest liczone,
podzieliłem na 3 przypadki i do każdego jest uszyty optymalny algorytm:

case 1:
jesli dany kafelek jest w calosci widoczny to od razu razsteryzuj krewedzie

case 2:
jesli jest czesciowo widoczny ale wszsytkie jego punkty nie są "za graczem", to najpierw zrób clipping do ekranu a potem rasteryzuj krewedzie

case 3:
jesli choc jeden punkt jest "za graczem" to najpierw zrób "near clipping", nastpenie clipping do ekranu a dopero potem rasteryzuj krewedzie..

ten trzeci jest oczywiście "najcięższy" do liczenia, nie za bardzo mozna tu bylo zoptymalizowac i w dodatku operuje na floatach ale z racji podzielenia na te 3 przypadki zwykle są to 2 góra 3 kafelki do obrobienia wiec nie wplywa to jakos na wydajnosc





Ostatnia aktualizacja: 08.08.2022 23:16:58 przez mateusz_s

• Odpowiedz

@mateusz_s, post #305

Mialem chwilke i odpalilem na a4k 040 25mhz zz9000. W 320x240 da sie przemieszczać ale nie widze ile fps wychodzi bo nie wyswietla wynikow. Wyglada bardzo efektownie. Zwlaszcza w wyzszych rozdzielczosciach. Niestety na tym configu w hires to juz ledwo chodzi i brak sensownej interakcji. Podoba mi sie nawet jako projekt studyjny. Pozdr

• Odpowiedz

@arturB, post #316

• Odpowiedz

@mateusz_s, post #315

yeah.. pijcie ze mno kompot

W teście z texturami samej podłogi (+lightmapy) na V1200
nowy algorytm ma 65 fps a poprzedni 45 fps..

jest różnica trzeba przyznać..

Walczę z gliczami i bugami jeszcze, wiekszosc juz poprawiłem,
chyba jeszcze jeden został..

na pewno jeszcze można coś zoptymalizować bo całość skłąda się z kilka działań i algorytmów
o których pisałem, a jak wiadomo nieraz można znaleźć szybszy algo albo lepiej go zaimplementować,

np. Testowałem różne algorytmy do rysowania linii (nie rysuje linii ale rasteryzuje krawdzie do bufora)
i ten jest najszybszy, chyba jedynie mógłby go przebić jakiś uszyty pod m68k asm, ale to poza moimi zdolnościami
może znacie jakąś gotową, zoptymalizowaną funkcję w asm, którą mógłbym przetestować?

Obecny jest taki:

void	GR_FV_Segment_To_Buffer(const int8 _buff_id, int32 x0, int32 y0, int32 x1, int32 y1)
{
	int32 dx = x1 - x0;
	int32 dy = y0 - y1;
	int32 e2;

	if (x0 < x1)
	{
		int32 dx = x1 - x0;
		int err = dx + dy;

		for (;;)
		{
			GR_fv_buf_x[_buff_id][y0] = x0;
			GR_fv_buf_x_cell_id[_buff_id][y0] = GR_fv_proxy_cell_id;

			if (x0 == x1 && y0 == y1) break;

			e2 = err << 1;

			if (e2 >= dy)
			{
				err += dy;
				x0++;
			}

			if (e2 <= dx)
			{
				err += dx;
				y0++;
			}
		}
	}
	else
	{
		int32 dx = x0 - x1;
		int err = dx + dy;

		for (;;)
		{
			GR_fv_buf_x[_buff_id][y0] = x0;
			GR_fv_buf_x_cell_id[_buff_id][y0] = GR_fv_proxy_cell_id;

			if (x0 == x1 && y0 == y1) break;

			e2 = err << 1;

			if (e2 >= dy)
			{
				err += dy;
				x0--;
			}

			if (e2 <= dx)
			{
				err += dx;
				y0++;
			}
		}
	}
}

Używam też przycinania linii i poligonów Sutherland-Hodgman.
Wersja do przycinania do okna ekranu jest zoptymalizowana pod ekran.

Ale wiem że są inne algorytmy np Mail92, miałem jakaś implementacje ale nie śmigała za bardzo i nie chciało mi się
zagłębiać w to może już poźniej..



Ostatnia aktualizacja: 13.08.2022 01:03:43 przez mateusz_s

• Odpowiedz

@mateusz_s, post #318

• Odpowiedz

@mateusz_s, post #318

• Odpowiedz

@buldogkekon, post #319

• Odpowiedz

@buldogkekon, post #319

• Odpowiedz

@arturB, post #320

Hej,
Niedługo postaram się zarzucić nowy filmik i dodać źródła + download do testu,
mam jeszcze dwa problemy które muszę rozwiązać..

Ale mogę już teraz powiedzieć że ten pomysł z nowym algorytmem
był dobrym rozwiązaniem. Jest nie tylko szybciej ale ponieważ podłogi i sufity są liczone
wcześniej niż ściany to będzie mi łatwiej dorobić potem nieregularne ściany.

Gdy chodzę po mapie na V1200, utrzymuję średnio 45 fps jest bardzo płynnie.
myślę, że jest to bardzo dobry rezultat biorąc pod uwagę że mamy tu textury ścian/sufitów/podłóg
razem z mipmapami oraz lightmapami i distance shading.

Jeśli wywalę lightmapy z podłóg i sufitów to mam grubo ponad 50-60fps, a jesli wywale textury podlog i sufitów zostawiać tylko kolor do ponad 100 fps..

Te lightmapy to takie już troche "porno", "eyecandy" - średni rezulat 45fps to niezły wynik chyba
- nie można dorzucać nowych ficzerów i spodziewać się fps nie zmaleje :)

Tak jak się spodziewałem, po dodaniu kodu który texturuje w najbardziej wewnętrznej pętli wydajność mocno spadła
pomyśłam, że może potem zarzuce na forum ten krótki kod ktory jest w wewnetrzej petli i może KTOŚ pomoże
zoptymalizować go w ASM

• Odpowiedz

@mateusz_s, post #323

Skoro u Ciebie dostalo skrzydel to na "padaczce" 040/25 pewnie tez troche befzie lepiej. Kibicuje temu. Dopinguje mnie do poprawiania mojego silniczka... choc idzie mi jak krew z nosa

• Odpowiedz

@arturB, post #324

• Odpowiedz

@arturB, post #324

ps.
jeśli wierzyć WinUAE to pod 040 @ 28mhz byloby około 14 fps

• Odpowiedz

@mateusz_s, post #326

Nie wiem czy tylko u mnie ale dziwnie myszka sie zachowuje... odpalilem na x5k i tez myszka fisiuje. Btw w fullHD 32bit 10fps... chociaz w sumie to jest dyskretna emulacja 68k... I tak niezle

• Odpowiedz

@arturB, post #327

• Odpowiedz

@mateusz_s, post #328

• Odpowiedz

@mateusz_s, post #1

*** UPDATE *** (msRay_devpack_v0.33)


cześć,
Wrzuciłem na Git-a kolejny update: https://github.com/mateusz83/msRay

Poza źródłami, w katalogu The Game Output są execi dla Amigi i Windows.

Tu przypominam, że do Amigi trzeba mieć 32-bit RTG + szybszy procek,
zalecane są "nowe" rozwiażania typu: V1200, Warp1260, TF1260 (z RTG), IceDrake, FireBird,
Emu68, PiStorm, PiAmiga itp.. w przeciwnym razie odpali się tylko starter z wyborem rozdzielczości

(jak komuś się chce to może potestować )

Ficzery:
- głownie zmiana algorytmu renderowania podlogi i sufitu na nowy, szybszy.. to chyba będzie już 4,
ale na razie ten jest najlepszy.
- textury na ścianach, podłodze i suficie
- wypalone lightmapy ze światłocieniami
- mip-mapy (256->32)
- "świecące pixele".


Wyniki:
- jak na razie najlepszy wynik jaki osiągnąłem na V1200. W 320x200 32-bit "rozgrywka"
jest płynna średni fps 35-45.
- przy czym musze zaznaczyć że jakbym wywalił lightmapy to byłoby na spokojnie dużo ponad 50 fps.


Jest też aktualizacja pierwszego posta: #1


Nowy filmik,
jest w nim opisany nowy algorytm z grubsza:




Co dalej:

- nowy algorytm ma tą wadę, że robi nadrysowywanie, ale nawet mimo to jest szybszy od poprzedniego, który tego nie robił.
Wydaje mi się, że nowy algorytm można jeszcze trochę zmienić, tj. olać zapisywanie list widoczności do pliku - robić to podczas rysowania ścian i wtedy też co prawda będzie nadrysowywania ale już mniej niż przy listach. No i plik z poziomem byłby mniejszy.
Jeśli takie rozwiązanie NIE BYŁOBY WOLNIESZE to byłoby lepsze. Ale to potem, na razie mi się nie chce.

- trzeba w końcu dorzucić nieregularne ściany. Dawno temu w pierwszej wersji juz mialem cos takiego, ale wywalilem zeby sie skupić na podstawach bardziej. fajnie by bylo też drzwi zrobić jakieś w końcu. Ale raczej tylko poziome.
Mam nadzieje ze z kolejnym v0.34 juz się pojawią

• Odpowiedz