NVIDIA PerfHUD is a powerful real-time performance analysis tool for Direct3D applications, and it is widely used by the world’s best game developers.
More info at NVIDIA PerfHUD homepage
PerfKit 6.0 New Feature Highlights:
* No longer requires an instrumented driver on Vista!
* Supports GeForce 8 and 9 GPUs
* SLI Support
* Texture Visualization and Overrides
* API Call List
* Dependency View
* New CPU/GPU Timing graph
Jay Dolan recently blogged about some of the performance optimizations he made to his Quake2-based engine, Quake2World. He provides links to various points in the source code to give context around some of the topics he discusses.
Read the post HERE.
Quake2 was released in 1997. Hardware acceleration was only available on higher-end PC’s, and things like multitexture and vertex arrays which are commonplace today didn’t even exist then. So naturally, Quake2′s rendering techniques appear very dated in 2008. Multitexture was made a part of the OpenGL specification in version 1.2.1, and is available on most 2nd generation hardware (TNT or newer). I strongly recommend cleaning up the renderer and removing any non-multitexture rendering paths.
Texture binds (glBindTexture) are rather expensive too, and so to minimize these per frame, you should group the world surfaces by texture before iterating over them. Note that a simple grouping operation is significantly cheaper than a qsort — overall order is not important, we just want to minimize texture changes.
Categories: Microsoft DirectX, OpenGL, Programming Tags: cg, fragment program, game development, gamedev, glsl, graphics programming, hlsl, Microsoft DirectX, pixel shader, profiling, shaderperf, vertex program, vertex shader
NVIDIA ShaderPerf is a command-line shader profiling utility and C API that reports detailed shader performance metrics for a wide range of GPUs.
ShaderPerf wokrs with GLSL vertex and fragment programs, HLSL vertex and pixel shaders and Cg shaders.
ShaderPerf 2.0 includes several new features:
* GeForce 8 series support
* Pixel Shader Differencing
* Vertex Shader Analysis
ShaderPerf outputs the following for any shader that you analyze:
* Cycle count
* Register usage
* Driver-optimized shader instruction list
* Vertex and pixel throughput estimates
More information and download HERE.
AMD will add the Havok Physics engine to both its multi-core CPUs and GPUs, but AMD managing director noted that the focus is on CPUs given feedback from gaming developers who like the idea of offsetting physics computation to CPU cores.
Read whole article HERE
AMD is hoping to accelerate Havok Physics on both its multi-core CPUs and GPUs and claims that it’s striving to deliver the best of both worlds. However, the main focus at the moment appears to be AMD’s CPUs. AMD and Havok say that they’re planning to optimise the ‘full range of Havok technologies on AMD x86 superscalar processors, and AMD claims that Havok Physics scales extremely well across the entire family of AMD processors.
Havok’s managing director, David O’Meara, explained the priority for CPUs, saying that the feedback that we consistently receive from leading game developers is that core game play simulation should be performed on CPU cores. However, he added that GPU physics acceleration could become a feature in the future, saying that ‘the capabilities of massively parallel products offer technical possibilities for computing certain types of simulation.
- AMD’s physics secret revealed: It’s Havok @ TG Daily
DirectX 11 will be presented at the upcoming nVision 2008. Among the news features, there will be tessellation, multithreaded rendering, compute shaders, Shader Model 5.
Leadwerks Software has released a paper describing their experience implementing deferred lighting in the OpenGL-based Leadwerks Engine. The paper includes some GLSL code for reconstructing screen space positions without need for a position float buffer, as well as a few results surprising to the author.
This paper is available HERE – PDF
Responsiveness is something that can make or break a game at first impression. This is especially true in reviews where a game with poor responsiveness will be described as being “sluggish”, “unresponsive”, “floaty” or “sloppy”. A better game might be referred to as “tight” or “responsive”. There are several factors that contribute to perceived responsiveness. This article looks at some of them from a programmer’s perspective, and offers some routes to making your game more responsive.
Read the complete article HERE
The second part of the Software Engineering Best Practices in Game Development was just published. It focuses on iterative development in the context of game development.