Tag Info

New answers tagged

0

You can suppresses messages from the debug layer: #include <wrl/client.h> using Microsoft::WRL::ComPtr; #ifndef NDEBUG ComPtr<ID3D11Debug> d3dDebug; hr = m_d3dDevice.As(&d3dDebug); if (SUCCEEDED(hr)) { ComPtr<ID3D11InfoQueue> d3dInfoQueue; hr = d3dDebug.As(&d3dInfoQueue); if (SUCCEEDED(hr)) ...


0

There is a chance that your depth value calculation is wrong. The way the GPU's are calculating the depth values is not that simple. For example if we take a point right in the middle between the near and far planes of the camera, the depth value is not 0.5 . You can refer to this post by Steve Baker to see how you can calculate the depth value: ...


0

some link to crunch the math side if you want to prepare a one matrix that rotates about the 2 angles at once: http://inside.mines.edu/fs_home/gmurray/ArbitraryAxisRotation/ Otherwise I personally do it this way: void ThisApplication::UpdateClient0Positions(void) { if (AbsoluteValueFl(RotateCamera.y) > D3DXToRadian(120)) RotateCamera.y = ...


6

The GPU doesn't, the programmer does. The initialization of the graphics API will typically involve optional specification of which display device to use; not explicitly specifying this generally results in the default of whatever the OS thinks the "primary monitor" is. OpenGL and D3D handle this decision differently. D3D has the concept of "adapters" ...


2

I understand that you are at a loss. I also liked to hack pixels when I was young, and did some games on calculator devices, or dos era this way. This can still be done today, but, because of various hardware history of evolutions, it has become more involved. CPU pixel pushing Notably, we can still push pixels one by one, but it would be incredibly slow ...


2

I'm also from a pixel-banging background. PEEK and POKE anyone? Using a GPU is a different mind-set entirely. (Well, it's still code, so just "more of the same...) The GPU is really good at certain things: Processing individual pixels (through textures and fragment shaders), and filling triangles with pixels. Much effort (on the programmer's part) is ...


2

Yes, you can easily do it. Modern video drivers (almost) always come with OpenGL support. DirectX 11 requires same hardware as OpenGL 4, so you will probably get at least OpenGL 4.3. Based on these statistics, and this information about equivalence of hardware requirements between different OpenGL and DirectX versions, we have approximately these numbers: ...


0

You can use glviewer to see which version of OpenGL your graphics card supports and which extensions are available to use.


2

There are 2 main types of projections used in video games and 3d applications: Perspective Orthogonal Perspective This type of projection is the one that is the most commonly used to represent a 3d world simulation; it acts a little like a normal camera with lenses. All the elements of the scene are projected toward a single point, but drawn on a plane. ...


0

What you can do is store boolean values for if the key was down or released and create some simple getters, a setter, and a "resetter" like so: struct Key { bool down; bool released; bool pressed; }; bool KeyInput::IsKeyDown(uint32 keyCode) { return s_keys[keyCode].down; } bool KeyInput::WasKeyPressed(uint32 keyCode) { return ...


1

Some informal thoughts, specifically about clickable menu items... You're 100% correct to not worry much about performance here. Menus are typically stateful, navigating a tree of states. So it may make more sense to alert a "menu node" which which of the several choices they made. At the individual button/item level, they could know their 2d boxes, and ...


3

The near plane parameter shall be strictly larger than zero. The smaller it is the more precision you burn close to the camera, and with zero, the projection matrix degenerates into unusability. If your geometry isn't where you want it to be when you use a conformant projection matrix, address that problem instead.


1

screenPosition is not at the right scale for texture coordinate lookup. Texture2D::Sample expects texture coordinates (0..1) while Texture2D::Load expects texel coordinates (0..[Width or Height]-1). So you're probably sampling way off the edge of the texture and either hitting the border color, or clamping to the edge which happens to be black. As a ...



Top 50 recent answers are included