I think it is best to just roll your own animation controller. It is not that hard to do. Animation Tracks has a set of keys for each bone. Just figure out between which two keys you are by using a time variable 0-1, then interpolate those keys for each bone.
What functionality do you want from a renderer? Well you want to give it a Scene and render it to the screen right? You also want it to handle the game window so that you can change resolution and toggle windowed mode and fullscreen mode.
Another thing you want from the renderer (atleast DX9) is to create textures/surfaces and buffers for you.
Unfortunatly those articles are not helping. But with some creative use of pen and paper i've cooked up something from what I got out of Rosens paper. I will see if I can implement this. I'm trying to do this on SM3.0 in DX9. All maps will have the same length.
1. First the importance map is collapsed into two 1D maps, the vertical and the horizontal. This is done by setting each corresponding pixel to the maximum value in the row or column.
2. These 1D maps are then blurred.
3. Calculate the sum of all pixels in each blurred map to get the total importance. Perhaps this can be done on the GPU by rendering to a 1x1 texture using a quad. Since the pixel shader is only run once for each 1D map it will sample the entire 1D blurred map and spit out the sum. Which can be read back to the CPU and set as a constant on the GPU. I don't know if there is a faster method to find the total importance.
4. The warping map is constructed by rendering to a 1D texture. The first pixel in the warp map will recieve half the value of the first pixel in the blurred 1D map divided by total importance. The second pixel in the warp map will recieve the full value of the first pixel, plus half the value of the second pixel divided by total importance. The third pixel in the warp map will recieve half the value of the third pixel in the blurred map, plus the sum of the first and second pixel divided by total importance. The algorithm here is the sum up all the pixels before the current pixel, plus half of the current pixel and divide by total importance. Each pixel in the warp map is a pointer that maps to a new coordinate. This is a list of pixels with values between 0 and 1.
5. Render the shadow map; in the vertex shader transform all vertices to screen space to have a value between -1 and 1 as normal. Then add 1 and divide by 2 to scale it to the range between 0 and 1. We now sample pixels in the warp maps where our value is between. A linear interpolation of the two pixel values gives us a new mapped coordinate in the range 0 to 1. We scale it back to be in the range -1 and 1 and output the result. Perhaps we can fiddle the warp map to have values between -1 and 1 to avoid back and forth scaling.
6. Render the scene to a texture.
7. Render full screen quad using the texture from step 6. In the pixel shader convert UV's to shadow map space and run them through the warp maps, using the new UV's sample the shadow map and do the depth test.
HRESULT hr = NULL;
hr = device->TestCooperativeLevel();
// device is no longer lost and reset has completed successfully; recover resources here
LostDevice = false;
return; // note: this assumes that this test is the last thing in the function it's being called from
// device is still lost; can't do anything so do nothing
// device is ready to be reset; Release resources here and then Reset it
// (be sure to test the hr from your Reset call too!)
MessageBox(NULL, L"TestCooperativeLevel() failed", L"Error", MB_OK);
You should not draw the same mesh with more then one draw call. Use instancing for every mesh you plan on drawing more then once. If you use the same mesh with different textures you can build a texture atlas or use more samplers.
Thanks guys. I think I will go for the D3DUSAGE_RENDERTARGET, D3DFMT_R32F, surface since I am targeting DX9 hardware and I need to most compatibility, and I don't want to complicate things by writing hardware specific code at this stage.
Yes. But if the map erases entry 5 then int_ptr will be dangling.
You can use a shared_ptr inside the map, such that if map erases entry 5 then int_ptr will still point to the valid int. Only when the last shared pointer is destoryed the int is automatically deallocated.
You should decouple FPS from game logic so that the game behave the same way regardless of FPS. For each frame you find the fElapsedTime and pass it down to all your logic. Every parameter you want to move/rotate/scale/advance you multiply with fElapsedTime.