More pages: 1 ...
11 ...
21 ...
31 ...
41 ...
51 ...
61 ...
71 ...
81 ...
91 ...
101 ...
109 110 111 112 113 114
115 116 117 118 119 ...
121 ...
131 ...
141 ...
151 ...
161 ...
171 ...
181 ...
191 ...
201 ...
211 ...
221 ...
231 ...
241 ...
251 ...
261 ...
271 ...
281 ...
291 ...
301 ...
311 ...
321 ...
331 ...
341 ...
351 ...
361 ...
365
Query Failed
Overlord
Saturday, May 16, 2009
So in essence, Tim Sweetny was right.
I totally agree with these thoughts.
I also think it's not long before we will see OpenCL-GL (as in CL with minimum graphics functions).
NitroGL
Friday, May 15, 2009
That's awesome, right up there with Renault playing music on their F1 car!
Humus
Monday, May 11, 2009
DirectX locks the number of buffered frames to at most three. With DXGI 1.1 you can set the number of buffered frames yourself using IDXGIDevice1::SetMaximumFrameLatency(), which could be useful in the future. Today the best way to reduce mouse lag within the game is to use an event query and sync to previous frame, which will give you one frame's latency. And for CrossFire/SLI systems you would typically sync to two frames back, or as many GPUs are being used.
John
Monday, May 11, 2009
Yes, custom-drawn cursors lag terribly. The main problem however are things such as first person shooters, where the view will lag and you can't use a hardware cursor to cover you up.
Really, what's up with that? Drivers using flip queues of 10 frames or even more, that's insane. That's too much even for video playback (sound will be desynched) or CAD work.
The other day I played a very old game. It ran V-synched at the screen refresh rate without effort, but was unplayable because there was about half a second of input delay. Most modern games that care about this clap the delay or use techniques which force a pipeline flush (such as visibility queries - but I could swear I saw a game which used visibility queries and still had three frames of lag or so).
This is clearly optimizing for benchmarks. It's as good as useless for anything else. One frame of delay is OK, it's pipelining, it'll improve performance but it won't increase latency. Two is already questionable, it'll improve performance if the workload varies from frame to frame, but 50fps with 40ms input lag sure beats 55fps with 54ms. More is completely inexcusable, whoever is responsible for that should be shot.
Sorry about the rant
random trivia: on Vista, when using the DWM, while you're dragging a window around, the hardware cursor is hidden and a software one is drawn to avoid the window lagging a lot behind the cursor
blah
Saturday, May 9, 2009
Did Not Finish
sqrt[-1]
Friday, May 8, 2009
Oh I just noticed today that the full episodes are no longer available to me - I must have just been clicking though some of their archive links before
mrman
Friday, May 8, 2009
Duke Nukem Fornever
Black Knight
Thursday, May 7, 2009
I also switched from rendering my own cursor to win32 cursor.I just load it at with LoadImage and set it as the class cursor.I also reload the cursor each time the window is resized to keep it's size relatively same to the window,works wells so far.The cursor I renderer with d3d lagged like hell even at frames rates around ~30.
More pages: 1 ...
11 ...
21 ...
31 ...
41 ...
51 ...
61 ...
71 ...
81 ...
91 ...
101 ...
109 110 111 112 113 114
115 116 117 118 119 ...
121 ...
131 ...
141 ...
151 ...
161 ...
171 ...
181 ...
191 ...
201 ...
211 ...
221 ...
231 ...
241 ...
251 ...
261 ...
271 ...
281 ...
291 ...
301 ...
311 ...
321 ...
331 ...
341 ...
351 ...
361 ...
365