Our first game is about to go live. We have found that the performance of sprite kit is reasonably good. We are moving hundreds of sprites around and have effect nodes and sounds. However you must not dare to set the score. The SKLabelNode is very slow.
after running diagnostics it was found that the following code was the culprit.
scoreLabel.text = [NSString stringWithFormat:#"Score: %d",my_score];
In the diagnostic tool the setText command was showing as the most expensive. We even made sure that it was not being called that often. It still resulted in a lag causing the sprites to jerk/jitter/hickup. Once we removed the line...we got smooth motion.
If we are not able to use the SKLabelNodes inside the game scene, what other options are there?
Be careful you aren't loading the entire font family.
If I load "Chalkboard SE" it will take 4-6 seconds, and appear to work.
But if I load ChalkboardSE-Regular , it's virtually instantaneous ~100ms or less.
Once it's added to the scene, subsequent calls are very quick. But if you transition to another scene, it might re-load, so do it early.
I did some testing with font families first, and the results are pretty catastrophic. Caching strong references doesn't help. https://gilesey.wordpress.com/2015/01/14/ios-spritekit-font-loading-times-of-sklabelnodes/
Related
Im optimizing my game for mobile. For that reason a low amount of batches is important. By using Frame Debug I found out that for some reason the Draw Mesh Node command is performed for every single node eventhough the nodes are static and have the same material as far as I understand. The frame debugger says that the objects cannot be batches because the "Objects have different materials". I dont get why and how to fix that. The nodes are all based on a prefab of them. The only thing that is different between them is their position. Please help
The Frame Debug Window:
Prefab for every node:
Example for one of the nodes in game (ONLY their position is different):
Problem solved after 2 days of being sad and watching every graphic performance tutorital on youtube.
Basically I needed to change every .material code to .sharedMaterial because for some to me unknown reason unity creates a copy of the material when using .material, after which each node got its own material. For that reason the performance was so bad. Now it works and my live quality has increased, since everything gets batched, reducing the draw calls from 300 to 10 :)
I hope future readers are helped by this!
I'm currently just trying to learn to use the animator within Unity, I'm very in-exp at animation and don't understand it even in the editor as I focus on programming/scripting.
I have an animation and the states for the animations as-well as the conditions all working perfectly however the animation check for the next state is way to slow. I've tried changing the speed of the actual state but it speeds the animation up and makes it look like my character is walking insanely fast.
I've tried messing around with the frames, making them over a longer time period and making the speed of the state faster however it seems to counter act each other, when I make it longer frames the pace of the animation is slow and then when I make the speed of the state go quicker it just makes the frames tick faster making the animation faster.
What I believe is happening is that the check for the next state of animation is happening once the full animation has been played. However what I need is the check to be happening constantly (as if frame by frame of the unity game not the animation).
Any advice would be great, I've tried using youtube to solve this before coming here however most people are creating a platformer game where as I'm trying to aim for a top down 2d, all directional character movement instead of the linear x axis character movement., and outside libraries.
I deeply apologise for my inability to find a suitable source. I have literally just came across an article online that came across a simple solution.
here:https://answers.unity.com/questions/221601/slow-animation-response.html
basically if you can't be bothered to click the link and you are having the same problem,
find exit-time by clicking the transition and then in the inspector and untick it.
Sorry.
I'm wondering about the best way of reducing my CPU and memory overhead for areas of the game world that do not need to be updated every frame.
I have just started to consider this issue as I'm currently implementing a shadow detection system using Raycasts.
My problem is this:
I can have about 100 lights in my level that on every frame send a Raycast to nearby characters to determine if these characters are in shadows.
My game is a low poly PC game, and I understand the overhead from Raycasting isn't that drastic. So its not a major concern. But I'm still not sure of the best approach to optimising this.
I have been thinking of a few soltions, but am unsure if there is "standard" per say.
1. exit update loop if player is too far away
void Update() {
if (Vector3.Distance(playerPos, transform.position) > someRadius) {
return
}
}
This is the most glaringly obvious solution, with even more obvious concerns.
This update loop will still be hogging CPU cycles , performing 2 calculations on every frame, for every light point.
2. Disable Light gameObjects when the player is too far away
This method is more efficient in terms of CPU overhead, as those will be negated. However I'm still hogging uneccesary memory.
In order to make this solution more scalable I would have to design some kind of "enabler" that keeps track of game objects that should be enabled/disabled based on the player position.
But at this point I know I'm re-inventing the wheel, and feel very sure that there is an industry standard for this.
Is there an alternative to enabling/disabling?
I see a lot of game developers talking about physically unloading areas of their game from memory and writing those areas to disk, when the player is not nearby.
I wonder is this achieved by simply destroying and re-instantiating the objects.
Question
Is Unity opionated about this?
The page here lists an example, similar to my first solution. But they are talking about 100s of thousands of updates per frame here.
Maybe I don't need to worry as much as I think
Thanks!
If you want not render objects, that are not in your camera area, Occlusion culling is what you exactly need. Watch this link:
https://docs.unity3d.com/Manual/OcclusionCulling.html
If You want change how your object looks based on range between camera and your object, You have to use LOD(Level Of Detail). Here is documentation:
https://docs.unity3d.com/Manual/class-LODGroup.html
My daydream app is working fine when used slowly. But when I rotate my head too quick it starts giving glitches first and then the app gets crashed. I am guessing it has to do something with frames/sec loaded during high quality objects rendering or something similar. If someone has a solution, please help me out.
Assuming you have no errors in logcat, visual glitches are generally indicative of extremely high per frame GPU load.
It would be good to profile your app and share the crash report - but the only way I've ever been able to actually crash an app this way is with very large textures.
Check the size and number of textures in your scene - it's possible rapid head rotation could be causing a large number of textures to need to be loaded as objects become visible. You can also see a good list of how large the assets are at build time in Unity by inspecting the editor log after a build. This can help make sure you aren't running out of RAM on device.
Make sure you have texture compression and mipmaps enabled on all textures. Disabling mip-maps on minified textures can easily overload the GPU.
Make sure you don't have too much transparency. Adding a lot of overdraw to the scene can overload the GPU.
Follow performance optimization guidelines https://docs.unity3d.com/Manual/OptimizingGraphicsPerformance.html
https://unity3d.com/learn/tutorials/topics/virtual-reality/optimisation-vr-unity
Make sure renderViewportScale is around 0.7, MSAA is at 2x or less, and you aren't using post-process effects, shadows, or any kind of deferred rendering
Stay below 100 draw calls, 200k vertices on screen.
I'm making my first game with Swift and SpriteKit and have noticed that my game quickly approaches 100% CPU use. I have been posting a lot about this recently, but here I'm now I'm now attempting to pull it apart to determine where my problems are. I originally thought my problem was with instantiating new enemies, so I removed everything but the small user-controlled spaceship and its shooting functionality. However, I'm still hitting 100% after a couple minutes of "play". I'm using the time-profiler instrument to try and figure out whats going on but I'm having trouble. I've broken up the time line:
Here is the first subgraph when the user clicks a homeScene button to enter the GameScene.
I'm not entirely sure what the red and yellow "Heaviest backtraces" with 3256x and 861x respectively mean, but from tutorials I've seen I would imagine that they are abnormally high. Here is the Call Tree as well:
I'm also not entirely sure why the controller textures would be using so much as they are simply setting two textures in the file right before the GameScene class:
let controllerBaseTexture = SKTextureAtlas(named:"Sprites").textureNamed("controllerBase")
let controllerHandleTexture = SKTextureAtlas(named:"Sprites").textureNamed("controllerHandle")
class GameScene: SKScene, SKPhysicsContactDelegate {
Then here is the Call Tree when the game starts and when the CPU reaches 100%:
I'm also confused about what "UnsaveMutableAddressors" are, as I see them very commonly when trying to debug this code.
I know this is a lot, but I'm not sure where to begin. Any suggestions would be awesome. I would also like to know if there are good resources on how to interpret this better because I've gone through a handful and I'm still very stuck.
Thanks for any help!
The profiler shows it's something in your update method for your gameScene. Keep in mind this gets ran around 60 times per second so you don't want to do anything extremely heavy there.