0
votes

OK, that's the problem. Currently I'm writing a OCX/NPAPI plugin for my game thus my game can run in the web browsers. In the current implementation, I use SetTimer to 'tick' the updating and rendering of my game (the plugin dll) but I find the FPS (frame per second) can only be 64 at most on my machine. I found it's the problem of the windows timer, since the timer can only be called by the message peeking process of the browser's plugin implementation which I cannot modify, in other words, the timer cannot be faster than the process handling speed of the browser.


So my question is,

  1. Can I break the 64 frame rate restricted by the browser message handling or speed up the timer proc?
  2. Or should I move my game to a separated thread but how to handle the window message (user input, window resizing, etc.) and the game thread can receive.

thanks in advance!

1

1 Answers

1
votes

If you are using a windowed plugin then your best bet is to do all the rendering and such on a seperate thread. Just use some sort of threadsafe queue or something to pass the window messages across the threads; fun with mutexes, of course, but it's not really that hard.

If you're using FireBreath (which would simplify a lot for you) there is a FB::SafeQueue class that you can use. If you're not using FireBreath you could steal it, though it requires boost, but it's not really that hard to make a threadsafe message queue anyway.

If you're on the main thread trying to do all the game logic you likely will have performance issues anyway.

If it's a windowless plugin, then you're out of luck.