<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:georss='http://www.georss.org/georss' xmlns:gd='http://schemas.google.com/g/2005' xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-3532236</id><updated>2011-04-21T11:35:29.277-07:00</updated><title type='text'>My own little DirectX FAQ</title><subtitle type='html'>Stuff that isn't in the official FAQ, but that keeps getting asked. Maybe some of this will migrate eventually.</subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://tomsdxfaq.blogspot.com/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default?max-results=100'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>17</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>100</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-3532236.post-114482869432550076</id><published>2006-04-12T00:39:00.000-07:00</published><updated>2006-04-12T00:58:14.340-07:00</updated><title type='text'></title><summary type='text'>Why is Present so slow?Well - it isn't! On its own, Present does very little except tell the GPU that the current frame is done, and it should display that to the screen. It might also do a few blits and clears, but those are very quick operations on today's cards.The reason you're seeing Present on your profile is that Present is also when the CPU and GPU "sync up" with each other. They are two </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/114482869432550076'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/114482869432550076'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2006_04_01_archive.html#114482869432550076' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-114482755569486635</id><published>2006-04-12T00:16:00.000-07:00</published><updated>2006-04-12T02:02:28.650-07:00</updated><title type='text'></title><summary type='text'>Why is DrawPrimitive so slow?Well - it isn't! If you simply do a whole bunch of DrawPrim calls in a row and time them, you will find they run very fast indeed. However, if you insert some rendering state changes (almost any of the Set* calls) in between those calls, that's when they start to get slow. Note that your profiler will not show the extra time being taken in the Set* calls themselves - </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/114482755569486635'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/114482755569486635'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2006_04_01_archive.html#114482755569486635' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-113546436585770597</id><published>2005-12-24T14:43:00.000-08:00</published><updated>2005-12-24T14:46:05.873-08:00</updated><title type='text'></title><summary type='text'>Vertex cache optimisationMost graphics cards have a vertex cache that sits after the Vertex Shader or Fixed-Function Transform &amp; Light stage and caches the results. (they also have a pre-VS cache, I'll discuss that below). The idea of this cache is to make sure the card never processes any vertex twice. However, getting it to work perfectly is impossible - the best you can hope for is that the </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/113546436585770597'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/113546436585770597'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2005_12_01_archive.html#113546436585770597' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-113546220006246490</id><published>2005-12-24T14:08:00.000-08:00</published><updated>2005-12-24T14:10:00.073-08:00</updated><title type='text'></title><summary type='text'>Strips, lists, fans, indexed or not?D3D has a wide array of primitive types, and they each have different performance characteristics. So which one should you use? To lay down some ground rules, these are the things you need to optimise for when making this choice - most important first:1: Number of DrawPrimitive/DrawIndexedPrimitive calls.2: Number of vertices processed by the vertex shader (or </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/113546220006246490'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/113546220006246490'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2005_12_01_archive.html#113546220006246490' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-113475668072706409</id><published>2005-12-16T09:34:00.000-08:00</published><updated>2005-12-16T10:18:22.346-08:00</updated><title type='text'></title><summary type='text'>Cunning ways to avoid clearing the framebuffer.Or rather, why you shouldn't try to do this! In ye olden tymes of the Voodoo2, filling pixels was expensive, and you could avoid having to do a clear by using a convoluted method (use only half the Z-range, flip it every even/odd frame, never actually clear any pixels).But that is all silly nowdays, and indeed it's usually slower. There's two big </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/113475668072706409'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/113475668072706409'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2005_12_01_archive.html#113475668072706409' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-106232377439207329</id><published>2003-08-31T02:56:00.000-07:00</published><updated>2003-08-31T02:56:14.200-07:00</updated><title type='text'></title><summary type='text'>State blocks and the D3DX Effects frameworkDan Baker from Microsoft had a handy hint when using the Effects framework on older drivers. This is related to another FAQ article What's the best way to do state changes?, so go read that one too.Effects make extensive use of stateblocks. Generally, performance stabilities issues with D3DXEffects are actually issues with a drivers stateblock </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/106232377439207329'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/106232377439207329'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2003_08_01_archive.html#106232377439207329' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-88502992</id><published>2003-02-03T17:15:00.000-08:00</published><updated>2003-02-03T17:19:09.000-08:00</updated><title type='text'></title><summary type='text'>What happens when I set a texture to NULL?Well, there's a number of different options. There's what should happen, there's what often happens, there's what more frequently happens, and there's what you can rely on happening. So let's address these one by one.What should happenAccording to the refrast source, if you read any texels from a NULL texture, you get opaque black. So that RGB=0.0, </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/88502992'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/88502992'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2003_02_01_archive.html#88502992' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-80620056</id><published>2002-08-23T10:00:00.000-07:00</published><updated>2002-08-23T10:01:09.000-07:00</updated><title type='text'></title><summary type='text'>What TextureStateState stuff can different cards do?It's a difficult question to answer fully. Drivers change, bugs get fixed (or created!), etc. The short answer is "use ValidateDevice()". The longer answer is "know roughly what most cards do, know what the gotchas are, write multiple versions of your TSS shaders, and use ValidateDevice()". The addendum is "sometimes ValidateDevice() lies". </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/80620056'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/80620056'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2002_08_01_archive.html#80620056' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-79344425</id><published>2002-07-24T05:55:00.000-07:00</published><updated>2002-07-24T06:03:38.000-07:00</updated><title type='text'></title><summary type='text'>Why ZBIAS is not a good thingZBIAS looks great at first sight. It's a little tweak to your Z values and stops Z-fighting when things are coplanar but don't actually share vertices (e.g. posters stuck on walls). However, it's a problem. The problem is that the actual behaviour of ZBIAS is not well defined. The number you feed in has no absolute meaning - each card is free to interpret it any way</summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/79344425'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/79344425'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2002_07_01_archive.html#79344425' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-78505386</id><published>2002-07-03T05:56:00.000-07:00</published><updated>2002-07-03T06:05:13.000-07:00</updated><title type='text'></title><summary type='text'>What's the best way to do state changes?Remember - there are three sides to this question. (1) what the app does, (2) what the D3D layer does and (3) what the videocard driver does. All affect performance in different ways. A few facts:On a PURE device, SRS and STSS calls go straight to the driver (or rather, they go into the D3D command-buffer that goes to the driver).On a non-PURE device,</summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/78505386'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/78505386'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2002_07_01_archive.html#78505386' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-77884484</id><published>2002-06-18T04:04:00.000-07:00</published><updated>2002-06-18T04:09:32.000-07:00</updated><title type='text'></title><summary type='text'>Why is software T&amp;L so slow?Well, it's slower than hardware, but not that slow. If you're finding massive speed differences (i.e. more than 10x), you may be doing something wrong. You need to be aware of the fundamental difference between software T&amp;L and hardware T&amp;L.Hardware T&amp;L only transforms vertices as-and-when you actually use one by referencing it with in index. To prevent it from </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/77884484'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/77884484'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2002_06_01_archive.html#77884484' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-77137810</id><published>2002-05-30T03:59:00.000-07:00</published><updated>2002-05-30T08:08:48.000-07:00</updated><title type='text'></title><summary type='text'>How do Texture Transform matrices work?The answer is - slightly oddly. If you are familiar with the OpenGL ones, forget them. These are subtly and confusingly different. So best just to forget them and start again. I am using the DirectX8 terminology here, but it translates fairly easily to DX7 or DX9.The basic operation is in four steps:(1) Coordinates (1-4 components) are fed into the </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/77137810'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/77137810'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2002_05_01_archive.html#77137810' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-77058367</id><published>2002-05-28T03:47:00.000-07:00</published><updated>2002-05-28T03:47:48.880-07:00</updated><title type='text'></title><summary type='text'>What is the difference between D3DCAPS8::MaxTextureBlendStages and D3DCAPS8::MaxSimultaneousTextures?The first is how many TSS blend stages the driver understands. The second is how many different textures you can use at a time. These two are not the same things - you may be able to use extra blend stages without using extra textures. In fact one of the commonest blends on 2-texture hardware (</summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/77058367'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/77058367'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2002_05_01_archive.html#77058367' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-77028718</id><published>2002-05-27T10:14:00.000-07:00</published><updated>2002-05-27T10:52:39.000-07:00</updated><title type='text'></title><summary type='text'>DrawIndexedPrimitiveA common question is - what do all those arguments actually mean?The DX9 version of DrawIndexedPrimitive is probably the best model. The DX8 one does not have a BaseVertexIndex argument in the DIP call itself - it is supplied when you call SetIndices. But both do the same thing, the argument is just in a different call on DX8.HRESULT DrawIndexedPrimitive(    </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/77028718'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/77028718'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2002_05_01_archive.html#77028718' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-76882403</id><published>2002-05-23T07:05:00.000-07:00</published><updated>2002-05-27T10:20:35.000-07:00</updated><title type='text'></title><summary type='text'>When to disable the TextureStateState pipeline.Drivers can get very confused if you don't set D3DTOP_DISABLE in both pipes at the same time. In fact according to the docs in DX8 (this was not true in DX7), it's just plain Wrong:D3DTOP_DISABLEDisables output from this texture stage and all stages with a higher index. To disable texture mapping, set this as the color operation for the first </summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/76882403'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/76882403'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2002_05_01_archive.html#76882403' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-76882356</id><published>2002-05-23T07:03:00.000-07:00</published><updated>2002-05-23T07:03:44.046-07:00</updated><title type='text'></title><summary type='text'>The first FAQ is of course, "how do I unsubscribe". The answer is at the bottom of every post: http://DISCUSS.MICROSOFT.COM/archives/DIRECTXDEV.html</summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/76882356'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/76882356'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2002_05_01_archive.html#76882356' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-3532236.post-76881961</id><published>2002-05-23T06:52:00.000-07:00</published><updated>2005-12-24T14:58:31.723-08:00</updated><title type='text'></title><summary type='text'>This is my own little version of the DX FAQ. OK, there might be some non-DX FAQ entries in here (especially on VIPM or something), but it's mainly for the benefit of people on the DXDev mailing list:-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-MSDN DirectX Developer Centre:  http://msdn.microsoft.com/DirectX-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=</summary><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/76881961'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/3532236/posts/default/76881961'/><link rel='alternate' type='text/html' href='http://tomsdxfaq.blogspot.com/2002_05_01_archive.html#76881961' title=''/><author><name>Tom</name><uri>http://www.blogger.com/profile/13824081088788380256</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author></entry></feed>
