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

@BULI, post #270

Ps.

Z takich przyszłościowych pomysłów:

- chciałbym jeszcze zoptymalizowac kod detekcji rysowania ścian i byc może co za tym idzie szybszego szukania punktów do rysowania podłóg.

- zrobić test z jakimiś lightmapami. Taka light mapa mogla by mieć tylko 32x32 i można by uzyc istniejących prekalkulowanych colormap. Jasność lightmapy byłaby indexem do kolormapy danej intensywności. Ale zakładam że fps by mocno spadł więc to tylko tak dla ciekawości.

- z geometrycznych rzeczy to tylko bym chciał dorzucić bloki o różnej szerokości i ewentualnie skośne ściany. No i drzwi. Sprajtow jeszcze nie dotknąłem, ale skoro pamięć jest to fajnie by zrobić z kilku kątów zeby mieć iluzję 3d. Im więcej tym lepiej.

- z ciekawości chciałbym załadować jakąś kolomape do trybu 8bit chunki i sprawdzić wydajność gdy zamiast uzupełniać bufor 4 bajtami to tylko jednym. Innymi słowy jak bardzo w kosc daje tryb 32bit w porównaniu do chunky.

- fajny efekt by dały jakieś color blending np. Glow czy flare tak jak w Genetic Spieces, ale obliczanie blendingu to raczej kosztowna opracja perpixel więc chyba szkoda czasu.

- można z mipmapami sprobowac zeby zmniejszyć pixeluzacje w 320x200, w 640x400 jest ok z grubsza.

- Skoro już zacząłem algorytmem raycasting to się będę go trzymał z tego co zauważyłem bsp
Z doom jest raczej szybsze.
1
[#272] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@BULI, post #270

Dzięki @Patapik za kompilacje pod POWER PC,
pod G5 wyszło w rozdzielczosci 1650x1050 ok 150 fps, więc bardzo pięknie!

-----------------------------------------------------------------
----LINK DO WERSJI POWER PC (textury 256x256) -------

https://mstanisz.website.pl/tmp/amiga/RAYPPC.ZIP

-----------------------------------------------------------------





Ostatnia aktualizacja: 15.01.2022 18:26:33 przez mateusz_s
3
[#273] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #272

Tu z kolei mamy konfigurację TF1260 + Radeon i ładnie ponad 30 fps, ale coś pixele wariują.

http://eab.abime.net/showthread.php?t=106646
1
[#274] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #273

Jeszcze chciałem na szybko sprawdzić tą technikę Lightmaps,
w sensie, że podczas tworzenia mapy można "wypalić" światło-cienie
do osobnej 1 bitowej textury np. 32x32 pix na kafelek.

Można by tym osiągnąć ciekawe efekty - ładne cieniowanie.

Czy jest sens dla rozdzielczosci 320x200? nie wiem myslę ze troszkę by dodatkowego klimatu zyskało
(a poprzed dodatkowe sciemnianie moze zredukowalo pixeloze), natomiast już w 640x400 jest cacy.

Jeśli chodzi o pierwszy test - to jest tak sobie.. same ściany były ok, nastomiast jak doszły podlogi i sufity
to troche wydajosc dostala kopa w tyłek.. na V1200 z 45fps spadlo do 30 wiec średniawka..

Jeśli chodzi o Banchmark to można by zostawić to jako opcję przy włączaniu.. nie wiem jeszcze czy uda mi sie to zoptymalizować, ale teżn ie bedę się upierał.. wole mieć szybszy silnik niż na siłę zamulony..


Obrazek z pierwszego testu - docelowo powinno być również uwzględnione istniejące cieniowanie, ale na razie tak zrobiłem


jak widać. tam gdzie mały miękkie gradienty jest fakjnie, nie nadaje sie ten rozmiar 32x32 do ostrych cieni lub masek..




Ostatnia aktualizacja: 17.01.2022 01:06:53 przez mateusz_s
5
[#275] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #272

Widzę, że w tym archiwum jest wersja PPC ale pod MorphOs'a.
Czy może ktoś to skompilować z zaznaczona opcją WOS?
1
[#276] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@BULI, post #275

Niestety ja osobiście, póki co nie ogarniam morphosa i WOS, więc nie dam rady. Nigfy nie mislem z tym kontakyi, nie wiem do końca nawet czym jest WOS? ;) .. ale z tego co zauważyłem rekompilacja z aos3.1 do aos4.1 czy morphos to nie problem bo nie trzeba było niczego zmieniać..
1
[#277] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #276

WarpOS, konkurecyjny do PowerUpa system dla kart PowerPC. Obecnie jedyne sensowne SDK dla WarpOSa jest pod MorphOSem więc jak ktoś chce kompilować pod WarpOSa to musi mieć MorphOSa.
[#278] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@michal_zukowski, post #277

Ale zaraz, przecież Morphos i AmigaOS 4+ są tylko pod PowerPC.. to po co tam jeszcze jakiś WarpOS czy PowerUP? To jakieś nakładki?
[wyróżniony] [#279] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #278

Phase5 wydało BlizzardaPPC i CybernStormaPPC, do nich dołączono system zwany PowerUP (typ pliku elf, autor Ralph Shmidt), z uwagi na jego niedopracowanie w 97 roku, Sam Jordan i firma H&P stworzyli system WarpOS (typ pliku amigowy hunk z dołączonym kodem ppc). Następnie Phase5 dopracowało PowerUPa, który okazał się stabilniejszy i lekko szybszy od WarpOSa, ale WarpOS dorobił się emulatora (wrappera) PowerUPa i wygrał wyścig o palme pierwszeństwa.

Format plikowy PowerUP po lekkich zmianach stał się formatem plików MorphOSa, format WarpOSa został pominięty i przestał być używany, AmigaOS4 wykorzystał ELFy jako pliki binarne.

MorphOS ma emulację PowerUPa i WarpOSa, AmigaOS4.x ma emulacje Warposa z tym, że przez około 10 lat nie działała ona na części maszyn (np. na Sam460, chyba dopiero teraz zaczeli to ogarniać, mufa może dać więcej info).

Jeśli chodzi o kompilatory to dla PowerUPa było GCC oraz SASC (wersja 7 finalna i pożegnalna), dla WarpOSa był gcc jako standalone i jako część pakietu StormC. Dodatkowo potem powstał VBCC ogarniajacy wszystkie systemy.

W polowie drugiej dekady XXI wieku Dennis Boom przygotował swoja wersje WarpOSa, które działa na kartach PCI podłączanych pod mediatora (np. Sonnet 7200, Bigfoot K1), więc ludzie sie lekko na to rzucili i Warpos znow wrocil do łask, z tym że jednocześnie powstał SDK dla Warposa będący nakładką na SDK MorphOSa więc jest możliwość używania najnowszych kompilatorów, binutilsów etc pod MorphOSem i generowanie binarek dla WarpOSa. Z ciekawszych rzeczy to powstał port Quake3 i jest on możliwy do uruchomienia na A1200 z BVision oraz 256 mb ramu i w gruncie rzeczy do momentu Emu68 to te karty z PPC w mediatorze dawały największą prędkość w klasyku bijąc na głowę biedarozwiązania w stylu wampira (tzn teraz też dają, ale juz nie wszystkie bo emu68 bije te wolniejsze). Minusem tych kart jest to, że rynek wysechł i karty chodzą po wiele wiekszych kwotach niż pare lat temu. Elbox natomiast pracuje nad nową wersją mediatora, który umozliwi wykorzystanie mostkow pcie-e -> pci, wiec będzie mozna wykorzystać teoretycznie jeszcze karty pcie z powerpc (np. Bigfoot killer 2100).

Ostatnia aktualizacja: 20.01.2022 02:07:07 przez michal_zukowski
4
[#280] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@michal_zukowski, post #279

No ładny manual WOS'aOK
Krótko dodam od siebie, Dennis Boom- przekozak OK pokłony
Rzokol, zrobisz jak sugerowałeś kompilacje pod WOS'a? Please
[#281] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #272

U mnie zarówno na iMacu G5, jak i PowerBooku G4 (oba na R300) z MorphOS 3.15 pojawiają się artefakty.
Podrzucam fotkę, bo grabber to średnio ogarnia.






Ostatnia aktualizacja: 22.01.2022 22:00:36 przez waldiamiga
1
[#282] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@waldiamiga, post #281



Hej, dzięki za test.. pewnie trzeba lepiej to pod morpha przeportować to było tak na szybko na libsach aos3.x sprawdzic czy kompilator to łyknie w takiej formie. Generalnie jest ok, jest jakby efekt odwróconych poligonów. Ale prędkościowo było zacnie..

Ostatnia aktualizacja: 23.01.2022 20:43:10 przez mateusz_s
[#283] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #282

Nawet na QEmu jest szybko, ale również z błędami. Emulowana karta to ATi Rage 16MB.


1
[#284] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #274

Ciągnę dalej temat z lightmapami - chce zobaczyć efekt w działaniu..

Tu musze powiedzieć że jak te 8 czy 9 miesiecy temu zaczynalem sie bawić raycastingiem
to chciałem właśnie ten efekt na Amidze osiągnać.. no i jakoś dopero teraz się udało :P

Musiałem dodac do edytora dwie opcje exportu:
- export modelu 3d mapy z koordynatami zwykłych textur (to w przypadku jakbym chciał
użyć jakiejś danej textury z mapy jako źródła światła)
- i export modelu 3d z koordynatami każdej ścianki osobno.. zeby każda scianka miała swoją texturę.




- do wyeksportowanego modelu w programie np. 3ds max wrzucam sobie swiatla itp. tu przykaz calej mapki z góry z renderingu.





- następnie wypalam ten render to textury wg tych uv osobych dla kazdej scianki, ponizej przykład, jak widać niewielkie pomieszczenie zajęło tylko trochę całej textury. DAłem na sztywno jej rozmiar 2048x2048 - wiadomo że powinno to być płynne w zalezności od ilości scianek ale doświadczenie pokazało że jesli nie zafixuje bitmapy to dodatkowe obliczenia zeżrą mi więcej wydajności, wiec na razie zostaje stał rozmiar.




- początkowo miałem jakiś problem z seamami uv, które psuły cały efekt





- ale podczas exportu zwiekszyłem prezycje obliczania koordynatów do 5 po przecinku i jest raczej ok, obrazek pokazuje model mapy w 3d
z nałożoną wypaloną texturą (nie ma tuż żadnych świateł)..





- teraz muszę to nałożyć w raycasterze..
myślę, że na początek nałoże same te lightmapy żeby zobaczyć efekt.. OK



Ostatnia aktualizacja: 30.01.2022 01:45:25 przez mateusz_s
9
[#285] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #284

Podsyłam pierwszą próbę, nie najgorzej ale seam-y ciagle widoczne - może po nałożeniu na nie textur tych zwyklych nie beda tak widoczne, wydaje mi sie ze to problem z prezycją pixeli na podłodze i chyba nie wiele bede mogl zrobić..

co ciekawe efekt jest calkiem fajny bo nie ma pixaelizacji rzucającej się w oczy, to daltego ze wszsytko jest dość gładkie a kazda textura ma 32x32 do lightmap oczywiście to wystarcza,

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

@mateusz_s, post #285

Jeszcze jeden test..
właściwie nie trzeba by już nawet dodawać distance shading + side shading + bright pixels,
bo niezle wyglada, jeszcez ich nie zdazyłem zmiskować..



Ostatnia aktualizacja: 01.02.2022 19:55:41 przez mateusz_s

Ostatnia aktualizacja: 01.02.2022 19:55:48 przez mateusz_s
3
[#287] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #286

Zmiksowałem te wszystkie rodzaje cieniowania,
poniżej filmik, ponieważ zmieniłem w strukturach pliku int8 na int16
to pod Amigą coś mi się źle wgrywało, i nie wiem dlaczego zmiana kolejnosci nie zadziałała,
dlatego wyjątkowo filmik z wersji PC..

szwy na podłodze nieco poznikały, ale nie do końca (tu problemem jest zawijanie textur na ostatnim pixelu)

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

@mateusz_s, post #287

Te problemy na brzegach mogą byś powodowane przez 2 rzeczy:
- błędy zaokrągleń.

Nie wiem czy robisz poprawne zaokrąglenie U/V przy zaokrąglaniu (znajdywaniu pozycji ekranowej na podstawie liczby float lub fixedpoint) X rysowanej linii poziomej. Takie coś nazywa się subpixel correction (jest sporo materiałów na ten temat w internetach). Jeżeli rysujesz każdy kafel podłogi jako wielokąt to powinieneś też tą korekcję robić dla X/Y przy zaokrąglaniu Y. Pomaga to niesamowicie jeżeli chodzi o płynność animacji renderowanych wielokątów. Eliminuje 'skakanie'.

- filtrację (jeżeli ją robisz)

Nawet przy interpolacji dwuliniowej możesz mieć problem z dokładnością i pobierać próbki po prawej/na dole które teoretycznie nie powinny być używane. Dosyć powszechny problem.

Jako szybki workaround to mogę polecić ci dodanie ramek dla każdego kafla. Z tego co pamiętam masz tam 32x32 piksele, więc spróbowałbym dodać do każdego z nich 2 pikselową ramkę. Po prostu poprzez powielenie wartosci brzegowych kafla. Oczywiście będzie cię to kosztowało nieco miejsca/ramu, ale koszt renderingu nie wzrośnie.
2
[#289] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@kiero, post #288

Dzięki za podpowiedź.
Koordynaty liczone z fixed pointow.
Tu chyba chodzi o maskowanie bitowe
Które zawija wartość do początku.

Myślałem tez o tym obejściu (padding) ale nie pomoze
Bo uv się wracają do początku textury czyli pierwszy pasek
Textury musiałby mieć identyczny kolor jak ostatni.
1
[wyróżniony] [#290] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #289

Jeżeli chodzi o pierwszy punkt, to wyobraź sobie taką sytuację.
Masz współrzędne wierzchołków kafla jako fixed point. Dla każdego z nich masz jakieś wartości UV. Teraz jeżeli chcesz narysować ten kafel to musisz jakoś zaokrąglić X/Y do współrzędnych ekranowych. Jeżeli robisz to przez obcięcie bitów, to efektywnie przesuwasz ten kafel o ułamkową wartość (każde zaokrąglenie to będzie jakieś przesunięcie). Problem w tym, że jednocześnie robisz to samo z U/V (przesuwasz, bo są one 'przyklejone' do X/Y). Co powinieneś zrobić, to znaleźć wartości U/V dla tego zaokrąglonego punktu. Wygląda to trochę jak obcinanie odcinka. Mój rasteryzer ma w kodzie coś takiego (dla X/Y):

isubpixel = ceil(vtx_y1) - vtx_y1; // <- część 'ułamkowa', fixedpoint, jako różnica pomiędzy zaokrągloną wartością a wartością oryginalną

corrected_vtx_x1 = vtx_x1 + (vtx_x2 - vtx_x1) * isubpixel; // <- poprawna wartość początkowa X dla 'obciętej' wartości Y

"(vtx_x2 - vtx_x1) * isubpixel" to jest 'pre-stepping' wartości, tak jakbyś wyrenderował jedną linię ale o wysokości <1pxl

Anyway, tak jak pisałem w internetach jest sporo informacji na ten temat.

Co do punktu drugiego to nie wiem w czym problem. Po prostu w jednym wierszu tej dużej tekstury nie trzymasz szerokość/32 kafli a szerokość/(32+2+2) kafli. To samo dla wysokości. Każdy kafel ma swoje ramki i prawa strona nie 'zachodzi' na lewą. Oczywiście jeżeli używasz tego upakowania które pokazywałeś. Jeżeli każda mała tekstura 32x32 to osobna tekstura, to po prostu zrób ją o wielkości 28x28 i dodaj 2pxl ramkę.
W obu przypadkach oczywiście musisz wtedy UV przesunąć o 2/32 dla każdego wierzchołka, tak aby ta ramka wychodziła poza kafel.
2
[wyróżniony] [#291] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@kiero, post #290

Dzięki,
jeszcze się będę temu przyglądał..

Bo wiesz tutaj nie mam typowo sytuacji z rendera 3D..

Wygląda to tak:
- przechodzę po każdej lini pionowej widocznego kafelka ystart-yend (wsp. pixeli na ekranie)
- następnie przez xstart-xend (wsp. pixeli naekranie) każdej pionowej linii
- obliczana jest pozycja rzeczywista xstart i xend na podstawie ich pozycji na ekranie (rzut promieniem przez
pixel na ekranie)
- na tej postawie jest obliczany 'krok' i ilosc tych krokow ile ich nalzey dodać do xstart zeby dojść do xend (specjanie zamiast interpolacji)
- wyniki są we floatach, ale zamieniem je na fixed pointy w tym momencie, żeby w najbardziej wewnetrzej pętli
gdzie pixele są plotowane działać na integerach zamiast floatach (duże przyśpieszenie)
- u i v są obliczane na podstawie "ułamkowej części" fixed pointów.. tj. trzeab je popnożyć przez wielkosc textury ale też zamieniać z FP na INT - i tu się coś kaszani - ale na pewno jest to jakoś do poprawienia,
chodzi też o to żeby nie zrobić zamulającego kodu w tej częsci, teraz to wygląda tak (wersja bez lightmap)

#define IO_TEXTURE_SIZE						256
	#define IO_TEXTURE_SIZE__SUB1				255
	#define IO_TEXTURE_SIZE__MUL__SUB1			65280	// 256 * 255
	#define IO_TEXTURE_SIZE__BITSHIFT			8
	#define IO_TEXTURE_SIZE__BITSHIFT_x2		16		
	#define IO_TEXTURE_SIZE__BITSHIFT_FP18		10		//  ((<< 8) >> 18)			=  (>> 10)
	#define	IO_TEXTURE_SIZE__BITSHIFT_2x_FP18	>> 2    //  (((<< 8) << 8) >> 18)	=  (>> 2) 


while (draw_length-- > 0)
{
    int32 texture_pixel_index = ( (floor_x__fp >> IO_TEXTURE_SIZE__BITSHIFT_FP18      ) & IO_TEXTURE_SIZE__SUB1     ) + 
                                             ( (floor_y__fp    IO_TEXTURE_SIZE__BITSHIFT_2x_FP18   ) & IO_TEXTURE_SIZE__MUL__SUB1);

   floor_x__fp += floor_step_x__fp;
   floor_y__fp += floor_step_y__fp;

   *output_buffer_32__ptr++ = texture_intensity_colortable__ptr[ ceil_texture__ptr[ texture_pixel_index ] ];
}
1
[#292] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #291

Generalnie zastanawiam się teraz co by tu z tym silnikiem zrobić..

Jeśli chodzi o grafikę to hyba zostane przy samych lightmapach i wywale reszte cieniowania
nie ma teraz dużej różnicy, a robi się ciemniej i byłoby szybciej.
2
[wyróżniony] [#293] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #292

To przyciemnienie na odległości trochę za mgłe robi, i dodaje klimatu. Jak byś coś horrorowatego z tego chciał zrobić, to pewnie lepiej z dodatkowego cieniowania nie rezygnować OK
2
[wyróżniony] [#294] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #291

Ja wszystko rozumiem, ale specjalnie nie dawałem przykładu konkretnie pod rendering trójkątów tylko starałem się (jak widać słabo) wyjaśnić idee. Wszystko co napisałem można odnieść do twojego sposobu renderingu (idea dla trójkątów jest identyczna). Tu nie chodzi absolutnie o to jak wygląda pętla główna, ale o to jak przygotowuje się dane dla niej. Twoja pętla wyglądałaby identycznie, a jedynie floor_x__fp oraz floor_y__fp są wstępnie modyfikowane (pre-stepping) używając różnicy pomiędzy zaokrąglonymi współrzędnymi ekranowymi a współrzędnymi wejściowymi.

Zobacz np to wideo . Mniej więcej 30 sekunda. Zwróć uwagę na to jak płynny jest ruch oraz na górną krawędź. Zauważ, że delta dla pozycji X krawędzi jest identyczna POZA pierwszą linią. To właśnie dlatego, że pierwsza linia jest wstępnie przesunięta uwzględniając wartość o którą została zaokrąglona pozycja Y. Zasada dla dla U/V jest identyczna, i powoduje że tekstura płynniej/dokładniej rusza się razem z kaflem.

Anyway, dużo prościej będzie dodać padding...
2
[#295] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@kiero, post #294

Dzięki będę testował
1
[#296] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #295

Dorzuciłem mip-mapping zeby zobaczyć jak wpłynie na pixelizacje i migotanie w lowres.
Efekt nie najgorszy.. ale to chyba ślepa uliczka, to dodatkowa pamieć a może wystarczy zrobić tak jak w starych grach - czyli dawać mniej skomplikowane textury, bez tylu detali, prostsze z wiekszymi elementami, moze troche stylizowane..

tutaj zrobiłem zejście 5 stopniowe, tj. 256 - 128 - 64 - 32 - 16
Textury zmniejszałem w photoszopie z filtrem jakimś rozmywającym,
skalowanie takie zwykłe co drugi pixel daje kiepski efekt.

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

@mateusz_s, post #296

ja tam bym sie nie ograniczał co do pamięci chyba, że bedzie to wymagało więcej niż 64 mb ramu
1
[#298] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@michal_zukowski, post #297

Myślę że max 15-16 MB
To już w latach '00 miałem 64mb
[#299] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #298

no to jaki problem z teksturami skoro te mniejsze za dużo nie zajmą, zwolnić nie zwolnią
1
[#300] Re: [C, RTG] Moje Raycasterowe zabawy, progresy, testy..

@mateusz_s, post #296

Uhm, nie skaluj co drugi piksel, bo to nie o to chodzi;) Wtedy dalej masz potworny aliasing ale po prostu 'wypalony' w teksturze. Najczęściej mipmapy generuje się używając po prostu uśredniania wartości w bloku 2x2. Czasami też z konfigurowalnym delikatnym wyostrzaniem. Ja bym to skalował w kodzie (o ile masz w kodzie też remapping z 24bit->8, bo z tego co pamiętam tekstury mają palet 256 kolorów).

Druga kwestia. Oglądałem ten film, i problem z niepoprawnym zaokrąglaniem imo psuje efekt. Nie tylko na podłogach ale i na ścianach masz na teksturze widoczne coś ala 'ząbki'. Tak jakby tekstura była przesunięta o jeden piksel w górę/dół. Jeżeli zaimplementujesz poprawnie pre-stepping dla U/V (która to tam u ciebie jest w pionie) to ładnie się wszystko "wyczyści". Wrzuć kiedyś wszystko na jakiś github;)
2
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