3 ms·

Hi! I have thought about the same issues as you described. I see this as an interaction between two parties: producer and consumer. If the producer is so slow,

by eurekin 11y ago

Hi! I have thought about the same issues as you described. I see this as an interaction between two parties: producer and consumer. If the producer is so slow, that the consumer manages to ask 1000s of times for a product before it's created, than we have a case for reactive events. Game programming is different: the rate at which the events are produced greatly overwhelm the consumer rate (60 fps is nice target for graphics). There is one exception though! I have found a very annoying issue in a lot of games: they sometimes drop input. If you happen to play some fast action game and the game is crunching too much for the moment and drops FPS, also assuming that input events are polled once per frame, then a lot of input events might go unnoticed. Only the last input state for one frame is recognized by the game logic, but there might have been more than one. So, in my opinion, input handling would be better handled in a pull fashion, where all the events could be processed immediately, for example: the rotation matrix could be updated off the game loop many times between one frame. I hate all those 3d viewers which loose all interactivity if the scene is too large. It doesn't have to be!

hacker_9 11y ago
I'm afraid you would just be moving the problem to another area of the game. By updating the camera matrices on a separate loop, the render thread may draw some objects with one view-proj and then the last few objects with another. This would lead to the objects look like they are flickering. If you queued up the input then you could imagine this would be quite undesirable if the game suddenly unfroze and did all the movements that made sense a second ago but not now (but for a 3d viewer tool this would be desirable, much like how a text editor will sometimes freeze but then catch up with everything you typed during the pause).
- eurekin 11y ago
  I wouldn't update the view matrix directly. Rather let the input events update one matrix and the game loop would copy it only once per frame. This way all the input events would be summarized in that matrix and the view would follow the dragging cursor, even at 3FPS. So, many input events are seen as a summarized version in the game loop. Not many of them.

by eurekin 11y ago

hacker_9 11y ago

I'm afraid you would just be moving the problem to another area of the game. By updating the camera matrices on a separate loop, the render thread may draw some objects with one view-proj and then the last few objects with another. This would lead to the objects look like they are flickering. If you queued up the input then you could imagine this would be quite undesirable if the game suddenly unfroze and did all the movements that made sense a second ago but not now (but for a 3d viewer tool this would be desirable, much like how a text editor will sometimes freeze but then catch up with everything you typed during the pause).

eurekin 11y ago
I wouldn't update the view matrix directly. Rather let the input events update one matrix and the game loop would copy it only once per frame. This way all the input events would be summarized in that matrix and the view would follow the dragging cursor, even at 3FPS. So, many input events are seen as a summarized version in the game loop. Not many of them.