quote:If you don't mind multithreading, there's a better way to deal with the mouse than what's described here. The method here is a one thread method, which polls the mouse every frame. Good for high frame rates, but not so good for low frame rates – the mouse cursor will appear "sluggish." The best way to deal with the mouse is to start a separate "mouse-rendering" thread, which continually monitors WM_MOUSEMOVE messages, and takes care of updating and bltting the mouse cursor each time the mouse is moved. The advantage to multithreading the mouse pointer in this manner is that your mouse will still be fluid regardless of how slow your game's frame rate is. Having a separate thread for your mouse will make the game feel responsive, regardless of frame rate.How i was thinking of dealing with this was to create a function in the mouse class called blitmouse, that calls the mouse member function refresh(to get the state of the mouse) then draws the mouse) my question is can I then create a thread that uses this function blitmouse even though it calls another function refresh. And will there be any problems in my main game loop if I call refresh independantly. While the blitmouse thread is running? The difference between this approach and the one described is I am not setting up another function that polls WM_MOUSEMOVE and the functions/ data are local to the object so less chance of conflicting data. I will also be able to destroy the thread in the deconstructor which would be nice. [edited by - curlious on October 23, 2003 10:05:06 AM]
mouse multi threaded
Author
This will not work in a double buffered pipeline
Even though you can multi-thread to update the position of the mouse, you cannot draw it faster than your frame rate, simply because to do so you would have to render the mouse and then flip the buffers and whoops! you were only half way through rendering that scene...
George D. Filiotis
I am a signature virus. Please add me to your signature so that I may multiply.
Even though you can multi-thread to update the position of the mouse, you cannot draw it faster than your frame rate, simply because to do so you would have to render the mouse and then flip the buffers and whoops! you were only half way through rendering that scene...
George D. Filiotis
I am a signature virus. Please add me to your signature so that I may multiply.
Author
I was thinking of using a secondary surface, to blit whats behind the mouse and another surface for the moust image. First blitting whats behind the mouse to the secondary surface then blitting the moust from the its own surface to the primary. Then finally blitting the old contents back in the previous position of the mouse. Not using the double buffer at all for the mouse.
Well, you would have to use a triple buffer this way. The buffers would then look like this:
[Render buffer] - [Rendered buffer] - [Primary surface]
You would have to copy everything from the rendered buffer to the primary surface and then blit the mouse onto it. But I think you would have quite a performance loss when you keep copying the buffers. Not such a good idea imho.
Toolmaker
-Earth is 98% full. Please delete anybody you can.
[Render buffer] - [Rendered buffer] - [Primary surface]
You would have to copy everything from the rendered buffer to the primary surface and then blit the mouse onto it. But I think you would have quite a performance loss when you keep copying the buffers. Not such a good idea imho.
Toolmaker
-Earth is 98% full. Please delete anybody you can.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement