Any reason to NOT use "fps=60" in config.lua?

The “default” frames-per-second in Corona is 30. But the documentation clearly shows how to increase that to 60.

My instinct prompts me, why not use 60 frames per second when it’s available? Assuming the device is a reasonably modern, i.e. an iPhone 3Gs, iPhone 4, newer Android, Galaxy Tab, etc… is there a reason why I should be restricting the game to 30 fps when (if I recall reading somewhere) most of the newer devices support 60 fps and perhaps even more?

There’s probably some totally obvious reason I’m missing here. Maybe it throws off the simulation? Causes graphic texture tearing? Something even worse?

Any thoughts on this are appreciated! [import]uid: 9747 topic_id: 4330 reply_id: 304330[/import]

Of the top off my head I’d say that one reason might be that for a lot of games a consistent 30fps is more than enough however if you up that to 60fps you might not always get it causing jumping etc. [import]uid: 5833 topic_id: 4330 reply_id: 13599[/import]

The 60 FPS option is very smooth, however, I haven’t used it in any of our games (or even the recent Ghosts vs. Monsters sample app) because I notice it’s harder to get decent performance on anything less than an iPhone 3GS (even iPod touch 2G has lots of slowdowns at 60 fps with the games I’ve tested, and that device is usually pretty good at playing games).

I wish there was a way to conditionally set the app from 30-60 depending on the device, and then make necessary corrections for each one because I would LOVE to use 60 fps (it makes everything SO much smoother), but I just don’t want to exclude so many folks because there are still A LOT of people using the iPhone 3G (which performs WORSE than the iPod touch 2G).

[import]uid: 7849 topic_id: 4330 reply_id: 13618[/import]

Jon, now that you’re a staff member is there a way you can push to get this kind of conditional check implemented? My game is gorgeous at 60 FPS on my iPhone 4, but needs to run at 30 FPS on an iPhone 3G to avoid stuttering, as you point out. I’ve coded my game so that it runs properly at 60 FPS or 30 FPS (that part wasn’t so difficult), but now there doesn’t appear to be a way to switch between the two settings depending on which device the app is running on. Surely many Corona users would love this kind of flexibility, and it would help promote Corona to show complicated games running at a smooth 60 FPS on an iPhone 4. [import]uid: 14598 topic_id: 4330 reply_id: 36592[/import]

The most you could do is make sure to enter a feature request, so that way when the next feature “vote” comes around, it’ll be sure to be on the list. At the moment that really is the only way to move features up on the priority list.

In the meantime, you could actually exclude people running anything less than a specific iOS version, such as 4.0 (or 3.2.0 for first gen iPad) if you don’t want your game to be downloadable with those with underpowered devices (so they don’t wind up with a bad experience and give you a 1-star rating).

To do that, make sure this is in your build.settings:

[blockcode]
settings =
{
iphone =
{
plist
{
MinimumOSVersion=“3.2.0”
}
}
}
[/blockcode] [import]uid: 52430 topic_id: 4330 reply_id: 36594[/import]

Isn’t conditional fps already possible?

Since config.lua is where you set fps you can detect the system, platform, and model using system.getInfo(). Depending on what those checks return you could then conditionally set fps to 30 or 60.

Here’s a simple example config.lua that sets fps to 30 if an iOS older than 3.2 is detected:

local sysPlatform = system.getInfo("platformName")  
local sysVersion = system.getInfo("platformVersion")  
  
local subSysVersion = string.sub(sysVersion,1,3) --truncates system version so 3.2.1 becomes 3.2, etc.  
  
if sysPlatform == "iPhone OS" and tonumber(subSysVersion) \< 3.2 then --if os version is iPhone and less than 3.2  
 sysAdjustedFPS = 30 --if os less than 3.2 it's an original iphone and os can't be updated. Use 30 fps  
else sysAdjustedFPS = 60 --otherwise use 60 fps   
end  
  
application =  
{  
 content =  
 {  
  
 fps = sysAdjustedFPS,   
  
 --Original scale for iPhone 3 native res.  
 width = 320,  
 height = 480,  
  
 scale = "letterBox",   
  
 },  
}  
  

My own issues with fps are related to how Corona handles physics. It seems that Corona’s implementation of Box2D is completely dependent on framerate, whereas it really should be completely independent.

If I set fps to 60 my game looks and feels great as long as it can maintain that rate. But there are times when it drops down to 40 fps or so and the game itself actually slows down. To prevent that all the physics properties, like gravity, need to be updated on the fly to compensate (totally impractical).

If you do the conditional fps adjustment above and need physics you’d need to have separate physics properties for each fps version, and test both to make sure they behaved identically (also practically impossible to achieve from personal experience).

If Corona’s physics was time-based instead of framerate-based you could simply set fps to 60 and be done. Even on a crappy iPod 2 making only 20 fps your app would behave identically. [import]uid: 9422 topic_id: 4330 reply_id: 36600[/import]

I didn’t realize that Apple dropped support for the iPhone 3G with iOS 4.3. I was going crazy trying to figure out a property of system.getInfo that would work for this purpose, since there is no way to directly get the model (is that a limitation an oversight or something mandated by Apple?).

At any rate, thanks a lot, XenonBL! I just tested your code (changing 3.2 to 4.3 since I can’t get 60FPS on pre-3GS systems) and it works like a charm: 30 FPS on my 3G, 60 FPS on my iPhone 4. It’s possible some people running older software versions on their iPhone 3GS/4 will end up with 30 FPS this way, but that’s better than forcing everyone to 30 FPS in my opinion.

As for physics, I’ve ended up avoiding the included physics engine due to a number of bugs and other issues like what you describe. It’s forced me to re-learn a lot of my High School Geometry and Physics, so I guess that’s a positive side effect. I’d love to see Ansca fix their implementation of the Box 2D engine though. [import]uid: 14598 topic_id: 4330 reply_id: 36611[/import]

Of course the physics engine should be time based. We have not touched the physics engine yet, but had noticed some bugs in example apps. eg. things flying through solid objects. Is this related to the frame locked implementation of the physics engine? [import]uid: 28534 topic_id: 4330 reply_id: 37108[/import]

Yeah I’ve noticed that too. Seems VERY VERY strange to create a frame based physics implementation.

Anybody know how to get around this? [import]uid: 8545 topic_id: 4330 reply_id: 57688[/import]