koobas.hobune.stream
Is it possible to seperate render and input frame rate (iOS)
Consider we have a game with good graphics, we just can render it with 30 fps, but we would like to get a better control with Multi-Touch (many slice style input defined in our game system).
Since the Input.touches only get updated after last frame, and the document suggest us to access it in the Update(), so if our game rendered by 30 fps, we just get a 30 fps input datas.
I am wondering, are these two thing necessary always at same frequency? Is there a way to make the input updated at a different frequency from the rendering(ex. 60 fps)?
I'v searched the answers and forum, no luck. Thanks very much if there's any help.
The frame rate is the number of game loops made in a second, everything in your game (Graphics, physics, input, sound, etc.) are going to be limited by it. You can get around it to some degree by off loading some of the more expensive tasks into coroutines, but you'll need to make sure your code logic can handle those tasks not being completed at any given moment.
There should be already two frame rate in my $$anonymous$$d, it is for Update(), and another is for FixedUpdate(), they can be different. What i want to do is add another just for Input detection.
The method by which input is detected in iOS is actually controllable in the XCode project and there are a number of different approaches - missing touch Ended etc is absolutely possible (indeed probable) in some circumstances if rendering takes too much time. See this documentation for some extra details - though its far from complete.
Basically it appears that you cannot do input detection more often than your frame rate (you certainly can't do it in FixedUpdate) - presumably because you are unable to react to it - though of course I can envisage scenarios where the ti$$anonymous$$g of the input could be used - I have yet to find a way of making this work.
There was briefly some excitement about using the events of OnGUI to improve the timer reactions, but I believe that they proved unreliable - unfortunately I cannot find the answer about this. It might be worth a go - the principle is that OnGUI gets called once for every input event and therefore you might get the input at the time that it occurs - as I say, I think this actually proved to be incorrect.
