look for this though i dont think it will do much
rendering 100 screen size quads is acceptable (for 800x600: 192 000 000 = 192mtexels/s)
SwapBuffer trouble
Check for driver settings -> i found something on my ATI card - swap buffers mode option with to modes: block transfer and smth else i dont remember.
look for this though i dont think it will do much
rendering 100 screen size quads is acceptable (for 800x600: 192 000 000 = 192mtexels/s)
look for this though i dont think it will do much
rendering 100 screen size quads is acceptable (for 800x600: 192 000 000 = 192mtexels/s)
Ilici is right. Try to check drivers and make sure you aren''t really moving buffers, but you are only redirecting "pointers" to them (i don''t know how is called a pointer to memory on graphics card)
2) why you have lots of textures? what are you exactly doing? If you aren''t generating them every frame, it may be better to create some bigger ones.
..and try to post all the code, we''ll check it too. I think (hope...) you won''t need copyrights or such things for 200 triangles.
...::why don''t we have assembler forum?::...
2) why you have lots of textures? what are you exactly doing? If you aren''t generating them every frame, it may be better to create some bigger ones.
..and try to post all the code, we''ll check it too. I think (hope...) you won''t need copyrights or such things for 200 triangles.
...::why don''t we have assembler forum?::...
1. Don''t do a glFlush unless you know what you''re doing (that means don''t do it) and *don''t* do a glFinish unless you know what you''re doing. You''ll wreck performance.
2. If vsync is on, swapbuffer will eventually block. You can turn off vsync either in your video drivers control panel or in your program with the WGL_EXT_swap_control extension.
3. To devrease latency windows mandates a certain maximum number of frames for which drivers can buffer a buffer swap something like 2 frames or so.
4. In general, all timing measurements are useless when vsync is on.
2. If vsync is on, swapbuffer will eventually block. You can turn off vsync either in your video drivers control panel or in your program with the WGL_EXT_swap_control extension.
3. To devrease latency windows mandates a certain maximum number of frames for which drivers can buffer a buffer swap something like 2 frames or so.
4. In general, all timing measurements are useless when vsync is on.
Sorry to bust in here, but the last poster said something which I am very interested about.
4. In general, all timing measurements are useless when vsync is on.
So how do you do timing if vsync is on? I mean, you need to do something with time, else how do you assure your game/program runs at the same speed on a slower/faster computer?
4. In general, all timing measurements are useless when vsync is on.
So how do you do timing if vsync is on? I mean, you need to do something with time, else how do you assure your game/program runs at the same speed on a slower/faster computer?
quote:Original post by GameCat
1. Don''t do a glFlush unless you know what you''re doing (that means don''t do it) and *don''t* do a glFinish unless you know what you''re doing. You''ll wreck performance.
2. If vsync is on, swapbuffer will eventually block. You can turn off vsync either in your video drivers control panel or in your program with the WGL_EXT_swap_control extension.
3. To devrease latency windows mandates a certain maximum number of frames for which drivers can buffer a buffer swap something like 2 frames or so.
4. In general, all timing measurements are useless when vsync is on.
1. glFlush waits till all the gl commands get proccessed, glFinish waits till everything is DRAWN. You should use glFlush if you doublebuffer.
2. Even with vsync swapbuffer won''t wait more than 60/100 ms.
4. Only if he gets more than 60 fps, and he doesn''t.
"C lets you shoot yourself in the foot rather easily. C++ allows you to reuse the bullet!"
1. Well if you want to be pedantic, glFlush ensures that the commands issued upto the flush will complete in a finite amount of time. Which is, for all purposes fairly pointless. However, it is generally used as a way to tell the driver "hey i submitted a small batch of something that you shouldn''t buffer up, start drawing now!". Even then, it might not work as expected due to the broken specification of glFlush. you do not need to call it before swapping buffers unless you''re paranoid about latency and are giving the driver small batches of stuff to do per frame. glFinish ensures that all previous commands are completed, but you *don''t* need to call it before you swap buffers. The driver and os take care of that.
2. I have no idea what you''re talking about here. 0.6 ms is certainly not some kind of "max block time" for swapbuffers. What gave you that idea? Are you assuming the refresh rate is 60Hz? Also see my point 3 which ties in with this one.
4. No, even if he gets less than 60fps. You do understand how Vsync works right. Assume the refresh rate is 100Hz. One frame take 0.011 seconds to draw. It then misses the refresh at 0.01 seconds and has to wait for 0.009 seconds til the next one. This means the total frame time will be 0.02 seconds, or 50Hz.
2. I have no idea what you''re talking about here. 0.6 ms is certainly not some kind of "max block time" for swapbuffers. What gave you that idea? Are you assuming the refresh rate is 60Hz? Also see my point 3 which ties in with this one.
4. No, even if he gets less than 60fps. You do understand how Vsync works right. Assume the refresh rate is 100Hz. One frame take 0.011 seconds to draw. It then misses the refresh at 0.01 seconds and has to wait for 0.009 seconds til the next one. This means the total frame time will be 0.02 seconds, or 50Hz.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
