kategoria: ANSI C
[#211] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@arturB, post #210

yeah !

magiczna bariera 30-35 fps przekroczona!

a do optymalizacji zostały jeszcze ściany i ich zamiana z float na fixed point
co powinno dać kopa jak pokazały poprzednie boje,
kto wie może otrę się nawet o 50 fps :)

*dotyczy testu na karcie V1200 oczywiście, 320x200x32 bit



Ostatnia aktualizacja: 16.11.2021 00:52:32 przez mateusz_s
[#212] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #211

i filmik Ray-21:





mozna pobrac i odpalić (wymaga trybu 32 bit)
http://mstanisz.website.pl/tmp/amiga/ray-21.zip
1
[#213] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #212

MEGA! A jak to idzie na natywnym AGA?
[#214] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@arturB, post #213

MEGA! A jak to idzie na natywnym AGA?

nie idzie :D przynajmniej na razie

od poczatku skupialem się na "nowych" akceleratorach typu V1200 z RTG i 32 bit
i chcialem zobaczyc ile sie uda mi wyciagnać

potem można oczywiście jakoś to przerobić na chunky i AGA ale nie wiem jak xDD
1
[#215] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #214

Grafika jest chyba po prostu w 32 bitach. Ciężko by było robić szybką remapę do 256 kolorów i jednocześnie c2p. Może PiStorm+Emu68k by jakoś wyrobiło tylko po co.... skoro ma działające RTG (chociaż być może jest inny format pixela). Na MOSie/AOS4 powinno szybko chodzić nawet w większych rozdzielczosciach, dzięki dobremu JIT.
1
[#216] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@pisklak, post #215

Formaty pixela są wykrywane na początku i do pamieci juz idą w prawidłowej kolejności więc działa na każdym formacie. Z 32 do 24 to nie problem, po prostu robie w 32 zeby cały czas operować na 4 bajtach.
[#217] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #212

Sprawdzilem na 060/66MHz + Voodoo3:
320x240 - mocne 10fps
640X480 - 3 fps

Zauwazylem ze wykrywanie kolizji ze scianami jeszcze nie jest uwzglednione.
2
[#218] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@Phibrizzo, post #217

Dzięki za test, na tych starszych hardware to chyba bida będzie przy 32bit, bo to już sporo danych na klatkę trzeba przesłać, ale jeszcze coś powinno podskoczyć jak zoptymalizuje ściany.. ale żeby płynnie chodziło to musiałoby być te 8bit..
[#219] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #218

zauważyłem, że Pan Michał Schulz, odpalił demko na Emu68.. niezłe wyniki w różnych rozdziałkach xDD
nawet w 2K się uruchomiło i nie zawiesiło, duma :)

4
[#220] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #219

Obecny proces rysowania wszsytkiego (w tym podłog i sufitów) wygląda tak..




Stoję w miejscu od jakiegoś czasu, bo staram się zoptymalizwaoć jeszcze ten proces
rysowania poglod i sufitów, bo jest na to miejsce, ale mi na razie cał czas jakieś glicze i babole
się pojawiają więc ślećzę nad tym.. proces rysowania krok po kroku pozwala zobaczyć
czy przypadkiem nie rysuje czegoś nie potrzebnie, tzn. czy nic się nie nadpisuje jedno na drugie itp?
4
[#221] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #220

udało mi się zrobić dużą optymalizację powyższego algorytmu od rysowania podłóg i sufitów
z referencyjnej sceny z 32 fps skok do 42 fps.. na V1200 oczywiście, 32 bit w 320x200,





generalnie pomyka bardzo płynnie na tych parametrach, fps wacha się w zależności od ujęcia,
np. blisko ścian ma cos ok 60-70, przy mniejszych przestrzenaich np. 50.

tak srednio wychodzi ze 40 może..

Jak Komuś się chce odpalić na swoim hardware to podaje linka
(odpalamy tylko wersje w 32 bit)
http://mstanisz.website.pl/tmp/amiga/ray-25.zip


ps. obecne textury maja rozmiar 128x128, na spokojnie mozna je podmienić do 256x256,
nie wplywa to na wydajnosc, ale troche dluzej się wgrywa, efekt jest ładny raczej jak sie podejdzie nieco blizej scian
lub spojrzy na podloge, sufit

zobacze czy jeszcze uda mi sie cos zoptymalizowac i postaram sie przygotowac jakaś łądniejsza planszę z fajnymi texturami,
może juz w 256x256



Ostatnia aktualizacja: 14.12.2021 01:56:05 przez mateusz_s
6
[#222] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #221

Jeszcze na gorąco.. zamiast 42 FPS mam 47 FPS !!!!

chciałem poeksperymentować z ChangeScreenBuffer, żeby pozbyć się tearingu,
okazało się, że w tym wypadku majac dwa bufory zmienia się tylko na nie wskaznik
podczas tej operacji a memcpy, ktrego wczesniej uzywałem (przy jedenym buforze)
jest nei potrzebne.. 5 dodatkowych FPS zleciało z nieba po prostu..

co do screen tearingu mam wrazenie ze nadal jest ale jakby"inny" niz poprzednio
byc moze jeszcez trzeba inaczej z tymi sygnałami coś albo waitTOF użyć, poniżej to co mam obecnie:

(opierałem się tu na opublikowanym fragmencie NovaCodera, ale coś miał tam zrypane i nie działało
i pomogłem przykłądem z http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node02A1.html
tam jest WaitBlit jeszcze, ale to chyba tylko pod AGA, a pod RTG? WaitTOF?

main loop
{
	 if (! _safeToWrite)
		while(! GetMsg(_dispPort)) Wait(1l<<(_dispPort->mp_SigBit));

	    _safeToWrite=TRUE;

// render
 EM_Update_And_Render(&APP_main_loop);

	    if (! _safeToChange)
		while(! GetMsg(_safePort)) Wait(1l<<(_safePort->mp_SigBit));
	    _safeToChange=TRUE;

 if (ChangeScreenBuffer(APP_screen, _hardwareScreenBuffer[_currentScreenBuffer]))
  {
          // Flip.
          _currentScreenBuffer = _currentScreenBuffer ^ 1;
		  EM_prefs.current_dbuffer_index = _currentScreenBuffer;
       }

	    _safeToChange=FALSE;
	    _safeToWrite=FALSE;
}


Ostatnia aktualizacja: 14.12.2021 18:36:50 przez mateusz_s

Ostatnia aktualizacja: 14.12.2021 18:37:02 przez mateusz_s
2
[#223] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #222

OK

Nio to czas na ray-26.zip :)
[#224] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #222

WaitBlit czeka na aktualnie trwająca jedną operację blittera, więc WaitTOF. Tylko on raczej poczeka na vblank czipsetu, sprawdź czy nie ma analogicznej funkcji w api RTG.
[#225] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@teh_KaiN, post #224

WaitTOF() nie jest potrzebny przy podwójnym buforowaniu z użyciem DBufInfo/ScreenBuffer. To czekanie na DispMessage załatwia sprawę synchronizacji animacji. Komunikat DispMessage dochodzi gdy wyświetlono aktualny bufor przynajmniej raz.

P.S. Przy okazji wspomnę, że w przypadku OCS/ECS/AGA zamiast DispMessage polecam używać przerwanie Coppera. Sprawdza się wyśmienicie.

Ostatnia aktualizacja: 14.12.2021 21:27:18 przez Hexmage960
[#226] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@Hexmage960, post #225

mały problem się zrobił, gdyż na jednym z testów Emu68 ta nowa wersja a ChangeScreenBuffer
zlagowała całość ze 170 do... 20 :) i to jak już wywaliłem dla testu te czekania na sygnał,
wieć w samym ChangeScreenBuffer jest jakieś czekadełko..

ale zdaje się że wywalę w ogóle tą komendę i zrobie potrójne buforowanie
i sam bede zmieniał wskazniki zobacze jak to wyjdzie..

nie ma jakieś wielkiej biedy w samej grze z tego powodu,
ewentulanie coś spraprałem w tym kodzie co jest bardzo możliwe
moze poszukam jakis referencji jeszcze

czy właściwie można coś tu ugrać? RTG nie wspomaga żadnych mechanizów synchronizacji na
nowych monitorach, jedne chodzą w 60 inne w 75 a ja mam ustawione na 100hz na przykład,
także chyba cieżko coś tu bedzie ugrać, lepie dać cała parę w silnik :)

Ostatnia aktualizacja: 14.12.2021 22:18:07 przez mateusz_s
[#227] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #226

Z tego co sobie przypominam, to kiedy pisałem trochę pod BVisionPPC trzeba było zrezygnować z czekania na SafeMessage, bądź DispMessage, żeby animacja była płynna.

Możesz też spróbować gołego DBufInfo do podwójnego/potrójnego buforowania. Jest szybsze. Sam używam stale aktualnie DBufInfo + SafeMessage + przerwanie Coppera na linii 0 dla płynnej animacji na OCS/ECS/AGA i z czystym sumieniem mogę polecić.

- Moja metoda polega na utworzeniu UCopList (copper-listy użytkownika),
- dodaniu instrukcji CWAIT(0,0) i CMOVE(custom.intreq, INTF_SETCLR|INTF_COPER).
- Następnie tworzę własny serwer obsługi przerwania Coppera, w którym sygnalizuję mój Task, gdy mój ViewPort jest widoczny.
- Teraz czekam w pętli głównej na to przerwanie, przełączam bufory za pomocą ChangeVPBitMap(), czekam na SafeMessage i rysuję.
- Opcjonalnie SafeMessage możemy obsłużyć niezależnie w pętli obsługi sygnałów. Ważne wtedy jest, by robić ChangeVPBitMap po odebraniu SafeMessage.

Moja metoda gwarantuje w pełni płynną animację.

Ja myślę, że najlepiej, jak zapytasz Kiero o kwestię animacji w RTG. On się na tym doskonale zna, jest autorem wielu dem działających na AGA i RTG.

Ostatnia aktualizacja: 14.12.2021 22:53:40 przez Hexmage960
[#228] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@Hexmage960, post #227

dzięki.. ciężka sprawa..
sprawdze ten ChangeVPBitMap jeszcze
to "ręczne" zmienianie wskazników to chyba tak nie zadziała bez tej funkcji jednak,
w kazdym razie mi nie działa


Ostatnia aktualizacja: 15.12.2021 00:43:21 przez mateusz_s
[#229] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #228

Ps. Ok chyba już wiem jak to zrobić, posiedzę nad tym jutro.. znaczy dzisiaj bo już 02:30

Ostatnia aktualizacja: 15.12.2021 02:28:04 przez mateusz_s
1
[#230] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #226

Tylko, ze to jest najprawdopodobniej techniczny problem PiStorma ze on sie dlawi a nie uzytego algorytmu. Byly robione testy porownawcze na innych kartach turbo? Blizzard, Cyberstorm, Warp czy V2? Moze nawet na V4.

Ostatnia aktualizacja: 15.12.2021 11:40:42 przez Don_Adan
[#231] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@Don_Adan, post #230

Był jakiś bug ze sterownikiem picasso w emu68, ale już naprawiony.
[#232] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #229

Próbowałeś podwójnego buforowania z użyciem ScrollVPort()?

http://aminet.net/package/docs/help/GameDev-Guide
[#233] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@forge, post #232

Nie, dzięki za linka zerknę..
[wyróżniony] [#234] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@forge, post #232

Mogę przysiąc, że kolega Kiero proponował jednak nowsze rozwiązanie od ScrollVPort(), czyli właśnie ChangeScreenBuffer().

O, znalazłem nawet mój wątek z 2009 roku: https://www.ppa.pl/forum/programowanie/15671/-os4-cgx-jak-zsynchronizowac-do-ramki. Stare dzieje.

Nie jestem pewien, jak jest ze sterownikami do Picasso96.

Kiedyś udało mi się przepisać grę z Amigi klasycznej, by działała w okienku pod Amiga OS4, ale już nie pamiętam jak to zrealizowałem. Pamiętam tylko, że przekierowałem wszystkie funkcje rysujące do RastPortu.
[#235] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@Hexmage960, post #234

haha, tak też go czytałem, a potem szukałem przez godzinę bo nie mogłąm znaleźć bo zamknałem
przegladarkę :)

ale końcowo zamiast Change Screen Buffer używam ChangeVPBitmap, z tego co wyczytałem
ta pierwsza bardziej nadaje sie do GUI i ona zawiera w sobie tą drugą.

ChangeVPBitmap wymusza zmianę adresu pamieci graficznej dzieki czemu ta podmiana wskazników jest możliwa (np. na Vampiorach nie trzeba jej uzywac i tylko podmieniac wskaznik)

@Hexmage960
zerknij proszę, wyciągnąłem jakiś stary mój kod z blitz basica z potrojnym bufforowaniem sprzed roku chyba xD , tam było wykorzystane przerwanie vblank jako osobny task do wykonania wyswietlenia zeby nie blokować petli

ja teraz w C zrobiłem tak, ale nie widzę nie tyko żadnej poprawy, ale też żadnej róznicy:

void Task__Display()
{
	WaitTOF();
	switch(curr_buffer)
	{
		case 0:
			show_buf = 1;
			break;
		
		case 1:
			show_buf = 2;
			break;
		
		case 2:
			show_buf = 0;
			break;
	}

	ChangeVPBitMap(&APP_screen->ViewPort, bmp[show_buf ], myDBI);
}

// a w głownej pętli mam tylko render i zmiene curr_buff:
 
...

 RenderDoBitmapy[curr_buf];

  curr_buffer++;  
  if (curr_buffer > 2) curr_buffer = 0;

...
[wyróżniony] [#236] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #235

Nie używałem nigdy potrójnego buforowania, więc nie mam tu żadnej wiedzy ani doświadczenia.

Podam Ci jak ja robię podwójne buforowanie z użyciem ChangeVPBitMap() w podejściu systemowym (bez Coppera). Ten kod powinien się nadać do potrójnego buforowania (ale nie jestem pewien).

Ten WaitTOF() jest niepotrzebny według mnie. Jeśli chcesz mogę Ci też podać wersję z Copperem.

Zakładając, że ViewPort (ekran), DBufInfo, bitmapy i porty mamy utworzone:

void Pętla(struct ViewPort *vp, struct DBufInfo *dbi, struct BitMap *bm[])
{
	struct MsgPort *safeport = dbi->dbi_SafeMessage.mn_ReplyPort;
	struct MsgPort *dispport = dbi->dbi_DispMessage.mn_ReplyPort;
	BOOL safeToDraw = FALSE, safeToChange = FALSE;
	UWORD frame = 0;

	ULONG safesig = 1L << safeport->mp_SigBit, dispsig = 1L << dispport->mp_SigBit;

	ChangeVPBitMap(vp, bm[frame], dbi);

	while (!done)
	{
		ULONG result = Wait(safesig|dispsig);

		if (result & safesig)
		{
			if (!safeToDraw)
			{	
				while (!GetMsg(safeport))
				{
					WaitPort(safeport);
				}
				safeToDraw = TRUE;
			}
			/* Tutaj można rysować */
		}
		
		
		if (result & dispsig)
		{
			if (!safeToChange)
			{	
				while (!GetMsg(dispport))
				{
					WaitPort(dispport);
				}
				safeToChange = TRUE;
			}
			ChangeVPBitMap(vp, bm[frame], dbi);
			safeToDraw = safeToChange = FALSE;

			/* Tutaj zmieniamy "frame" na indeks nowego bufora */
		}	
	}
}


Ostatnia aktualizacja: 15.12.2021 20:27:01 przez Hexmage960
[#237] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@Hexmage960, post #236

dzięki, spróbuję.. tzn nie zebym sie upierał przy triple buffer, po prostu nie zauwazylem ŻADNEJ roznicy
cokolwiek bym nie robił.. wiec cos robie nie tak.. przetestuje Twój kod, moze mi się coś rozjaśni..

ten tearing u mnie jest glownie widoczny jak się "sunie" po scianach nie ma jakiegoś bólu,
ale wiadomo warto sprobowac cos poprawić..
[#238] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@Hexmage960, post #236

chyba sie nie da nic z tym zrobić..

bo dałem na chama WaitTOF() a po nim wyświetlanie gotowej ramki, wszsytko w pętki glownej,
fps zwolnił czyli oczekiwał.. natomiast na ekranie nie zauwazylem znowu rożnicy, miałem tearing jakby w 3 miejscach.. w trybie 320x200 mam ustawione odsweizanie monitora na 100hz, jak zmniejszylem do 60hz
to już tylko widzialem taki normalny tearing co dzielił skośnie obraz na dwie czesci.. a 50 hz juz nie moglem wyświetlić, wiec chyba taki wniosek ze odswiezanie z rtg leci w 50hz o ile nie gadam glupot skoro przy 60 hz tearing nadal jest

no nie wiem.. przy grach lowres z AGA przez indivision nie mam tearingów przy odświeżaniu 100hz

no wiec tu jest cala masa zmiennych (jak choćby monitor ktory odswiaza 60, 75, 100 itp)

nie mam na to pomysłu.. zostawie ten ten niech leży.. przynajmniej udalo mi sie ominać kopiowanie ramki na rzecz zamiany wskazników przez co odstalem w prezencie dobrych kilka fps..
1
[#239] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #237

dzięki, spróbuję.. tzn nie zebym sie upierał przy triple buffer, po prostu nie zauwazylem ŻADNEJ roznicy
cokolwiek bym nie robił.. wiec cos robie nie tak..


Nie za bardzo rozumiem, co dla Ciebie jest ten triple buffer. To są trzy bufory, które sobie przełączasz ? Czy kryje się za tym jakaś dodatkowa antyczna wiedza, której nie widzę ?
[#240] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@asman, post #239

z tego co słyszałem, jeśli gierka generuje klatki dość szybko to 3 bufory się powinno zastosować
a jak np. generuje 100 fps to i cztery.. zwykle stosowałem dwa na zmianę w roznych projektach

sam nie testowałem nigdy, teraz po prostu testuje..

w tym momencie dzięki uprzejmości @Arcziego
udało się naprawić ten tearing, na razie tylko na V1200, "tylko" ponieważ,
Vampiry pozwalają zmieniać bezpośrednio wskaźnik do ramki
i jego hardware pomoc już nie pozwala żeby zmiana nastąpiła w połowie itp.

mam teraz punkt odniesienia, i sparuje z systemowymi komendami raz jeszcze,
no i jakiś babol miałem u siebie w kodzie :-/ wiec poprzednie testy moge wyrzucic do kosza..
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem