http://www.microsoft.com/downloads/deta ... laylang=en
December 2006 DirectX SDK now available
December 2006 DirectX SDK now available
This one contains the first official release (non-beta) of DirectX 10! Now we just need an irrlicht version that supports it, vista, and DX10 card like nVidia 8800 series. I'm so excited!
http://www.microsoft.com/downloads/deta ... laylang=en
http://www.microsoft.com/downloads/deta ... laylang=en
I don't understand why everyone is so up and excited about Irrlicht on DX10. Irrlicht most likely won't take advantage of any of the benefits of DX10, as doing so would further seperate the functionality offered by the D3D and OGL renderers... i.e. interfaces to support geometry shaders would not work with any of other renderers, and that would destroy the cross-platform nature of Irrlicht.
I would rather see Irrlicht take advantage of some of the existing features of DirectX and OpenGL like hardware vertex buffers.
Travis
I would rather see Irrlicht take advantage of some of the existing features of DirectX and OpenGL like hardware vertex buffers.
Travis
well, i dont care about directX10 either because i dont even use shaders atm 
but i heard there is a lot of spead gain with directX10 is that true?
mfg,
halan
but i heard there is a lot of spead gain with directX10 is that true?
mfg,
halan
My Blog: http://www.freakybytes.org
Possibly. At the moment the development community probably doesn't have enough time with D3D10 and the hardware to do a fair comparison. Stuff that you will see from MSFT will be written to take advantage of enhancements and features to make it seem faster, but that doesn't mean that it will actually perform faster given the 'same' code.
When in the context of Irrlicht, it doesn't matter if DX10 is 10x faster than DX9. Irrlicht doesn't even use the features of DX9 that are there for performance. Because of this, most applications written using Irrlicht are going to be CPU bound.
Travis
When in the context of Irrlicht, it doesn't matter if DX10 is 10x faster than DX9. Irrlicht doesn't even use the features of DX9 that are there for performance. Because of this, most applications written using Irrlicht are going to be CPU bound.
Travis
Wow, I didn't know about that aspect of irrlicht. I assumed the DX9 part is optimized when on the win32 platform since that's the only platform that supports DXes. If that's true, this really sucks for any DX10 support in future versions of irrlicht.vitek wrote: When in the context of Irrlicht, it doesn't matter if DX10 is 10x faster than DX9. Irrlicht doesn't even use the features of DX9 that are there for performance. Because of this, most applications written using Irrlicht are going to be CPU bound.
Travis
Sounds like there needs to be an irrlicht DX10 branch to fully take advantage of what DX10 brings in terms of unified shaders.
I've heard an upcoming OpenGL revision supporting some of the DX10 feature set. But it seems like OpenGL takes forever to implement new features than DX.
Here's a feature list of DX10:
Fixed pipelines[2] are being done away with in favor of fully programmable pipelines (often referred to as unified pipeline architecture), which can be programmed to emulate the same.
Paging of graphics memory, to allow data to be loaded to Video RAM when needed and move it out when not needed. This enables usage of the system memory to hold graphics data, such as textures, thereby allowing use of more and higher resolution textures in games.
There is no limit on the number of objects which can be rendered, provided enough resources are available.[3]
Virtualization of the graphics hardware, to allow multiple threads/processes to use it, in turns.
New state object to enable the GPU to change states efficiently.
Shader model 4.0, enhances the programmability of the graphics pipeline. It adds instructions for integer and bitwise calculations.
Geometry shaders, which work on individual triangles which form a mesh.
Texture arrays enable swapping of textures in GPU without CPU intervention.
Resource View enables pre-caching of resources, thereby reducing latency.
Predicated Rendering allows drawing calls to be ignored based on some other conditions. This enables rapid occlusion culling, which prevents objects from being rendered if it is not visible or too far to be visible.
(source: http://en.wikipedia.org/wiki/Direct3D#Direct3D_10)
Fixed pipelines[2] are being done away with in favor of fully programmable pipelines (often referred to as unified pipeline architecture), which can be programmed to emulate the same.
Paging of graphics memory, to allow data to be loaded to Video RAM when needed and move it out when not needed. This enables usage of the system memory to hold graphics data, such as textures, thereby allowing use of more and higher resolution textures in games.
There is no limit on the number of objects which can be rendered, provided enough resources are available.[3]
Virtualization of the graphics hardware, to allow multiple threads/processes to use it, in turns.
New state object to enable the GPU to change states efficiently.
Shader model 4.0, enhances the programmability of the graphics pipeline. It adds instructions for integer and bitwise calculations.
Geometry shaders, which work on individual triangles which form a mesh.
Texture arrays enable swapping of textures in GPU without CPU intervention.
Resource View enables pre-caching of resources, thereby reducing latency.
Predicated Rendering allows drawing calls to be ignored based on some other conditions. This enables rapid occlusion culling, which prevents objects from being rendered if it is not visible or too far to be visible.
(source: http://en.wikipedia.org/wiki/Direct3D#Direct3D_10)