SetUpdateRate 100
Monkey Forums/Monkey Programming/SetUpdateRate 100
| ||
| Is there a real reason to set the update rate to 60? Do programmers set it to 60 because that's the default refresh rate for LCD monitors? What I mean is, if you set it to 100 then you can use an integer based timing system where 1 tick equals 10ms. |
| ||
| You are right, no reason not to set it higher. What you could do is to update different systems of your game with different update rates. Systems could be 'rendering', 'keyInput', 'collision', etc. Maybe it's enough to render at 30 fps, but check for collisions with 100fps. Therefore you would set your UpdateRate equal to that of the 'fastest' system(the one with the most fps). PS: As far as I remember monkey will call OnUpdate/OnRender with your set UpdateRate, except if it notices it can't keep up. It will then skip OnRender() to catch up. |
| ||
| If your update rate is not a multiple of the refresh rate then you will get a different number of updates per frame and your smooth scrolling etc. will begin to look a little lumpy. |
| ||
| Ok on that note, if you set it to 120...would those extra cycles eat up battery power faster than setting it to 60? |
| ||
| The accelerometer yes. BRL has phones that kill many banana frame rates when set to MAX_SAMPLE_RATE. Monkey does need a nicer event queue. Currently updates can only run when render is complete and so cannot poll the state of the touch screen at anything faster than a games draw rate. For physics if you are using box2d i think it would be a good idea to experiment with at 120. I would adjust simulation precision at same time as those Box2D settings are basically a CPU usage dial. Hmmm, I wonder if 100hz Smart TV's based on android can run apps at that rate. Oh FFS, HDTV in america runs at 30/60/120 hz???? |
| ||
| And some at 240. >< |
| ||
| As a note on this, it would be good to be able to poll input and fire sounds at a higher rate. I've gotten ok'ish results when making an instrument app (iOS), but it is audible that timing is limited to the render framerate. Also to even record /register user touch at the correct time, an immediate registration of the touch is required. |
| ||
| I think I'm going to use a 120 update rate for greater timing accuracy. Any final thoughts? |
| ||
| This is a puzzling thread, and I wonder if things are being over complicated. The refresh rate of a game is purely the rate this is needed to animate objects to fool the human brain into thinking that they are moving. You can get this effect at as low as 15 frames per second, 30 is much better, but beyond this most people won't notice. So if I'm going to refresh the screen 30 times per second, why would I want the "update" routine (as opposed to the "render" routine) running any faster than this? If it ran twice as fast, 1/2 of the updates would be pointless because the user is not seeing anything from them. You NEED to refresh the screen say 30 times, so you ONLY NEED to do your updates 30 times. Any more than this is pointless. Picking 120 will just make the device run flat out draining a battery for no reason at all. Having played a lot of PC games I know that regular users like something above 50fps and grumble if it goes lower, so 60 I guess is the default as this will keep even the proper gamers happy. But for small phone games I'm sure 30 would be fine. (note: most cartoons are 24fps) C10B |
| ||
| If you run your update rate at 30 fps you and you have fast moving objects you might get tunneling (on collision) |
| ||
| It's not so much the rendering but how many times the logic updates happen. Running the rendering at 30fps is fine but you may need a higher update rate for the logic when it comes to collision detection and preventing your rendering from jittering. |
| ||
| My main concern was a timer class I was writing and I wanted to keep the update rate a divisor of 1000 so I could throw the time as milliseconds. But now I've modified my timer to use millisecs but also utilize the 60 updaterate so I don't run into render stuttering problems. My solution was to just take the millisecs and divide by 16.6666 which gives me the same ms time base on a 60 updaterate. I just wanted to keep the time keeping as integer only. But I got this solved and moved on. Thanks for the help. |
   |