Why does function draw() draw frames 60 frames per second? Was there limitations where codea may crash or is any other reason. Just curious :-?
@kirorp the iPad, same with most low end computers screens only support a refresh rate of 60Hz or 60 frames per second, I believe the hardware is made for a refresh rate of 60 as well, otherwise I reckon it wouldn’t be limited to 60fps.
Typically, most games run at 60 FPS now and days. There’s not much of a point than going much higher since your eye can only see at 20 FPS, but some people claim that even though you can’t tell when something is slower, going about 60 FPS (like 120 FPS) tends to make it seem like you’re looking into the game. Some very nice movie theaters play movies at very, very high frames per second, and I’ve heard it’s like looking into the movie, even in 2D.
@Zoyt I think it is the average 30fps for the eye, it depends on the cognitive speed of the persons brain, which decreases with age.
@Luatee, I suspected hardware limitations but wasn’t sure.
@Zoyt, I didn’t know human eyes could only see 20 - 30 fps so that could also be a possibility. Why have super high fps if people won’t notice it. But games can something’s look and feel better when played at I higher framerate. Again as Luatee said, it depends Manley on how fast your brain is to reading what your eyes see.
This “how many fps can the eye see” discussion is useless.
Experiments with fighter pilots have shown they can recognise brief flashes of light lasting indescribably low amounts of time. The eye doesn’t see at any set fps, it’s completely unlike a camera etc.
I mean, seeing the effect when a frame rate drops from 60 to 30 is clear as day.
@Causeless that’s true I can see a clear difference between 30-45-60 FPS, but it doesn’t look out of place until around under 30
I heard 20-30 FPS somewhere, but that doesn’t mean we can’t see brief flashes. As you said, there is no clear definition on how many FPS the eye can see.
Also, @Causeless, it’s typically not a good idea to insult something (in general, but also), then go ahead and take part of the discussion.
I love the fact that codea plays at 60 fps. Many other 2d game development platforms are limited to 30 fps. I can certainly notice the difference when objects move from one place to another in 60 fps vs 30 fps even if they move at the same relative speed.
@Zoyt I wasn’t trying to take place in the fps discussion, just giving reasoning to the claim that talking about how many fps we can see is useless.
@Zoyt if you have the opportunity to go to an i-Max cinema, do it! There is one in most major US cities (ie San Diego,…). You will se the experience of fast frame rate for yourself. It is… wow!
@Causeless The word “useless” is a probably what’s gotten the reaction. The discussion is definitely not useless, if for no other reason than to make the point that people do not see in “frames per second”. So a better phrasing might have been “In fact, ‘how many fps can the eye see?’ is the wrong question because the brain doesn’t work that way. Perhaps the right question is ‘At what fps does it become obvious that it is a series of static images?’” and then give some links to back up this point of view.
At the core, the question being asked here is: “What FPS do I need to run in order to ensure that my game/program is perceived as running smoothly?”. Phrasing it as “What FPS does the eye see at?” reveals a misconception as to how the brain works, but the core of the discussion is not actually about how the brain works so whilst it is nearly always beneficial to point out misconceptions, in this case it’s not a central issue.
Basically, the faster the action, the more frames per second are required to avoid blurring and aliasing (when using compression). It’s the same with audio–the more samples per second, the less aliasing and loss of high end. The old movie standard was 24fps, but has crept up to 30fps and higher.
Andrew_Stacey has the right of it though, the important question for apps and games is what FPS is enough that the user doesn’t notice it being slow or jerky.
The hardware maxes out at 60fps, but if you code takes a decent amount of processing time then this will drop. So when building and tuning a game you need to look at how slow it gets on it’s busiest screens and ensure it’s efficient enough that it doesn’t ruin the experience.
The other important factor is it will run as fast as it can, but not at a fixed speed, so you can’t assume draw will be called at a fixed timing, so you have to factor in frame time if you are computing movement etc yourself. If you are using physics then luckily it already works movement based on clock not on drawing speed.