Tag: directx

Entries for tag "directx", ordered from most recent. Entry count: 67.

Uwaga! Informacje na tej stronie mają ponad 5 lat. Nadal je udostępniam, ale prawdopodobnie nie odzwierciedlają one mojej aktualnej wiedzy ani przekonań.

Pages: > 1 ... 6 7 8 9 >

# Szarpanie gry

Fri
07
Dec 2007

Szarpanie gry to wredny błąd. Długo nie wierzyłem w ogóle w jego istnienie - dopóki sam go nie doświadczyłem w swoim kodzie, najpierw na laptopie, a potem również na blaszaku. Chodzi o sytuację, kiedy FPS-ów jest dużo, ale mimo tego animacja "szarpie". Powiązany z tym może być jest błąd opóźniania się obrazu za wejściem z myszki, doświadczany przy pisaniu GUI. Rozwiązania są różnorodne:

Comments | #directx #rendering #algorithms Share

# Alpha Testing kontra Shadow Mapping

Sun
18
Nov 2007

Alpha Testing to funkcja przydatna tam, gdzie skomplikowany kształt obiektu określają przezroczyste miejsca na teksturze zamiast układu geometrii - np. do rysowania drzew, trawy itp. Problem w tym, że taki alfa-test trzeba też wykonać przy rysowaniu obiektu do Shadow Mapy, Shadow Mapa jest często w formacie zmiennoprzecinkowym (np. R32F), a przy renderowaniu do tekstur w formatach zmiennoprzecinkowych ustawienia takie jak alfa-blending i alfa-testing często nie działają.

Rozwiązaniem jest napisanie sobie alfa-testu samemu w Pixel Shaderze za pomocą instrukcji anulującej rysowanie piksela - texkill. W języku HLSL odpowiada jej funkcja clip. Przykładowy kod wygląda tak:

// Zadeklarowane jest: out float4 Out : COLOR0
// Wypełniam Out, łącznie z kanałem alfa
// Zakładam granicę alfa = 128, czyli 0.5
// Na końcu Pixel Shadera dodaję:
clip(Out.a - 0.5);

Jeszcze większy problem z obiektami używającymi alfa-testu mają ci, którzy realizują cienie za pomocą drugiej techniki - Shadow Volume. Z inicjatywy Skalniaka próbowaliśmy niedawno przedyskutować tą sprawę w tym wątku forum.

Comments | #rendering #directx Share

# Shadery a sprawa preprocesora

Sun
19
Aug 2007

Fakt nr 1 - shadery warto pisać w HLSL albo innym tego typu języku. Kompilatory generują dobry kod, więc nie ma sensu babrać się w czystym asemblerze. Fakt nr 2 - shaderów potrzeba wiele. Najlepiej, żeby można było generować nowe shadery z różnych kombinacji jakiś swoich ustawień. Niektórzy radzą sobie bez tego, ale ja nie wyobrażam sobie jak. Shadery zastępują przecież niektóre ustawienia renderowania z dawnego nieprogramowalnego potoku i tak też na nie patrzę - jak na własny potok sterowany ustawieniami. Mają przy tym tą zaskakującą na początku nauki cechę, że nie można ich łączyć - na raz może być ustawiony jeden shader, który musi zawierać wszystko, co jest do zrobienia na wierzchołku albo pikselu.

Rozwiązaniem jest dołączenie do gry źródła shadera (np. pliku FX) i jego kompilacja w czasie ładowania albo w czasie samej gry, w razie potrzeby, z odpowiednimi ustawieniami. Jak odwzorować to w kodzie shadera? Opcje są dwie, a nawet trzy.

Ta, która dla mnie odpada natychmiast to skorzystanie z instrukcji warunkowych Static Branching. Po co marnować cenny czas na instrukcje sprawdzania warunku, który zawsze będzie niespełniony, jeśli można wygenerować osobny shader, który danego kodu po prostu nie zawiera?

Opcja pierwsza to wstawienie do kodu dyrektyw warunkowych preprocesora typu #ifdef (OPCJA == 1), gdzie OPCJA będzie makrem przekazywanym jako parametr podczas kompilacji shadera. Opcja druga to wstawienie do kodu warunków typu if (OPCJA == 1), gdzie OPCJA również będzie makrem. Obydwa rozwiązania wygenerują równie dobry kod. To drugie wydaje się przy tym bardzie eleganckie.

Niestety ma jedną wadę. O ile fragmenty kodu można objąć w if (OPCJA == 1), o tyle czegoś takiego nie można napisać dla pól struktury definiującej dane przekazywane z VS do PS. Tam natomiast muszą występować różne pola, niektóre nieużywane, zależnie od parametrów kompilacji danego shadera. Każde takie pole natomiast, nawet jeśli nieużywane, musi być wypełniane przez VS, choćby samymi zerami (swoją drogą - cóż za bzdura! - to powinno generować ostrzeżenie a nie błąd kompilacji), a to kosztuje dodatkową, niepotrzebną instrukcję w VS.

Toteż pozostaje objąć te nie zawsze wykorzystywane pola struktury w dyrektywy #ifdef. Skoro przy niektórych wartościach makr w ogóle ich nie będzie, to nie można też ich wtedy używać w kodzie. Tak więc warunki w kodzie też trzeba wtedy objąć w #ifdef zamiast w if. Co Należało Dowieść :) Tak też mam zrobione u siebie.

Comments | #rendering #directx Share

# Wchodząc w szczegóły

Thu
03
May 2007

Kot zadał na forum - w temacie Narzut BeginPass / EndPass - ciekawe pytanie dotyczące jak najlepszej (oczywiście z punktu widzenia wydajności) organizacji procesu renderowania obiektów w silniku, w którym wykorzystujemy mechanizm efektów FX. Temat jest o tyle ciekawy, że mnie również dotyczy :) Dlatego wszelkie odpowiedzi mile widziane.

Przy okazji padł link do ciekawego znaleziska - ktoś napisał sobie swoje My own little DirectX FAQ z kilkoma ciekawymi informacjami.

Jeszcze mały off-topic: Wszystkim kolegom piszącym w tym roku maturę życzę powodzenia i ocen dostatecznie wysokich, żeby dostali się na swoje wymarzone studia - bo w takim momencie chyba to jest dla młodego kodera najważniejsze. GL & HF :)

Comments | #rendering #directx Share

# Dobra dokumentacja na wagę złota

Fri
13
Apr 2007

Dokumentacja... Najbardziej znienawidzona część każdego programu. Prawie nikt nie lubi jej pisać, ale wszyscy wiedzą, że jest niezbędna. Dokumentacja jest tym, co najlepiej odróżnia prawdziwy, dopracowany program od eksperymentu/prototypu.

Dla odbiorcy danego programu (czy - przede wszystkim - biblioteki) dobra dokumentacja to nieoceniona pomoc. Zaawansowani tym się właśnie różnią od początkujących, że nie boją się do niej zaglądać, bo wiedzą, że znajdą tam systematyczny i szczegółowy opis każdej funkcji, jej działania i parametrów. Tylko czy na pewno kompletny?

MSDN zawsze pozostaje dla mnie pod tym względem wzorem. Ale już dokumentacji w DirectX SDK można co nieco zarzucić, szczególnie jej części poświęconej D3DX. Oprócz braku rozdziałów opisujących ogólnie sposób używania poszczególnych interfejsów doskwierają liczne drobiazgi. Na przykład:

D3DXMACRO Macros[MACRO_COUNT+1];
for (int i = 0; i < MACRO_COUNT; i++) {
  Macros[i].Name = // ...
  Macros[i].Definition = // ...
}
Macros[MACRO_COUNT].Name = NULL;
Macros[MACRO_COUNT].Definition = NULL;

Comments | #directx #philosophy #software engineering Share

# DirectX Ops

Fri
16
Mar 2007

Błędne działanie NVMeshMender

W skład pakietu DirectX SDK wchodzi m.in. ciekawe narzędzie, któremu dziś przyjrzałem się bliżej, a z którego chyba niewiele osób korzysta. Chodzi o dxops.exe. Ten napisany w C#, konsolowy programik "karmi się" skryptami zapisanymi w plikach tekstowych w prostym języku, w którym kolejne instrukcje mogę wczytywać, zapisywać oraz przetwarzać tekstury (we wszelkich obsługiwanych przez D3DX formatach) oraz siatki (w formacie X). Pośród możliwości programu warto wymienić:

Nie jest to w sumie nic ponad możliwości dostępne z poziomu funkcji D3DX, ale ich udostępnienie jako narzędzia nie wymagającego pisania kodu czyni ten program godnym uwagi.

Niestety z nieznanych mi przyczyn dxops źle generuje normalne dla moich siatek eksportowanych do formatu X z Blendera. Pozostaje więc NVMeshMender, który niestety też nie jest idealny (co pokazałem na załączonym zrzucie ekranu).

Comments | #rendering #directx #tools Share

# Wielbłądy

Sun
11
Mar 2007

Spędziłem wczoraj pół dnia na walce z dwoma wyjątkowo wrednymi błędami. Jednym z nich był błędny odblask specular - latał po powierzchni bez ładu i składu mimo że siatka była dobra i wzory na obliczenia też. Okazało się, że wektorów przekazywanych do pixel shadera, takich jak wektor kierunku do światła czy wektor połówkowy, nie należy w vertex shaderze normalizować. Heh, kto by na to wpadł nie wiedząc o tym wcześniej?

Drugi błąd sprawiał, że w pewnych bliżej nieokreślonych warunkach (ustawienia trybu graficznego, ilość renderowanej geometrii) niektóre obiekty znikały albo straszliwie migały pokazując się lub nie pokazując w poszczególnych klatkach. Najwidoczniej sterownik/karta nie czekała na opróżnienie kolejki przed zaprezentowniem danej klatki. Pomogło użycie IDirect3DQuery9 typu D3DQUERYTYPE_EVENT lub też - bardziej radykalnie - blokowanie i odblokowanie back buffera przed wywołaniem Present.

Tego rodzaju problemy i ich pokonywania (samemu czy z czyjąś pomocą - pozdro Krzysiek K.!) sprawiają, że takie programowanie wzbudza szeroki wachlarz skrajnych emocji. Podłoże matematyczne okazuje się być tylko podstawą i jego zrozumienie nie gwarantuje, że wszystko zadziała dobrze. A przecież na tym nie koniec - na jeszcze wyższym poziomie czeka problem sensownego zorganizowania całego programu, żeby to z czego się składa było jakoś poukładane, a nie tworzyło wielkiej kuli błota.

Comments | #rendering #directx Share

# Fixed Pipeline Lighting Demo

Wed
07
Feb 2007

Fixed Pipeline Lighting Demo to moja najnowsza produkcja. Właściwie nic konkretnego, a jedynie pokaz aktualnego kodu, który udostępniam z prośbą o przetestowanie. Chcę się przekonać, czy zgodnie z założeniami zadziała także na starym sprzęcie klasy GeForce 2, GeForce 3, GeForce 4 MX i Ti, ich odpowiednikach firmy ATI czy na zintegrowanych, laptopowych intelach - słowem na kartach, które nie mają Vertex Shader 2.0. Po pobraniu dema proszę zapoznać się z plikiem Readme.txt.

Przy okazji: Wygląda na to, że po chwilowej awarii mojego konta (zamiast strony było napisane, że konto jest zawieszone) strona przestała działać tak wolno jak to było od pewnego czasu i teraz działa już bardzo sprawnie.

Comments | #rendering #productions #directx Share

Pages: > 1 ... 6 7 8 9 >

STAT NO AD
[Stat] [STAT NO AD] [Download] [Dropbox] [pub] [Mirror] [Privacy policy]
Copyright © 2004-2019