Should I strive for anything less than maximum device FPS?

I have an issue where I have a very basic 3D scene/game (Android) and I have buttons to show and hide all of the content to test. The issue is I can lose 3/4 FPS out of 30 just turning on some basic effects. This takes me down to a laggy 10FPS when I have everything on. It makes me wonder whether I will be able to achieve 30FPS consistently throughout gameplay.

So my question is should I aim for max FPS, which is 30 for my phone, or do I just eyeball it and take what still looks reasonably good?

Thanks

 

If you go below 30fps on a target device you're only asking for trouble. You should look into mobile optimised effects because it sounds like you're using desktop ones if a very basic scene (screenshots?) chugs like that. We also need to know what device you're talking about.

 

I understand there's a lot of particles going on and some I definitely need to improve but it seems as though I won't be able to get to something half as good as this if I optimise it. I am using an old HTC M8 so the specs are relatively low end but a good baseline for performance.

 

Sub-30fps games which are not turn based will play badly. It's that simple. Do you want to make something play badly? will a badly playing game sell? Questions anyone can answer.

 

The thing is 20FPS plays pretty well but now it seems like I should not be satisfied with 20 and must achieve 30, that was my question. i.e. Do not sacrifice FPS for graphics, not matter how small.

 

If it plays well, then go for it. Perhaps your style of game suits a slower pace?

 

As this is my first real attempt at making a decent game I have a lot to learn about optimisation and feel I can improve the FPS so I will look to try and achieve 30 but may go to 20-25 at worst as it is still playable and will be fine on higher end mobiles. (Unless anyone thinks there is a problem with that strategy)

 

If your problem is that you have a low-end device, there's at least hope that it will play well on most recent devices. You could try to test the FPS when launching the game and maybe lock the frame rate to a lower setting, because consistent rates are better than jumping all over the place.

 

This is why the quality settings exist. Just define your quality settings properly and adjust it when you're on a lower end device. It won't be that beautiful, but this is the price when someone wants to play your game on an old device. They are probably already used to the fact that their games aren't looking that good than on the latest devices.

 

I actually use those as well but the majority of the FPS is lost on effects not things like shadows, textures or lights or any of the things those settings control. Unless you are referring to something else.

 

How do you lock the framerate and how does that work when it needs to be less than what it is locked to? Why not just lock it to 30 all the time?

 

In your screenshot it looks like you might be using the built-in terrain system? If so, I don't think that's a good fit for a top-down game. It's designed for efficient drawing over long draw distances where you can see a lot of terrain at once. You're looking straight down at a small patch, so having a terrain that's a mesh and splitting it into small pieces is likely to be far more efficient.

This, very much.

When playing around with UWP deployment to an Xbox One with a similarish top-down game I found that switching from the standard shader to one that did only what I needed took my game from visibly struggling to a solid 60fps.

Before you do anything, though, connect the profiler and see if you can specifically identify where the time is getting eaten. No point optimising one thing if it's another that's dragging you down.

 

There is a target frame rate setting in Unity which you can set via script, and the quality settings have an option for every other vertical blank, effectively making it 15fps on your device.

But do check out the various other quality settings, as mentioned above. Shadows, lighting, AA and other post-processing are the biggest hits. Anisotropy and texture quality might not cause a noticeable hit to frame rates, but I dunno about low-end ARM devices. Some of them get much slower even when using alpha channels in textures. Camera distance has many different settings - shadows, LODs, terrains etc. can all be set to different maximum (and minimum!) view distances. The less you draw, the faster you go.

As said above, slimmer shaders improve performance a lot too, especially if you weren't actually using mobile shaders. Anything that improves quality costs performance, so tick and untick check boxes and keep trying on-device builds. Unity's terrain system in general has been problematic on mobile too. Perhaps decorating a large, flattened cube with meshes would give you better results if you're not entirely reliant on the way terrain texturing works.

A general optimisation trick you can use to keep the frame rates decent once you have it running OK, is to not use so many Update() methods on scripts. Remove all but one, and have that one method run the rest via delegates. When you use that method you can get to quite a lot of objects before taking a frame rate hit from Update() slowing you down, and it's easier to wrap your head around than the still experimental ECS and job system.

Profile everything and pay attention to your time spent in code every frame. 1/fps = time you can spend in code every frame. That gives you about 33ms at 30fps, twice that if you skip every other vblank, give or take some overhead.

 

Thanks for the advice.
Do you happen to know what costs more in those settings? i.e.e Shadows, AA, texture quality, lights etc?

 

The profiler will tell you because the cost changes per game. Just test stuff?

 

Yeah, just run the profiler. It takes some getting used to, but you'll start seeing patterns eventually.

 

Can I, to save resources, have a box collider the same aspect ratio, and angle as my camera but slightly wider and slightly higher so it is just out of the viewport and dynamically show and hide content as it enters or leaves the box collider? So just before it is in camera view it loads and just as it leaves the camera view it hides? Or is this bad practice as showing and hiding takes up cpu time in itself?

EDIT: I have come to the realisation that if it is not enable it will not trigger the box collider, derp.

Thanks

 

What you're describing is very similar to "frustum culling", which is done by game engines for rendered objects anyway.

There can still be benefits to doing it for yourself, but it's something I'd only look at under fairly specific circumstances.

 

Unity has built in occlusion culling using Umbra. You can use OnBecameVisible or
OnWillRenderObject if you want to only do some stuff in tour code when the entity is visible. Or use the Cullign group API

https://docs.unity3d.com/Manual/CullingGroupAPI.html

Also dont forget to bake occlusion

 

If it's less than 60fps I toss it in the garbage at 120fps..

 

Anything less than 90 fps with stereoscopic cameras is garbage

 

What phone has a 30 FPS limit? I have always gone for 60 FPS and every phone I have tested on has been capable of doing that. It would be useful to test on a phone only capable of 30 FPS because they exist, but I don't know of one.

 

Put one or two desktop post processing effect on the screen and you will know the answer: all of them.
It's not hard limit per say. It's that usual mobile devices have different capabilities. Aiming to 30FPS minimum is okay. It's not ideal or beautiful, it's okay. More important to play your game seamlessly than play it beautifully.

 

No.
FPS or die.

 

To give a serious answer to the thread title question: "should I strive for anything less than the maximum device FPS?" Doing this often makes perfect sense.

Some games need silky smooth motion and for input to be as responsive as possible. For those games you want to get the FPS as high as possible. For other games, 30fps is perfectly acceptable and aiming for more could be wasting electricity for no tangible gain. On mobile devices that means battery drain.

Also consider that if you're going for maximum eye candy then halving your frame rate from 60 to 30 means you can afford to spend twice as much time per frame making stuff look pretty. This is the approach most console games take.

Someone has already pointed out that a consistent frame rate can provide a better experience than a higher but highly inconsistent one. So tuning your game for a minimum 30fps and then using v-sync or similar to lock at that frame rate can make a lot of sense.

Note that I am not suggesting that you don't take reasonable steps to optimise your game. Targeting a lower frame rate is no excuse for getting sloppy in the performance department, as it wastes power, increases heat, raises hardware requirements (ie: shrinks your audience) and gives your artists and designers less headroom when making content.

 

Can someone please explain how a game can be set to a framerate and what happens if the actual framerate is below or above what is set?

I'm confused how this is possible/works.

Thanks

 

Once a frame is rendered it does not have to be displayed immediately.

When running at a fixed frame rate, the game renders the frame in less than the intended amount of time between frames. It then waits until the appropriate time before putting that frame on the screen.

If your game can not complete a frame before it is meant to be displayed then, typically, that frame waits until the next refresh before displaying.

 

Well. Since we are talking about Android, the power of the devices is so vastly different that really *aiming* for a specific framerate without talking about a specific device doesn't make a lot of sense. (unless of course you only limit your market to very new and high end devices).

So optimise as much as you possibly can. If you're not getting 60fps on a new high end device, you're doing something wrong. And then maybe have an option for users to be able to limit to 30fps (maybe try to have it default to that if the device is old), since unstable 30-45fps is worse than stable 30fps.

 

Honestly ,even a phone of that age shouldn't be struggling like it is.

 

I have not optimised very well so I understand why it's struggling. I will just have a low, medium, high graphics settings for the user and let them decide how good a graphics their phone can handle.

 

That's not specific to Android. Performance targets should be in the context of specific target hardware, otherwise they're useless as a reference point.

 

Perhaps I'm not putting enough emphasis on the situation here.

Your game, from that screenshot, is not doing anything an iPhone 4 would even struggle with, and that phone came out 8 years ago. My guess is that your quality settings are all at default, that you're making use of desktop targeting post processing effects, and that you've got things like AA enabled. Judging by what's going on with the specularity on the textures, you're probably using the standard shader rather than a custom solution. It also looks like all your particle effects are completely raw rather than making sheet based solutions for your smaller particle groups.

An option for different graphical settings doesn't mean much of anything because you don't even have a performance baseline to test against.

 

I don't think emphasis is needed? Everyone starts somewhere and there's a heck of a lot to learn. One step at a time, right?

 

Yeah I know where AA is and that's about it out of all of that so give me some time and I'll try and get this thing up to scratch.

 

The original message said the max for phone was 30FPS, no mention of that being for only the their game. So I asked what phone is limited to 30FPS.

Aiming for 30FPS is fine for some games, but not for others. All my games so far have been capable of running at 60FPS on any device I tested (including an iPod Touch 1st gen for the first games), although it took a lot of effort to achieve that (my current game was 2FPS on much newer devices when I first tested it), but I put all that effort in because they play better at 60 (I have tested them limited to 30).

 

I'm not a mobile developer so I don't have much experience in it, but AFAIK there is no device which locked into 30FPS. AFAIK they either 60FPS, 30FPS or lower, you have mandatory VSync. But again, it's just I read it somewhere, I'm not the best person to answer if such device exist (I haven't seen them all).

 

Do not underestimate the lag-ability of the iPhone 4 (4s anyway) because that sucker is being a real pain for me right now. I test on those and comparable android devices and it can be lots of trouble to get 30 FPS solid on that sucker - and god forbid you push the memory too high, or the OS force closes your app.

Anyway, as far as what I see in that screenshot, there are two big issues. 1) Unity built in terrain (it appears). This is a solid no-go on mobile, even with light shaders and limited settings its always a huge performance drag. And then 2) skidmarks that might be the unity example skidmarks. They generate lots of garbage and just murder FPS when the GC kicks in on mobile.

I could be wrong, but if that is the case, those are two big targets for mobile perf killers right there. I sure hope your not using the standard shaders!

If your using the unity example skidmarks - ditch em and use Nition's skidmarks instead. If you are using the built in terrains, convert them to meshes and use mobile diffuse shader.

Oh another thing - set the target frame rate to 60 or unlimited when testing on android, so you can get an idea what the ceiling of performance is, then when you get close to release, cap at 30 to avoid overheating devices. Better leave headroom above 30 (ideally smooth 60) so that the game runs good on junk devices and bogged down ones.

Don't instantiate - pool! Mesh compression should be as high as you can go without losing quality visually, same for textures.

Profile, profile, profile. Whoever started the idea that you should never optimize early was not considering these toasters we have today. Optimize out of the gate, and as soon as your past the prototype stage treat everything like its final, don't leave garbage or GetComponent calls around. Use the frame debugger to make sure your getting a reasonable amount of batching, and share materials on as many objects as possible. Mark stuff that never moves static. Don't use dynamic shadows (or at least the built in ones) and instead bake lighting, and use blob shadows.

 

It's not specific to Android, but the point I was trying to make, out of all target platforms, Android is the one that varies the most. Get a couple random Android devices made in the last 3 years and the power difference between them is going to be insane.

All other platforms (Console/PCs/iPhones) are less insane in that regard.

There are a handful of 120fps devices as well.

 

Its pretty interesting that in VR 90 fps is sweet spot while in desktop you want togo above 120hz. Must be neck/head speed vs mouse speed.

 

Yes, there are multiple reasons for variations, including...

VR needs 90FPS as it makes a major difference to motion sickness.

For PC, higher FPS on FPS (frames-per-second on first-person shooters) means smoother tracking on fast rotational movement, and a fractional head start on reactions.

Console games often have 30FPS because a prettier image is an easier sell in mass marketing than 60FPS.

Mobile varies between 30FPS and 60FPS. 30 to save on battery life and because of limited performance (you could probably go even lower on hidden object games, but then the interface can appear unresponsive), 60 for tracking fast movement (for example, side-scrolling endless runners benefit here a lot). The maximum screen refresh rate was 60 until recently, and is still a common limit. We may see games highlighting 120FPS when it doesn't mean alienating the majority of the user base.

 

Difference is on VR anything above is waste, while on desktop is does make a difference. I went from 75hz IPS to a 144hz IPS, world of difference.

 

Profile and Deep Profile allow you to see what is chewing through your 16.6 ms frame time, if you run the profiler and share a screenshot of the hierarchical view it provides it will become obvious what is slowing down your frame rate.

Otherwise we are all guessing, so Profile then Optimise, you could be changing things that are not impacting the frame rate when there are a couple of hot spots that will show up in the profiler and allow you to optimise and hit your target framerate with a couple of tweaks.

Remember the 80/20 rule only 20% of your code is responsible for slow down and will need optimising, the trick is finding that 20% and not changing the other 80% in the process!