   Speed Changing between Reset?
  I have a curious problem with DirectX9, I have an application that normally goes at 640 FPS on my machine (ATI X1600PRO), if i try to move the window (causing a lostdevice) the device is reset. Well after the reset the speed change in a range between 610 to 680 totally random and remain the same for the whole duration of the app (or until another reset :D), what can be the cause?I'm a little troubled lol, i would prefer sticking with 680. XD   
  There is not really any difference between 610 and 680. The time for each frame is 1/610 and 1/680 seconds, which makes the difference 1/6000 of a second..You should measure how many milliseconds you have to draw rather than the FPS number, since at such high numbers, even if you had doubled your FPS to 1200, the speed increase would be so small it made zero difference.In a release of your game everyone will play it with vsync enabled, so your FPS will be clamped to the screen refresh rate. This is usually 60 FPS, which gives you 16.6 ms time to draw a frame. At 600 FPS you use up 1.6 ms, which leaves you 15 ms to use up. The drop of 1/6 ms leaves you 14.83 ms instead.It is very possible that once you use up about 1 or 2 of those 14.83 ms, the 1/6 ms drop will disappear. It can be something with the setup that is taken care of in parallel with your drawing.Note that a game looks much better in 60 FPS, or whatever number is the screen refresh rate, than a much higher number. You get ugly artifacts when drawing animation faster than the screen refresh rate. It is good for performance measuring, but again use the milliseconds instead of the FPS to get accurate results.   ;  Have you got the debug runtimes running, if so is there any output post-reset?The closest I've seen to your behaviour is where there is lots of debug output being spewed out. The frame rate drops each time the debug gets flushed to the console which gives it an odd 'saw tooth' like pattern.Otherwise, is the timer precision being corrupted? timeSetPeriod(1) (iirc) might need to be called again.hthJack   ;  First of all thanks to all for the answers. The reason of why I'm concerned about speed is because I'm actually finegraining the performance of the multithreaded DX9/DX10 game engine i've created. (using the 3 example game (1 arkanoid 2d, 1 arkanoid 3d, 1 tetris 2d) i've made to test out the engine in a real situation instead of sintetic benchmark)I know that the difference is very slim in terms of milliseconds (0,16 ms aren't that big :D), i was just wondering about WHY there is this difference and what can I do to ensure the best result. (for example I took today 2 hours of developing to refactor the synchronizing manager between threads at the end of the frame to recover 40 ns each frame and make it more object oriented :D)I had some idea that this could be caused by the texture position in GPU memory that change every time the device is reset. Can it be the case?To answer the question of jollyjeffer, I tested and there is no debug output, and anyway the change is permanent. It is not a temporary spike, it change the FPS permanently until another reset occur.   ;Quote:Original post by feal87First of all thanks to all for the answers. The reason of why I'm concerned about speed is because I'm actually finegraining the performance of the multithreaded DX9/DX10 game engine i've created. (using the 3 example game (1 arkanoid 2d, 1 arkanoid 3d, 1 tetris 2d) i've made to test out the engine in a real situation instead of sintetic benchmark)I know that the difference is very slim in terms of milliseconds (0,16 ms aren't that big :D)You need to put more strain on the system then. Either downgrade your system, or give the GPU / CPU more work to do. The more work you can give them, the more accurate the changes will be.Quote:Original post by feal87i was just wondering about WHY there is this difference and what can I do to ensure the best result. (for example I took today 2 hours of developing to refactor the synchronizing manager between threads at the end of the frame to recover 40 ns each frame and make it more object oriented :D)I had some idea that this could be caused by the texture position in GPU memory that change every time the device is reset. Can it be the case?Anything is possible. Resetting the device is a pretty major operation, and I wouldn't be surprised if some drivers took advantage of this time to cache resources differently.One thing to check is that if you're toggling between fullscreen and windowed mode that you're correctly updating the window style flags and window size so that D3D doesn't have to stretch the backbuffer to the window.Quote:Original post by feal87To answer the question of jollyjeffer, I tested and there is no debug output, and anyway the change is permanent. It is not a temporary spike, it change the FPS permanently until another reset occur.If you're not already; you'll also want to make sure you're using the retail D3D runtimes if you're doing any sort of profiling.   