@recedent, post #30

• Odpowiedz

@mateusz_s, post #31

• Odpowiedz

@mateusz_s, post #31

• Odpowiedz

@recedent, post #33

• Odpowiedz

@Norbert, post #32

• Odpowiedz

@mateusz_s, post #35

• Odpowiedz

@mateusz_s, post #35

• Odpowiedz

@recedent, post #30

• Odpowiedz

@waldiamiga, post #38

• Odpowiedz

@mateusz_s, post #39

• Odpowiedz

@waldiamiga, post #38

Udało się uruchomić na AmigaOS4.x z VooDoo3, półtorej klatki na sekundę i zielony ekran.

• Odpowiedz

@mateusz_s, post #39

• Odpowiedz

@mateusz_s, post #25

Zrobilem test u siebie na 060/Voodoo3.

Niestety rozdzialki 320x240x32 moj monitor nie zdzierzyl wiec wybralem 640x480.
Obraz wyswietlil sie w trybie super wide . Podejrzewam ze renderer masz zafiksowany na wysokosc 240.
W takim trybie uzyskalem wynik ok 3.2 FPS.

Moglem tylko patrzec gora/dol (strasznie czule) oraz obracac sie na boki. Kroku do przodu nie udalo mi sie wyczaic.

• Odpowiedz

@Phibrizzo, post #43

• Odpowiedz

@waldiamiga, post #44

• Odpowiedz

@waldiamiga, post #41

• Odpowiedz

@Phibrizzo, post #45

• Odpowiedz

@waldiamiga, post #41

Udało się uruchomić na AmigaOS4.x z VooDoo3, półtorej klatki na sekundę i zielony ekran.

• Odpowiedz

@MUFA-amigaone-pl, post #46

wczoraj troche testowałem, generalnie jest dziwna sprawa..

- w "małym teście" gdzie była tylko pętla i wyświetlanie po zamianie WIDTH i HEIGHT na u_int16 + unroll-loops + integer bufor był wzrost z 130 fps do 550 fps..

- wstawiłem wszystkie te poprawki w docelowym kodzie (który składa się z kilku plików i modułów i wiekszej ilosci obliczen)
ale fps nawet nie drgnał.. wieć coś jest ewidentnie zrąbane

- natomiast wyłączyłem podłogę i sufit i z 6 fps skoczyło do 60 fps.
- przy czym jeśli podszedłem blisko do ściany (czyli cały ekran był wypełniony) to fps spadł do 20 fps

- wieć problem chyba leży gdzieś tutaj..

na ten moment podłoga i sufit są rysowane w niezbyt oiptyumalny sposób tj. rysują cały ekran a dopero na to są rysowane ściany tam gdzie faktycznie są, więc jeżeli wypelnieni całego bufora czyli przejscie WIDTH*HEIGHT tak mocno go obciąza no to dodatkowe drugie to samo go zabija.. ale ewidentnie jest jakieś wąskie gardło gdzieś..

- no i przetestowałem fixując WIDTH i HEIGHT wpisanymi wartosciami też i też ZERO róznicy

- bedę sie skupiał na tym fragmencie teraz

- ale przetestuje też kompilatory inne,

• Odpowiedz

@michal_zukowski, post #42

• Odpowiedz

@mateusz_s, post #50

• Odpowiedz

@mateusz_s, post #51

• Odpowiedz

@mateusz_s, post #51

• Odpowiedz

@mateusz_s, post #53

*********
UPDATE
(taki tam średni UPDATE)

na razie jest lipton,
próbowałem na wszystkie sposoby
ale nie mogę przebić powyżej 5-6 fps (winuae 060 fastest bez JIT),
a na Vampirzach chodzi po ok 9 fps - więc odniesienie jest podobne...
no chyba ze sobie włącze JIT to mi śmiga 60 nawet w 640x480 ale nie tędy droga :)

- jeśli wyłączę sufit i podłogę - to w zależności od tego jak blisko jestem ściany mam 60-20 fps
- no sufit i podłoga są mocno nie optymalne - skupie się teraz chyba na optymalizacji tego algorytmu
- próbowałem wrzucić wszystko do jednego pliku, bo myślałem, że są jakieś problemy przy kompilacji,
bo niby mój pierwszy test wydajnościowy działał szybko.. ale nie było różnicy, no ale też w tym teście nie było tylu obliczeń.
- nie używam też jakiś ciężkich funkcji typu sqrt(), a dzieleń na floatach jest dość mało
- w międzyczasie moze jeszcze sprawdzę w tym środowisku Cubic IDE, bo sobie zamówiłęm ale jeszcze nie dostałem żadnego linka może jutro przyjdzie..

- czy w tym momencie jest sens konwertowania floatów na fixed-point? nie wiem.. jeśli mamy 040, 060 z FPU?


Natomiast udało mi się chyba znaleźć prawdziwe wąskie gardło, chodzi o pobieranie textela z textury i wpisywanie do bufora:

for (u_int16 ry = 0; ry < APP_requested_height; ++ry)
{
........
       // drawing floor and ceiling from left to right
        for (u_int16 ry_x = 0; ry_x < APP_requested_width; ++ry_x)
        {
                 ...........
               // get pixel coords in texture
            u_int32 texture_pixel_index = texture_pixel_x + texture_pixel_y * RC_texture_size_i;

            // draw into buffer
            u_int32 output_pixel_index = ry_x + ry * RC_render_width_i;

               // kolor pobrany z textury
               unsigned int tmp = GP_level_textures[texture_index].pixels[texture_pixel_index];

               // zapisuje wynik w buforze ekranowym
               my_buf_1[output_pixel_index] =
                                        (((tmp >> 16 & 0x0ff) * intensity_value) >> 8 ) << 16 |
                                        (((tmp >>  8 & 0x0ff) * intensity_value) >> 8) <<  8 |
                                        (((tmp       & 0x0ff) * intensity_value) >> 8);
         }
}

tmp to int który oznacza jakiś kolor, jeśli jest pobrany z textury - to fps jest z 6, jak go zafixuje na jakaś stałą wartość to skacze do ponad 400, jak zafixuje np. texture_pixel_index na 5000 to wzrasta do 50 itp..
czyli jak nie musi skakać po teksturze to jest znaczenie szybciej.. nie wiem czy to można jakość poprawić, textury były 128x128, potem zmieniłem na 64x64 - bez różnicy..

kolor w teksturze to też int 4 bajty, może jakby je zamienić na 256 indeksowany to by wzrosło..? nie potrzeba mi 24/32 textur dalem je bo nie chcilo mi sie wczytywać indeksowanych.


*******

Ostatnia aktualizacja: 15.03.2021 03:13:03 przez mateusz_s

Ostatnia aktualizacja: 15.03.2021 03:20:19 przez mateusz_s

• Odpowiedz

@mateusz_s, post #54

• Odpowiedz

@mateusz_s, post #54

• Odpowiedz

@kiero, post #56

• Odpowiedz

@Kefir_Union, post #57

• Odpowiedz

@kiero, post #58

Trzeba zrobić jedno i drugie równocześnie

• Odpowiedz

@Kefir_Union, post #55

@Kefir_Union

aaa.. ależ to oczywiste, nie zauważyłem, dzięki super pomysł z tym wywaleniem przed petle X

miałem co prawda potem umiescic juz prekalkulowane wartosci w tablicy zeby czytal po kolei ale możliwe że to bez sensu, przynajmniej bez wcześniejszego testu







Ostatnia aktualizacja: 15.03.2021 12:53:05 przez mateusz_s

Ostatnia aktualizacja: 15.03.2021 12:53:58 przez mateusz_s

• Odpowiedz