http://asawicki.info/ Graphics programming, game programming, C++, games, Windows, Internet and more...
All blog entries, ordered from most recent. Entry count: 997.
Nothing Renders - Why?
"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.
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.
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?
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.
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)?
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.
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.
Installing Visual C++ Redistributable Package from Command Line
You may think that unless you explicitly use some external library (like FMOD), your program will not require any additional libraries to work, but when coding in C++ using Visual Studio, this is not the case. The functions of standard C/C++ library are implemented in a package of DLL-s called Microsoft Visual C++ Redistributable Package. Each version of Visual Studio has their own set. For example, version for Visual Studio 2013 (Release configuration) consists of files: msvcr120.dll, msvcp120.dll.
You can make your application not requiring this library by setting your project options in Configuration Properties > C/C++ > Code Generation > Runtime Library to "Multi-threaded [Debug]" without the "DLL" part, which makes it statically linked. Alternatively, you can distribute these DLL files (although I'm not sure if this is legal) or the whole library installer together with your application. The library is small and free, available to download from Microsoft website:
The question is: can you launch the installer of these packages with some special parameter so the user doesn't have to go through all the setup wizard, confirming each step? The answer is yes, but as Microsoft likes to change everything very often :) the exact command line is different depending on version. Here is the whole set:
Visual Studio 2005:
Visual Studio 2005, x86 (32-bit version):
vcredist_x86.exe /q:a /c:"VCREDI~1.EXE /q:a /c:""msiexec /i vcredist.msi /qn""
Visual Studio 2005, x64 (64-bit version):
vcredist_x64.exe /q:a /c:"VCREDI~2.EXE /q:a /c:""msiexec /i vcredist.msi /qn"" "
Visual Studio 2005 SP1, x86:
vcredist_x86.exe /q:a /c:"VCREDI~3.EXE /q:a /c:""msiexec /i vcredist.msi /qn"" "
Visual Studio 2005 SP1, x64:
vcredist_x64.exe /q:a /c:"VCREDI~2.EXE /q:a /c:""msiexec /i vcredist.msi /qn"" "
If you would like to install it in unattended mode (which will show a small progress bar but not require any user interaction), you can change the "/qn" switch above to "/qb". Unattended mode + disabled "Cancel" button is "/qb!".
Visual Studio 2008: Just pass one of these parameters:
/q - quiet mode, no user interface.
/qb - unattended mode, shows progress bar but no user interaction required.
/qb! - unattended mode with "Cancel" button disabled.
Visual Studio 2010 and 2012:
/q /norestart - quiet mode
/passive /norestart - passive (unattended) mode
Visual Studio 2013:
/install /quiet /norestart - quiet mode
/install /passive /norestart - passive (unattended) mode
To quickly install all of these libraries on the machines where lots of different applications are launched that may require them, I gathered all the libraries in one directory and I have written following BAT script:
"2005 SP1\vcredist_x86.exe" /q:a /c:"VCREDI~3.EXE /q:a /c:""msiexec /i vcredist.msi /qb"" "
"2005 SP1\vcredist_x64.exe" /q:a /c:"VCREDI~2.EXE /q:a /c:""msiexec /i vcredist.msi /qb"" "
"2008 SP1\vcredist_x86.exe" /qb
"2008 SP1\vcredist_x64.exe" /qb
"2010 SP1\vcredist_x86.exe" /passive /norestart
"2010 SP1\vcredist_x64.exe" /passive /norestart
"2012 Update 4\vcredist_x86.exe" /passive /norestart
"2012 Update 4\vcredist_x64.exe" /passive /norestart
"2013\vcredist_x86.exe" /install /passive /norestart
"2013\vcredist_x64.exe" /install /passive /norestart
Watch out for reduced precision normalize/length in OpenGL ES
GLSL language for OpenGL ES introduces concept of precision. You can annotate variable declaration (both float and int/uint) with a precision qualifier:
mediump float a = 3.0;
You can also specify default precision qualifier by using precision statement. Language specification defines minimum required range and precision for each precision qualifier.
highpbasically means normal, single-precision, 32-bit float (IEEE 754), as we know it from CPU programming.
mediumpis said to have have range of at least -2^14 ... 2^14 and relative precision 2^-10, so it can be, for example, implemented using a 16-bit, half-precision float.
lowpis said to have range at least -2 ... 2 and absolute precision 2^-8, so basically it can be stored as a 10-bit, fixed-point number.
GPU vendors are free to use more precise data types, or even full 32-bit float for all of them. What exact precision is used depends on specific GPU and maybe even operating system or graphics driver version. Using smaller data types can occupy less memory, calculate faster and consume less battery power. But it comes at the price of reduced precision and range of these numbers. Tom Olson wrote interesting articles about this: "Benchmarking floating-point precision in mobile GPUs": Part I, Part II, Part III.
In this post I'd like to warn you against a specific problem related to it - usage of
distance() functions. Using smaller data types not only limits precision in terms of number of significant digits, but also available range (over which the value will saturate to -INF/+INF). For mediump, this range is defined as +/-2^14, which is only 16384.
This may still look like a lot, but let's remember that calculating vector length involves intermediate value that it sum of squares of this components. This can grow very big before a square root is applied. For example, for 3D vector:
length(a) = sqrt(a.x*a.x + a.y*a.y + a.z*a.z)
If you do this operation on a mediump vector, the term
a.x*a.x + a.y*a.y + a.z*a.z can exceed maximum value for vector as small as (74.0, 74.0, 74.0). It can be very dangerous if you do something like this in your fragment shader:
precision mediump float;
uniform vec3 light_pos;
vec3 dir_to_light = normalize(pos - light_pos);
// Calculate your lighting and so on...
You might ask: Why isn't this intermediate value stored in high precision before taking its square root to avoid this overflow problem? Obviously it could be, as precision in any place of the shader is free to be higher than the minimum allowed in that place, so some GPU vendors can do it this way, but you shouldn't rely on this. GLSL specification clearly says that the shader is free to use same, reduced precision for intermediate values.
The precision used to internally evaluate an operation, and the precision qualification subsequently associated with any resulting intermediate values, must be at least as high as the highest precision qualification of the operands consumed by the operation.
Conclusion is: When you write shaders for OpenGL ES, watch out for operations that involve calculating vector length (or dot product) like
highp precision for vectors involved and remember that what works on one GPU due to using precision higher than minimum required, may not work on another GPU and it’s still an application issue.
My visuals on Headrush party in Protokultura, Gdańsk
Next Saturday, 2015-04-11, you can see my music visualizations on Headrush party in Protokultura club in Gdańsk. There will be 3 scenes with various genres of electronic dance music, and the club is big and very good, so I'm sure it will be great party. My visuals will be shown on psytrance scene. Unfortunately I can't be there myself, but I'm sure my friends Wooffer and Brain Massage will handle setup of this system very well. Some random screenshots:
Funny quotes from Twitter
Today I reviewed all the tweets that I have in favorites and made a list of most funny (and sometimes quite serious) quotes that I could find there. They are mostly about C++, games and graphics programming. Enjoy :)
If Tetris has taught me anything, it's that errors pile up and accomplishments disappear.
Reproducibility is collaborating with people you don't know, including yourself next week (@philipbstark at #dsesummit)
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.
Sony totally missed the opportunity to call their phones Talkman.
IGK 2015 Conference
I will be there, giving a lecture "On the other side of graphics API. How does graphics driver and chip look like?" (It will be in Polish. Actual title: "Po drugiej stronie API graficznego. Czyli jak wygląda sterownik i układ graficzny?")
Abstract: A programmer developing games or other applications that utilize GPU uses one of API-s for 3D graphics (e.g. DirectX, OpenGL) or GPGPU (e.g. OpenCL). With examples based on the Intel products, the lecture shows what is on the other side of that API: characteristics and components of graphics driver (especially shader compiler), architecture of a GPU and its instruction set.
Psychill Evening Vol 2 with my visuals
On Friday, 13 February 2015 I'd like to invite you for second edition of Psychill Evening party in Paszcza Lwa club in Gdańsk, Poland. Once again the music will be "Psychill, Psybient, Downtempo, Psydub and Ambient", so basically more calm genres of electronic music. Once again I will be doing visuals on this party. See also my blog entry and video below from first edition.
I'm now working on my software to prepare some new stuff. Some random screenshots:
Of course this is a blog about programming, not about art or parties, so in the next posts I will explain some of the technical details behind this program.
Compiler Development - A Higher-Order Hardcore
Of various kinds of programs that a programmer can work with, I think that developing compilers is particularly difficult. Here is why:
If your job is to just work with data (e.g. in Excel), all that can be wrong is just the data.
If you are a programmer, you write programs. Programs generally translate some input data to some output data. So if the output is wrong, you examine the input and if you are convinced that the input is correct, there is probably some bug in your program.
If you develop a compiler, things get even more complicated. Then you write a program (compiler) that will take source code of another program as input and produce compiled program as output. That program will process some data. So if the output of that program is wrong, its input data may be wrong, its source code may have a bug or, if you are convinced that they are both correct, there is probably some bug in the compiler. So there are more “degrees of freedom” here. You examine what’s wrong in the output data, then you look at compiled program to find a bug and finally you examine the compiler to understand why it generated that program.
It’s not always that simple to even determine which part has a bug. Even if your change in the compiler causes program to produce invalid output, sometimes it may be a bug in the source code. For example, the program may rely on some undefined behavior (like use of uninitialized variable), so any change in the compiler can produce different output, while the compiler is still correct.
When learning functional programming, you must understand how to operate on higher-order functions - functions that operate on functions. I can see an analogy here. So if you even consider working in compiler development, better think twice whether you are ready for such higher-order, hardcore level of debugging :)