eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingdalsza optymalizacja › Re: dalsza optymalizacja
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.task.gda.pl!not-for-mail
    From: zażółcony <r...@c...pl>
    Newsgroups: pl.comp.programming
    Subject: Re: dalsza optymalizacja
    Date: Mon, 02 Apr 2012 10:40:16 +0200
    Organization: CI TASK http://www.task.gda.pl/
    Lines: 59
    Message-ID: <jlbole$p9j$1@news.task.gda.pl>
    References: <jl73ie$b6f$1@inews.gazeta.pl>
    NNTP-Posting-Host: efp194.internetdsl.tpnet.pl
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    X-Trace: news.task.gda.pl 1333356014 25907 83.14.249.194 (2 Apr 2012 08:40:14 GMT)
    X-Complaints-To: a...@n...task.gda.pl
    NNTP-Posting-Date: Mon, 2 Apr 2012 08:40:14 +0000 (UTC)
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327
    Thunderbird/11.0.1
    In-Reply-To: <jl73ie$b6f$1@inews.gazeta.pl>
    Xref: news-archive.icm.edu.pl pl.comp.programming:196534
    [ ukryj nagłówki ]

    W dniu 2012-03-31 16:15, generał kenobi pisze:
    > ten sposob rysowania rotowanej bitmapy jest fenomenalny
    > swoja prostota
    >
    > for(int j=0; j<sprite_height; j++)
    > {
    > for(int i=0; i<sprite_width; i++)
    > {
    > SetPixel( x>>20, y>>20, sprite[j][i] );
    >
    > x += dxdx; // skosy/ poprawki dla ruchu pixele na fiz ekranie
    > y += dydx; // dla ruchu po tekselach x++
    > }
    >
    > x += dxdy; // skosy dla y++
    > y += dydy;
    > }
    >
    > tu raczej nie da sie nic poprawic - ale chcialbym jakos moze
    > poprawic sama funkcje stawiania pixela

    Moim zdaniem właśnie tu możesz poprawić.
    Iteracje są z równym krokiem, są to więc funkcje liniowe,
    ściśle monotoniczne. Jak rysujesz wiersz to wystarczy, że jeden piksel
    wyjdzie Ci poza ekran, a już wiesz, że cała końcówka wyszła i nie musisz
    tego dalej renderować, idziesz do nast. wiersza.
    Niby trochę gorzej z lewą stroną, bo musisz wiedzieć, kiedy 'wejść
    na ekran', jak Ci obcina początek. Ale w gruncie rzeczy to jest
    podobny problem, wystarczy znaleźć jeden piksel, który jest w ekranie i
    jechać w prawo i w lewo od niego tak długo, aż nie wylezie poza ekran,
    reszta nas nie interesuje.

    Jak mi się zdaje, Twoje tekstury są bardzo duże, więc potencjalnie
    zawsze duża część może wyłazić poza ekran.

    A tak ogólnie, to imo najlepiej z góry sprawdzić, czy tekstura
    musi być poobcinana (clip), czy mieści się cała. Jak będziesz
    miał dużo małych tekstur i większość będzie całkowicie wchodzić
    w ekran to bez sensu jest robić te warunki. Robisz dwie
    osobne procedury - na maksa wydajna bez clippowania i ta, co
    masz wyżej - obcinająca. Przed renderowaniem sprita robisz
    test położenia wszystkich wierzchołków, jeśli wszystkie
    są w ekranie, to odpalasz bez żadnego clipowania maksymalnie
    prostą.

    A tak w ogóle, to Twój algorytm bym 'odwrócił'. Ty poszedłeś
    w kierunku takim, że każdy piksel tekstury wyświetlasz
    raz na ekranie. Ten algorytm wyklucza np. powiększanie a nawet
    przy samym obrocie jestem pewien, że już będziesz miał sitko
    z dziurkami. Przy pomniejszaniu będzie masakrycznie niewydajnie.

    Dlatego powinieneś robić to od drugiej strony: iterować
    po x/y ekranowych, a dx i dy powinny wskazywać kroki
    w teksturze. Dla każdego piksela ekranowego pobierasz
    z tekstury kolor i tyle. Wtedy clipowanie będzie również
    prostsze.
    Przy takim podejściu masz tylko troszeczkę trudniej, bo x i y
    ekranowe idą skosami, więc jest trochę więcej roboty w ustalaniu
    pierwszego x kolejnego wiersza.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: