Tag: directx

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

Warning! Some information on this page is older than 5 years now. I keep it for reference, but it probably doesn't reflect my current knowledge and beliefs.

Pages: > 1 2 3 4 ... 8 >

# Lower-Level Graphics API - What Does It Mean?

Jun 2015

They say that the new, upcoming generation of graphics API-s (like DirectX 12 and Vulkan) will be lower-level, closer to the GPU. You may wonder what does it exactly mean or what is the purpose of it? Let me explain that with a picture that I have made few months ago and already shown on my two presentations.

Row 1: Back in the early days of computer graphics (like on Atari, Commodore 64), there were only applications (green rectangle), communicating directly with graphics hardware (e.g. by setting hardware registers).

Row 2: Hardware and software became more complicated. Operating systems started to separate applications from direct access to hardware. To make applications working on variety of devices available on the market, some standards had to be defined. Device drivers appeared as a separate layer (red rectangle).

Graphics API (Application Programming Interface), like every interface, is just the means of communication - standardized, documented definition of functions and other stuff that is used on the application's side and implemented by the driver. Driver translates these calls to commands specific to particular hardware.

Row 3: As games became more complex, it was no longer convenient to call graphics API directly from game logic code. Another layer appeared, called game engine (yellow rectangle). It is essentially a comprehensive library that provides some higher-level objects (like an entity, asset, material, camera, light) and implements them (in its graphical part) using lower-level commands of graphics API (like mesh, texture, shader).

Row 4: This is where we are now. Games, as well as game engines constantly become more complex and expensive to make. Less and less game development studios make their own engine technology, more prefer to use existing, universal engines (like Unity, Unreal Engine) and just focus on gameplay. These engines recently became available for free and on very attractive licenses, so this trend affects both AAA, as well as indie and amateur game developers.

Graphics drivers became incredibly complex programs as well. You may not see it directly, but just take a look at the size of their installers. They are not games - they don't contain tons of graphics and music assets. So guess what is inside? That is a lot of code! They have to implement all API-s (DirectX 9, 10, 11, OpenGL). In addition to that, these API-s have to backward compatible and not necessarily reflect how modern GPU-s work, so additional logic needed for that can introduce some performance overhead or contain some bugs.

Row 5: The future, with new generation of graphics API-s. Note that the sum width of the bars is not smaller than in the previous row. (Maybe it should be a bit smaller - see comment below.) That is because according to the concept of accidental complexity and essential complexity from famous book No Silver Bullet, stuff that is really necessary has to be done somewhere anyway. So lower-level API means just that driver could be smaller and simpler, while upper layers will have more responsibility of manually managing stuff instead of automatic facilities provided by the driver (for example, there is no more DISCARD or NOOVERWRITE flag when mapping a resource in DirectX 12). It also means API is again closer to the actual hardware. Thanks to all that, the usage of GPU can be optimized better by knowing all higher-level details about specific application on the engine level.

Question is: Will that make graphics programming more difficult? Yes, it will, but these days it will affect mostly a small group of programmers working directly on game engines or just passionate about this stuff (like myself) and not the rest of game developers. Similarly, there may be a concern about potential fragmentation. Time will show which API-s will be more successful than the others, but in case none of them will become standard across all platforms (Vulkan is a good candidate) and GPU/OS vendors succeed in convincing developers to use their platform-specific ones, it will also complicate life only for these engine developers. Successful games have to be multiplatform anyway and modern game engines do good job in hiding many of differences between platforms, so they can do the same with graphics.

Comments | #gpu #rendering #directx Share

# DirectX 12: What We Already Know?

Jun 2015

I am very excited about the upcoming DirectX 12. I have always been standing on the side of PC, Windows and DirectX. Currently I code in DirectX 11 on Windows 7 at home. Upcoming Windows 10 with free upgrade from version 7 and 8 (and the Start menu back on its place) looks like a good system. Together with it, a new version of DirectX will be released. Let us summarize general information about this new graphics API that are publicly available at the moment.

Here are some interesting links:

First and foremost: Direct3D 12 Graphics @ msdn.microsoft.com. Microsoft says "these information relate to pre-released product and may be substantially modified before it's commercially released", but you can already find there all Direct3D 12 Programming Guide and Reference, so basically the whole API is already public and you can start learning it.

Social Media:

General information:

Slides and videos from conferences:

Videos and screenshots from some working applications already shown:

Comments | #windows #directx Share

# Nothing Renders - Why?

May 2015

"I have a blank screen" or "nothing is rendered" is probably the most frequent bug in graphics programming. It's also quite hard to debug because there are many possible causes. Graphics pipeline is compilated, so there are multiple things that can be wrong at each stage. Few years ago I've written a short article about this, in Polish, titled Nic nie widaŠ. This is translation of that article. It provides a list of questions you should ask yourself while considering the most frequent reasons for why nothing appears on the screen. It is dedicated for Direct3D 9, but it can also be applied to OpenGL (only some things are named differently) and, to some degree, to newer graphics API-s.

It's black

First of all, please clear your background to some color other than black, e.g. gray or blue. Maybe your geometry is rendered, but it is black. It is a frequent bug, especially if you have lighting enabled (and it is enabled by default) while you didn't setup any lights.


Are you sure you correctly setup all matrices - world, view and projection? Did you create them using correct functions? Is the camera located in the right place and looks in the desired direction? Maybe your object is in the same position as camera or behind the camera, which is pointing backward?


Is the size and position of your object correct? Is your object too close or too far from the camera, relative to the minimum and maximum Z value set in projection matrix? Isn't it too small to be visible?


Do all the calls to DirectX functions return a value meaning success? Do you even check that value? Please also launch "DirectX Control Panel", enable Debug Layer for your application and analyze Output for any error or warning messages.

Vertex Format

Do you use correct vertex format? Did you define a structure describing your vertex correctly and compatible with the FVF/vertex declaration that you use? Are all the fields in the correct order and of the right type? Do you tell DirectX what vertex format you want to use by calling SetFVF/SetVertexDeclaration before rendering?

Draw Call

Do you pass correct parameters to the rendering function? In the most basic case, all offsets should be 0 and "stride" is the size of your vertex structure, in bytes, like sizeof(SMyVertex). Do you pass correct number of primitives to render?


Do you fill your vertex and (optional) index buffer correctly? Do they have correct number of elements? Do you fill all of them? If you use transformed coordinates XYZRHW, the RHW component should be set to 1.0 and never to 0.0.

Alpha Channel

Maybe your geometry is totally transparent. Is the alpha channel set to maxium (1.0 or 0xFF, depending on type) and not to minimum in all of these: vertices, texture, material (only if you use lighting)?

Backface Culling

Maybe the triangles you want to render are ignored as "back facing" the camera, because they have wrong winding (clockwise or counterclockwise)? Try to disable backface culling to check that.


Did you setup blending on all texture stages correctly? Did you correctly setup all rest of the states of graphics pipeline? Maybe the problem appears only when you render some objects in a specific order? That means states set before rendering one object remain in the pipeline and break rendering of the next one.

Advanced Effects

If you use some advanced rendering features, your graphics card may not support them. Set reference software rasterizer during creation of the device object (D3DDEVTYPE_REF instead of HAL). Your program will run very slowly, but everything should be drawn as expected. Query device object for capabilities of your GPU (device caps).


If you use depth buffer, remember to clear it as well, together with backbuffer. In 3rd parameter of Clear function bitwise OR following flag: D3DCLEAR_ZBUFFER. Without it, you won't see anything on the screen or you will see artifacts. Value to clear Z-buffer to is 1.0f (not 0.0f).

Finally, there are ways you can actually debug how data and state look like on subsequent stages of the graphics pipeline while this bugged draw call is executed, using Graphics Diagnostics in Visual Sudio or other GPU debugging tool.

See also: How not to render 3D graphics: 40 ways to get a blank black screen

Comments | #directx #rendering Share

# DirectX 11 CheatSheet

Aug 2014

I've created several cheatsheets: about DXGI Formats, XNA Math, floats, color names in .NET and Direct3D 9. You can see it in Download/Misc. Today I discovered that I didn't publish my DirectX 11 CheatSheet that I've prepared 3 years ago! So here it is:


On 15 pages, you will find:

Comments | #directx Share

# Book Review: DirectX 11.1 Game Programming

Sep 2013

"DirectX 11.1 Game Programming" is a new book published by Packt Publishing, written by Pooya Eimandar. It introduces new features of DirectX 11.1 and some other technologies available for game developers when writing Metro-style apps for Windows 8. The book uses C++/CX - a new language based on C++, with the syntax somewhat similar to C++/CLI (the language is extended by managed pointer operator ^). But while C++/CLI is a .NET language (like C#), C++/CX is compiled to native code and the ^ pointer is just a convenient syntax for reference-counting smart pointer to a COM object. Math is done with DirectXMath library (the successor of XNA Math).

Each of the chapters describes several loosely coupled topics. Their flattened list looks like this:

I have mixed feelings about this book. Contrary to what title suggests and what the author claims inside ("By the end of this chapter, we are going to have a multithreaded game engine"), you obviously cannot learn game programming by reading just 146 pages. Especially as the book covers so many different topics. It looks like the author wanted to include everything what's fresh and sexy in Microsoft Windows 8 API-s. As a result, each example is kind of "Hello World" - the simplest possible application of the described technology.

But at the same time, the book is also not teaching 3D games programming from the start. It explains some selected basic concepts in more details (e.g. describes what vertex shader does, shows how rotation matrices look like, how to use constant, vertex and index buffer or shows a diagram of the graphics pipeline - 3 times actually :) but generally you should already know C++ and preferably DirectX 10/11 to make use of the knowledge from this book. It is more like an overview of "What's New" in Windows 8, DirectX 11-11.1 and new Visual Studio.

I think the biggest value of this book is the attached source code. Each chapter is accompanied by a complete C++/CX project that shows an application of the described technology and the text in the book is an overview of this code. So if you already know some game programming in C++ and DirectX 10/11, this book can be a good tutorial which will help you to start using latest Microsoft technologies and develop Windows 8 Metro-style games. Preface says "This book will help you easily create your own framework and build your first game for Metro Style all by yourself in order to publish it on the Windows Store." and that is true.

But whether this is worth doing, that's another question. Surely you can use DX 11 on 9- or 10-compatible hardware, using Feature Level, but you cannot use most of what this book describes below Windows 8, and many of these things also without buying Visual Studio Professional or higher. According to Steam Hardware & Software Survey: Auguest 2013, while 64.78% of gamers already have DirectX 11 capable system and GPU, only 15.41% of them have Windows 8 installed (and it's already a year since its release).

Now it's time for a contest. Packt has proposed to offer 3 digital copies of the book. All you need to do is head on over to the book page, look through the product description of the book and then drop a line via the comments below this post to let us know what interests you the most about this book. 3 best comments win!!! Deadline: The contest will close in 1 weeks time. Winners will be contacted by email, so be sure to use your real email address when you comment.

Comments | #books #competitions #reviews #directx Share

# CConstantBuffer, CTypedConstantBuffer

Jan 2013

DirectX 10 and 11 have new, redesigned API that has its pros and cons. One can say that it is now more clean and well organized, but on the other hand it requires more (or as those who code in higher-level languages than C++ or use existing game engines would say - *even more*) lines of code than old Direct3D 9. So I created classes that encapsulate some most typical boilerplate D3D11 code. Here is first one - CConstantBuffer, which handles constant buffer, required now to pass any uniform parameters to a shader.

class CConstantBuffer {
        size_t bytesLength,
        const void* initialData = nullptr,
        bool immutable = false );
    ID3D11Buffer* Buffer() { return m_Buffer.get(); }
    void Update(const void* src);
    void SetForVS(UINT slot);
    // ...and so on for HS, DS, GS, PS, CS.
    size_t m_Length;
    unique_ptr<ID3D11Buffer, ReleaseDeleter> m_Buffer;

Read full entry > | Comments | #directx Share

# How to Flip Triangles in Triangle Mesh

Jan 2013

Given triangle mesh, as we use it in real-time rendering of 3D graphics, we say that each triangle have two sides, depending on whether its vertices are oriented clockwise or counterclockwise from particular point of view. In Direct3D, by default, triangles oriented clockwise are considered front-facing and they are visible, while triangles oriented counterclockwise are invisible because they are discarded by the API feature called backface culling.

When we have backface culling enabled and we convert mesh between coordinate systems, we sometimes need to "flip triangles". When vertices of each triangle are separate, an algorithm for this is easy. We just need to swap first with third vertex of each triangle (or any other two vertices). So we can start implementing the flipping method like this:

class CMesh
    D3D11_PRIMITIVE_TOPOLOGY m_Topology;
    bool m_HasIndices;
    std::vector<SVertex> m_Vertices;
    std::vector<uint32_t> m_Indices;

void CMesh::FlipTriangles()

Where the function template for flipping triangles in a vector is:

template<typename T>
void CMesh::FlipTriangleListInArray(std::vector<T>& values)
    for(size_t i = 0, count = values.size(); i < count - 2; i += 3)
        std::swap(values[i], values[i + 2]);

Simple reversing all elements in the vector with std::reverse would also do the job. But things get complicated when we consider triangle strip topology. (I assume here that you know how graphics API-s generate orientation of triangles in a triangle strip.) Reversing vertices works, but only when number of vertices in the strip is odd. When it's even, triangles stay oriented in the same way.

I asked question about this on forum.warsztat.gd (in Polish). User albiero proposed following solution: just duplicate first vertex. It will generate additional degenerate (invisible) triangle, but thanks to this all following triangles will be flipped. It seems to work!

I also wanted to handle strip-cut index (a special value -1 which starts new triangle strip), so the rest of my fully-featured algorithm for triangle flipping is:

            size_t begIndex = 0;
            while(begIndex < m_Indices.size())
                const size_t indexCount = m_Indices.size();
                while(begIndex < indexCount && m_Indices[begIndex] == UINT_MAX)
                if(begIndex == indexCount)
                size_t endIndex = begIndex + 1;
                while(endIndex < indexCount && m_Indices[endIndex] != UINT_MAX)
                // m_Indices.size() can change here!
                FlipTriangleStripInArray<uint32_t>(m_Indices, begIndex, endIndex);
                begIndex = endIndex + 1;
            FlipTriangleStripInArray<SVertex>(m_Vertices, 0, m_Vertices.size());

Where function template for flipping triangles in selected part of a vector is:

template<typename T>
void CMesh::FlipTriangleStripInArray(std::vector<T>& values, size_t begIndex, size_t endIndex)
    const size_t count = endIndex - begIndex;
    if(count < 3) return;
    // Number of elements (and triangles) is odd: Reverse elements.
    if(count % 2)
        std::reverse(values.begin() + begIndex, values.begin() + endIndex);
    // Number of elements (and triangles) is even: Repeat first element.
        values.insert(values.begin() + begIndex, values[begIndex]);

Comments | #directx #rendering #algorithms Share

# DirectX 11 Renderer - a Screenshot

Jan 2013

Here is what I've been working on in my free time recently. It's a renderer For PC, Windows, using DirectX 11.

It may not look spectacular here because I've just quickly put random stuff into this scene, but I already have lots of code that can do useful things, like deferred shading with dynamic directional and point lights, a bunch of material parameters, mesh processing and loading from OBJ file format, heightmap generation, particle effects and postprocessing (including bloom of course :)

In the next posts I will describe some pieces of my technology and share some C++ code.

Comments | #rendering #productions #directx Share

Pages: > 1 2 3 4 ... 8 >

[Stat] [STAT NO AD] [Download] [Dropbox] [pub] [Mirror]
Copyright © 2004-2018