Entries for tag "directx", ordered from most recent. Entry count: 92.
# The Concept of Immutability and Descriptor
Fri
27
Nov 2009
An object of some class represents a piece of data, chunk of memory or other resource along with methods to operate on it. It should also automatically free these resources in destructor. But how should modifying these data look like? There are two possible approaches. As an example, let's consider a fictional class to encapsulate Direct3D 9 Vertex Declaration (I'll show my real one in some future blog entry). A Vertex Declaration is an array of D3DVERTEXELEMENT9 structures, which can be used to create IDirect3DVertexDeclaration9 object. First solution is to define class interface in a way that data inside can be modified at any time.
class MyMutableVertexDecl { public: // Creates an empty declaration. MyMutableVertexDecl(); // Frees all allocated resources. ~MyMutableVertexDecl(); // Copies data from another object void CopyFrom(const MyMutableVertexDecl &src); // Deletes all internal data so object becomes empty again. void Clear(); bool IsEmpty() const; // I/O (Serialization) void SaveToStream(IStream &s) const; void LoadFromStream(IStream &s); // Reading of underlying data size_t GetElemCount() const; const D3DVERTEXELEMENT9 & GetElem(size_t index) const; // Modification of underlying array void SetElem(const D3DVERTEXELEMENT9 &elem, size_t index); void AddElem(const D3DVERTEXELEMENT9 &elem); void InsertElem(const D3DVERTEXELEMENT9 &elem, size_t index); void RemoveElem(size_t index); IDirect3DVertexDeclaration9 * GetD3dDecl() const; private: std::vector<D3DVERTEXELEMENT9> m_Elems; IDirect3DVertexDeclaration9 *m_D3dDecl; ... };
This approach seems very nice as you can create your object any time you wish and fill it with data later, as well as change this data whenever you need to. But at the same time, a question emerges: when to (re)create "destination" IDirect3DVertexDeclaration9 from the "source" D3DVERTEXELEMENT9 array? Each time the array is modified? Or maybe each time the IDirect3DVertexDeclaration9 is retrieved? Optimal solution for the interface above would be to do lazy evaluation, that is to recreate IDirect3DVertexDeclaration9 whenever it is retrieved for the first time since last time the D3DVERTEXELEMENT9 array have been modified. But...
Comments | #software engineering #directx #.net #physics #c++ Share
# Texture Shader for Generating Textures
Thu
22
Oct 2009
There was a discussion recently on our forum (in the topic [HLSL] Przekazywanie struktury ?!?) about shader performance and execution time of texture fetches versus arithmetic operations. When we need a sophisticated function that involves many costly computations in a shader, sometimes it is better to prepare a special texture to be sampled as a lookup table for values of this function. But how to generate such texture?
Of course you can write a simple console program, create Direct3D device of type D3DDEVTYPE_NULLREF, create a texture in the D3DPOOL_SCRATCH pool, fill its pixels and finally save it to a file. But there is another solution called Texture Shaders. It's not a new shader type introduced in DirectX 10/11/... It actually exists for quite a long time and is available in D3DX for generating textures with a shader. Such shader is always executed on CPU. If you are interested, look at functions D3DXCreateTextureShader, D3DXFillTextureTX and the ID3DXTextureShader interface.
Another good news is that you can utilize Texture Shaders without coding any program in C++. All you need is AMD RenderMonkey shader IDE. To generate a texture procedurally:
Here is my example:
Interesting curiosity: there is a intrinsic function in HLSL available only in Texture Shaders - noise, which generates Perlin noise.
Comments | #directx #rendering #tools Share
# Coding Texture Preview
Sun
13
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.
Comments | #rendering #directx Share
# New DirectX SDK and Total Commander
Thu
10
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
Sun
12
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.
Comments | #directx #rendering Share
# Thoughts on Display Settings
Tue
23
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
Thu
19
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
Thu
22
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.