Tag: directx

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

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 10 11 >

# Coding Texture Preview

Sep 2009

Today is the 256's day of the year, so it's the Programmers' Day. Thus I wish all the best, especially a good code and no bugs to all of you who code for fun or/and profit (hopefully "and" :)

I've recently started new home project called "BlueWay". There's noting special about it - just another time I start everyting from scratch :) But this time I have deferred shading, cascaded shadow mapping, new scene management (based on k-d tree), new component-based object system and asynchronous resource manager (resources are loaded in the background on separate thread). I'm not sure whether I can call D3DXCompileShaderFromFile from separate thread without D3DCREATE_MULTITHREADED, but it seems to work OK :)

What I want to show today is a code for previewing textures. When coding some complex effects, it's often handy to look at intermediate results in render-target textures. Of course we have famous PIX and NVIDIA PerfHUD, but I believe that such custom code for real-time in-game texture preview is useful anyway. I wanted to make it general and flexible and here is the way I do it.

Read full entry > | Comments | #rendering #directx Share

# New DirectX SDK and Total Commander

Sep 2009

There are two new software releases that are important to me. I know about them from Twitter (yet another good reason to join microblogging activity :)

First one is DirectX SDK August 2009. Updates relate mostly to DirectX 11, but hey, there was no new SDK version for a long time!

(I've just discovered there are changes in the error handling system that are not backward compatible. To compile my code I had to change #include <dxerr9.h> to <dxerr.h>, link with file dxerr.lib instead of dxerr9.lib and rename function calls DXGetErrorString9 and DXGetErrorDescription9 to DXGetErrorString and DXGetErrorDescription.)

Second new release is Total Commander 7.5 FINAL. I can't see any revolutionary changes (despite the new, Vista-like behavior of the current directory bar), but that's a good news as Total Commander is already great.

Comments | #directx #software Share

# Cascaded Shadow Mapping

Jul 2009

When I was writing The Final Quest engine for my master thesis, I didn't manage to implement any technique to ensure good quality shadows in outdoor scenes. I've read about all these kinds of perspective reparametrization like PSM (Perspective Shadow Maps), LiSPSM (Light-Space Perspective Shadow Maps), TSM (Trapezoidal Shadow Maps) or XPSM (Extended Perspective Shadow Maps) and all that math behind them seemed very scary to me. Today I know that complexity of these techniques also causes some artifacts in particular cases and commercial games more often use simpler technique called CSM (Cascaded Shadow Maps).

Yesterday I've implemented CSM and I'm very glad with the results. Of course there are always some artifacts, aliasing problems and z-acne on some distant objects under particular surface angles, performance degradation (additional objects rendering to 3 x 1024 x 1024 textures must take some time) etc., but still its the first time I have not so bad outdoor shadows in my code. On the screenshot below you can see transitions between cascades marked with red arrows.

Cascaded Shadow Mapping

Read full entry > | Comments | #directx #rendering Share

# Thoughts on Display Settings

Jun 2009

I've decided to make a demo for this year's Riverwash demoscene party. For that purpose recently I've prepared my framework and coded loading of display settings from either command line parameters, configuration file or my brand new dialog box:

Coding it reminded me of my thoughts about display settings from user's versus programmer's perspective. User is usually able to change screen resolution and sometimes also change refresh rate, turn vertical synchronization on/off, toggle between fullsreen and windowed mode, choose antialiasting, texture filtering quality and some general quality/performance parameters. On the other hand, programmer passes bunch of parameters to Direct3D as D3DDPRESENT_PARAMETERS structure and other arguments to functions CreateDevice and Reset. The question is how to map between these parameters?

Here are my current beliefs on this subject:

[+] Adapter: I just pass D3DADAPTER_DEFAULT constant. Sure it would be better to give a choice of an adapter (one can enumerate adapters using IDirect3D9 methods), but it's useful only on multi-monitor systems and not many games expose such setting.

[+] DeviceType: I always pass D3DDEVTYPE_HAL. Using software reference rasterizer D3DDEVTYPE_REF makes no sense, as it gives SPF instead of FPS :)

[+] BehaviorFlags: Now I always pass D3DCREATE_HARDWARE_VERTEXPROCESSING. Using software or mixed verex processing made sense only on old hardware, especially on old Intel laptop graphics chips, which had Pixel Shader 2.0 but no Vertex Shader at all.

[+] BackBufferWidth, BackBufferHeight: I give a choice of display modes available on default adapter with format hardcoded as constant (D3DFMT_X8R8G8B8). One can enumerate available display modes using IDirect3D9 methods. In windowed mode it could also be reasonable to be able to set any given resolution (Width and Height as text fields), as well as manually resize application's window.

[+] BackBufferFormat: I just use D3DFMT_A8R8G8B8. Choice between X8R8G8B8 and A8R8G8B8 just the matter of having additional fourth channel available (alpha), which is obviously not visible, but can be written, used in alpha blending and thus utilized to do some special effects (like masking intensity of some effect in screen space).

[+] BackBufferCount: I just give 0 here, which resolves to default value of 1 back buffer. I'm aware that using value 2 can change the way rendering is performed a bit.

[+] SwapEffect: I always use constant D3DSWAPEFFECT_DISCARD, as it is the fastest one. It says that entire content of the back buffer can be discarded after frame was presented and program have to render new frame from scratch (which is what we always do in game development).

[+] AutoDepthStencilFormat: Direct3D defines many of them, but for real all the D3D9 generation hardware supports only three: D3DFMT_D16, D24X8 and D24S8. So the choice is only based on the decision whether we need higher, 24-bit precision or stencil buffer.

[+] Flags: For the best performance possible I always give D3DPRESENTFLAG_DISCARD_DEPTHSTENCIL and never give D3DPRESENTFLAG_LOCKABLE_BACKBUFFER.

[+] FullScreen_RefreshRateInHz: Nowadays, when many (most?) people have LCD displays, standard refresh rate is 60 Hz and maybe 75 Hz. In the CRT era setting good refresh rate was crucial for playing comfort and thus it was very annoying when a game didn't expose setting of refresh rate, but used default 60 Hz instead. I believe refresh rates should be enumerated and given as a choice next to the resolution.

[+] PresentationInterval: This is the value the "VSync" setting is converted to. It looks like D3DPRESENT_INTERVAL_DEFAULT behaves as VSync turned on (FPS <= RefreshRate) and D3DPRESENT_INTERVAL_IMMEDIATE means VSync off (FPS as high as possible), but once during my experiments I've observed that flag D3DPRESENT_INTERVAL_ONE behaves slightly different than D3DPRESENT_INTERVAL_DEFAULT (I can't remember the details now).

I know I would sound more "professional" if I considered all other constant values available and their possible uses, but I don't care :) My point here was to simplify the problem to be able to map these technical parameters to the display settings exposed to the user. Multisampling is separate subject so I don't cover it here.

Comments | #demoscene #directx #rendering Share

# Wycinanie komentarzy ze skompilowanego shadera

Feb 2009

Shader Direct3D skompilowany do kodu binarnego (np. funkcją D3DXCompileShaderFromFile) zawiera w sobie nie tylko instrukcje asemblerowe, ale i dodatkowe informacje - komentarze. Te komentarze nie są bezużyteczne. Tam zapisana jest np. tablica stałych, którą można odczytać funkcją D3DXGetShaderConstantTable. Jednak jeśli ona nie jest potrzebna, te komentarze można z kodu wyciąć i wtedy shader staje się dużo mniejszy.

Jak to zrobić? Choć trzeba grzebać wprost w pamięci, to nie jest trudne. Konkretny algorytm opisuje na swoim blogu Jesus de Santos Garcia we wpisie Stripping comments from Shader bytecodes. Ja tutaj streszczę go krótko swoimi słowami.

Format binarny skompilowanych shaderów D3D jest udokumentowany w MSDN, na stronie Direct3D Shader Codes. Składa się z sekwencji 32-bitowych tokenów. Ostatni z nich ma wartość 0x0000FFFF i oznacza koniec kodu. Komentarz natomiast rozpoczyna się tokenem 0x####FFFE, gdzie "####" (starsze dwa bajty) to liczba następujących dalej 32-bitowych wartości stanowiących treść komentarza. Takie komentarze można po prostu wyciąć z kodu shadera i gotowe :)

Comments | #directx #rendering Share

# Nowy artykuł - Preprocesor w shaderach HLSL

May 2008

W następnym artykule opisałem, jak używa się preprocesora w języku shaderów HLSL. Pisząc coś bardziej skomplikowanego niż pojedyncze efekty graficzne - np. silnik - na vertex shader i pixel shader trzeba czasem spojrzeć jak na zestaw ustawień, tak jak w starym dobrym Fixed Function Pipeline. Pojawia się taki problem, że każda kombinacja ustawień to powinien być osobny shader. W artykule przedstawiłem jedno z rozwiązań - kompilowanie kodu HLSL z użyciem proprocesora (#if itp.), z ustawieniami wpisanymi jako wartości makr. Zapraszam do lektury: Preprocesor w shaderach HLSL.

Comments | #rendering #productions #directx Share


May 2008

Jak wiadomo, tekstury nie muszą być kwadratowe, ale generalnie powinny mieć boki będące potęgami dwójki - tj. 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 itd. Ograniczenie to znoszą jedynie układy firmy nVidia z SM3 (od GF6), ale karty ATI z SM3 nadal je mają. Odpowiada za to flaga D3DPTEXTURECAPS_POW2 pola TextureCaps struktury D3DCAPS9.

Jest jednak taka sytuacja, kiedy to ograniczenie jest bardzo uciążliwe. Chodzi o użycie tekstury jako Render Target. Wówczas, jeśli powinna mieć co najmniej rozmiar ekranu, przykładowo dla rozdzielczości 1280 x 1024 musiałaby mieć rozmiar 2048 x 1024 i dużo miejsca by się marnowało.

Dlatego jakby specjalnie w tym celu, praktycznie wszystkie układy graficzne posiadają flagę D3DPTEXTURECAPS_NONPOW2CONDITIONAL, która pozwala na używanie tekstur o dowolnych rozmiarach pod pewnymi warunkami (opisanymi w DX SDK pod hasłem "D3DCAPS9"):

Comments | #directx #rendering Share

# DirectX Debug i dxcpl

May 2008

Jeśli masz zainstalowany DirectX SDK, możesz przestawić swojego DirectX w wersję Debug. W tym celu wybierz Start > Uruchom > "dxcpl" i w oknie 1. przesuń suwak "Debug Output Level" na przedostatni ząbek 2. przełącz na "Use Debug Version of Direct3D 9" 3. wciśnij "Apply".


DirectX w wersji Debug prawdopodobnie działa wolniej, dlatego nie zostawiałbym go tak na stałe, ale chwilowe przełączenie w ten tryb może się bardzo przydać. Po zrobieniu tego trzeba uruchomić swój program w trybie debugowania (w Visual C++ to będzie F5) i w czasie pracy programu albo po jego zakończeniu obserwować panel Output. Będą tam wypisywane różne ostrzeżenia i błędy, a wiele wywołań funkcji D3D może się wręcz nie udać, bo DirectX dużo lepiej sprawdza wszystkie dane i zależności.

Mnie w ten sposób udało się znaleźć nie tylko wiele błędów które powodowały niedziałanie programu, ale i takich rzeczy, które na mojej karcie graficznej działały mimo, że nie musiały. Na przykład blokowanie z flagą D3DLOCK_DISCARD zamiast 0 bufora, który nie miał D3DUSAGE_DYNAMIC, albo nawet używanie wypełnionego bufora dynamicznego do renderowania zanim go odblokowałem :)

Comments | #directx #tools Share

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

[Download] [Dropbox] [pub] [Mirror] [Privacy policy]
Copyright © 2004-2020