@mateusz_s, post #330

Pojawił się pierwszy teścik
- Warp1260 @ 105mhz i w 320x240..
w końcu "grywalne".. w sensie działa całkiem płynnie



Ostatnia aktualizacja: 26.08.2022 20:53:54 przez mateusz_s

Ostatnia aktualizacja: 26.08.2022 20:54:16 przez mateusz_s

Ostatnia aktualizacja: 26.08.2022 20:56:51 przez mateusz_s

• Odpowiedz

@mateusz_s, post #331

• Odpowiedz

@selur, post #332

• Odpowiedz

@buldogkekon, post #333

• Odpowiedz

@mateusz_s, post #334

• Odpowiedz

@buldogkekon, post #335

• Odpowiedz

@mateusz_s, post #336

ehhhh...

włąśnie wyjebałem do kosza dwa tygodnie roboty ktore spedzilem na tym generatorze potencjalnie widzialnych framgentow mapy w edytorze ktore zapisywałem do pliku..

.. teraz robie to dynamicznie podczas szukania ścian, prędkość ta sama, a plik z poziomem kilka razy mniejszy hehe.. no i mozliwe ze troceh mnij jest nad-rysowywania ehhh xD bo na liście zawsze bylo kilka fragmentów więcej..

jeszcze mam jedną optymalziacje do sprawdzenia kurła, nie skończe chyba nigdy haha

• Odpowiedz

@mateusz_s, post #337

edit:

ok, obie optymalizacje się udały, i coś tam jeszcze zdołałem urwać.. ale nie zawracm już gitary,
i dam to w kolejnej wersji v.034

one przyszły mi dosłownie dzień po tym jak skończyłem v0.33

czyli, jak już wspomniałem:

1. tworzenie listy widocznych kafelków mapy można robić dynamicznie podczas raycastowania ścian -
i tak przez nie przechodzimy, trzeba je tylko na liste dodać. Plusy są dwa:
+ nie trzeba tego robić w edytorze i zapisywać do pliku wiec plik z poziomem jest dużo mniejszy.
+ ilość widocznych kafelków mapy jest lub może być mniejsza niż na wygenerowanej w edytorze liście, przez co rysujemy mniej rzeczy.

2. była spora redundancja obliczeń podczas renderowania podlogi i sufitów, udało mi się to jakoś bezboleśnie "cache-ować" w trakcie - obliczenia są wykonywane raz i potem używane w miare potrzeby.

3. no i było małe niedopatrzenie przy ścianach, nie potrzebnie wykonywało się kilka obliczeń..

OK, mam nadzieje że to już koniec optymalizacji.. chciałbym coś do przodu ruszyć,
w sensie dodać nieregularne ściany i drzwi..

• Odpowiedz

@mateusz_s, post #338

• Odpowiedz

@mateusz_s, post #339

• Odpowiedz

@mateusz_s, post #340

Udalo mi się w końcu pozbyć "szwów" pomiędzy lightmapami na podlogach




to o czym pisalem tutaj kiedyś:
https://www.ppa.pl/forum/programowanie/42708/moje-raycasterowe-zabawy-progresy-testy/10#m742765

• Odpowiedz

@mateusz_s, post #341

-- mały UPDEJT --


Pijcie ze mno kompot


Po 1,5 roku zabawy, odkąd wrzuciłem tu pierwszego posta, mogę powiedzieć że chyba udało mi się dojść do etapu w któym nie tylko zrobiłem wszsytko co sobie założyłem ale i z nawiązką.

Tak, tak.. już chyba ze dwa razy tak pisałem, po czym przychodziłem z nowym algorytmem i robiłem od nowa :)

Ale coś czuję, że to właśnie teraz doszedłem do momentu, że "core" w postaci ścian i podłóg jest na tyle zoptymalizowany ze mogę to zostawić i zacząć dodawać jakieś kolejne, bardziej konkretne rzeczy.

Nie mówię bezpodstawnie, bo ostatnio na V1200 miałem ok. średnio 36 fps na refencyjnej scenie,
natomiast po ostatnich poprawkach mam ok. 50 fps. a skacze i do 60 albo i wiecej - wiadomo w zależności co akurat widać.
Co oznacza że na Warp1260 i ewentualnie TF1260 (z rtg) było by na ten moment na luzie z 25 fps.

Wprowadziłem DWIE istotne optymalizacje:

++ Rendering podłóg i sufitów. W pionie, tj. z lini na linię jest pixel normalnie 1:1,
ale już w poziomie wstawiam na raz DWA PIKSELE. Różnica jakościowo właściwie żadna, a spory przyrost.
(można by jeszcze zrobić taki myk, że flaty któe są daleko rysować co 4pix, musze to jeszcze sprawdzić)

++ Wysokość screena jest zmiejszona o wysokosć potencjalnej belki informacyjnej
(taka retro belka z ammo, health itp), w przypadku 320x200 ma ona 40 pixeli, więc silnik renderuje 320x160, przy wyższych rozdzielczościach bedzie ona proporcjonalnie wieksza.


Jeszcze z ciekawostek:

1. Poprawiłem zaokrąglanie float na int. W kilku miejscach korzystam z float-ów, ale do tej pory zawsze wszystko zaokrąglałem w dół poprzez rzutowanie (int). Dopiero sobie to uświadomiłem . Żeby uzyskać dokładniejsze trzeba było dodać wcześniej +0.5f, tak jak się to robi normalnie.

W efekcie uzyskałem chyba "sub pixel rendering", dobrze mówię? W każdym razie wszystko rysuje się bardzo płynnie i tak samo reaguje na drobne ruchy myszki. Dodatkowo w ten sam sposób poprawiłem koordynaty textur, dużo lepiej to teraz wszsytko wygląda.

Pisał mi kiedyś o tym @kiero tutaj w kontekście tych szwów między lightmapami. Przy lightmapach jak pisałem w poprzednim poście wina była gdzie indziej. Natomiast ta sprawa z dokładnym zaokrąglaniem float do int jest też ważna i duża zmienia wizualnie.


Wrzucam podglądowe video z V1200 z opisywanymi zmianami:
https://www.youtube.com/watch?v=yVAxSXM_5pU





Z takich rzeczy co chce dalej porobić do aktualnej wersji:

1. Najpierw znowu poprawić edytor
2. Plik z poziomem zrobić bardziej dynamiczny żeby był mniejszy rozmiar.
3. Potem dodać inne rodzaje ścian - wtedy nie będzie to już taki kwadratowy labirynt ale można by tworzyć ciekawsze poziomy, nadal jednopoziomowe ale ciekawsze.
4. Te zasrane kolizje ze ścianami dodać.
5. Poprawić ruch - akceleracja/deakceleracja.
6. Drzwi by się w końcu przydały :)
7. Co do textur to zdecydowałem się na zmianę żeby były mniejsze rozmiary: mipmapy będą od 128 do 32.
Kolorów na texture 64, ale odcieni zmienie chyba z obecnych 128 na 256, skoro i tak robie pod RTG to niech będzie ładnie cieniowane.

Ostatnia aktualizacja: 12.09.2022 13:12:09 przez mateusz_s

• Odpowiedz

@mateusz_s, post #342

Pierwsze podejście do c2p. Można przetestować pod AGA.
(moje pierwsze w życiu c2p )



Tzn. są tylko kolory bez textur na razie. Ale sposób w jaki pixele są układane w buforze
jest taki gdyby były tektury, tj. nie wrzucam np. całej linii naraz, tylko pixel po pixelu (tak jak przy texturach).




-- PROŚBA o TESTY pod AGA, wymagania to: procesory 040/060 --
-- PROŚBA o TESTY pod AGA, wymagania to: procesory 040/060 --
-- PROŚBA o TESTY pod AGA, wymagania to: procesory 040/060 --



- Dajcie znać ile Mhz ma Wasz procek i ile FPS na początku pokazuje licznik
- podczas uruchamiania wybierz pierwszą pozycję z okienka: PAL 320x256

link:
http://mstanisz.website.pl/tmp/amiga/msRay-34_AMIGA__AGA.zip

DZIĘKI!

powinno być coś takiego:



Ostatnia aktualizacja: 14.09.2022 21:05:27 przez mateusz_s

• Odpowiedz

@mateusz_s, post #343

wyglada jak "Za Zelazna Brama 2"

• Odpowiedz

@selur, post #344

• Odpowiedz

@mateusz_s, post #345

• Odpowiedz

@mateusz_s, post #345

Hej, bardzo ładnie to wygląda. O wiele schludniej i płynniej niż wersja z 24-bit teksturami.

Serdecznie gratuluję Ci efektów pracy!

• Odpowiedz

@Hexmage960, post #347

@hexmage Dzięki


Na a4000 z 060/50 MHz średnio trzyma 20fps
Niezły wynik bo nie widać aż takiej różnicy
Teraz pomiędzy v1200 na której średnio trzyma 25fps.
Pewnie WaitTOF () blokuje i sam transfer do chip.

Ostatnia aktualizacja: 15.09.2022 12:46:41 przez mateusz_s

• Odpowiedz

@mateusz_s, post #348

-- PROŚBA o TESTY pod AGA, wymagania to: procesory 040/060 --
-- PROŚBA o TESTY pod AGA, wymagania to: procesory 040/060 --
-- PROŚBA o TESTY pod AGA, wymagania to: procesory 040/060 --

Podrzucam jeszcze trochę szybszą wersję bez synchronizacji bez WaitTOF(),
na V1200 skoczyło z 25fps do 35fps.

- Dajcie znać ile Mhz ma Wasz procek i ile FPS na początku pokazuje licznik
- podczas uruchamiania wybierz pierwszą pozycję z okienka: PAL 320x256

http://mstanisz.website.pl/tmp/amiga/msRay-34_AMIGA.exe__AGA_bezTOF.zip



Ostatnia aktualizacja: 15.09.2022 14:04:43 przez mateusz_s

• Odpowiedz

@mateusz_s, post #349

Kolejny TEST..

tym razem udało się odpalić w pod AGA w trybie HAM8, ponad 10 000 kolorów,
co ciekawe działa dość "szybko"...

(na pewno szybciej niż AB3D w którego grałem na gołej A1200 w latach 90 )

Tutaj cały wątek co i jak, podziękowania dla @kiero:
https://www.ppa.pl/forum/programowanie/44677/-c-asm-gcc-i-osobna-funkcja-w-asemblerze-jak-to-polaczyc

link do pliku exe:
https://mstanisz.website.pl/tmp/amiga/msRay-34__HAM8_AGA.zip



Ostatnia aktualizacja: 17.09.2022 23:23:42 przez mateusz_s

• Odpowiedz

@mateusz_s, post #350

fiu fiu

• Odpowiedz

@marianoamigo, post #351

Proboje dodawac nieregularne sciany - na początek "cienkie ukośne",
potem jeszcze "boxy-kolumny"

• Odpowiedz

@mateusz_s, post #352

Zaczyna się w końcu robić mniej kwadratowo
ściany skośne chyba działają prawidłowo, nie zauwazylem jakiegoś mega obciążenia, więc git..



Ostatnia aktualizacja: 01.10.2022 23:01:50 przez mateusz_s

• Odpowiedz

@mateusz_s, post #353

• Odpowiedz

@mwb113, post #354

• Odpowiedz

@mwb113, post #354

• Odpowiedz

@mateusz_s, post #356

• Odpowiedz

@mateusz_s, post #343

• Odpowiedz

@BULI, post #358

Wersja od HAM8 działa całkiem płynnie na 060 60mhz, ale coś jest nie tak ze sterowaniem, gdy wciskam klawisz 'W' (do przodu) postać idzie do przodu i w prawo, albo jest wrażenie, że środek perspektywy znajduje się po prawej stronie a nie na środku ekranu.
Ładnie wygląda działa w rozdziałce 640x256

Ostatnia aktualizacja: 03.10.2022 09:17:37 przez BULI

• Odpowiedz

@BULI, post #359

Trzeba wybrać 1280x256 HAM po prostu

• Odpowiedz