Does knowing of async and await is useful in Unity?
or knowing asynchronic programming is useful in Unity, or Unity do everything for us?
async and await are useful when doing certain i/o operations, for example when accessing the serial port (which is blocking in Mono otherwise), but this is a realatively narrow area.
Otherwise, normal daily tasks are typically performed on the main thread, as Unity absolutely hates when stuff is called out of order, pretty much crashes immediately.
As for doing multiple things in the background, Unity provides a very conveinient mechanism called Coroutines. Its not actually multithreading but has almost none of the issues real multithreading has.
Asynchronus programming for Unity is probably something you really don't need to learn. I mean, if you want go for it. Always nice to know more about coding.
Unity has certain execution order for all its methods. Just check out the documentation:
https://docs.unity3d.com/Manual/ExecutionOrder.html
As the other answered already states, certain I/O operations, but if you are relatively new to Unity, don't bother about it right now.
Use StartCoroutine(Function()) from the usual functions like Update, Start, Awake or whatever.
Usually you would start IEnumerators in coroutines. Check out Unity docs on that one too:
https://docs.unity3d.com/Manual/Coroutines.html
Cheers.
Related
The last sentence of the Apple Documentation for ARSession.run(_:options) in the the discussion section states:
ARSession.run(_:options)https://developer.apple.com/documentation/arkit/arsession/2875735-run?changes=latest_minor
”After you call this method, the session runs asynchronously.”
What do this mean?
Does it mean it runs on a different thread from the main forever?
Or
Does it mean that while it is transitioning from the previous session to new session it will be rerunning on a different thread?
Or
Does it mean something else?
I really want like to know/understand and would really appreciate any kind soul out there who would like to give some insight:-)
Thank you to the kind ARKit community,
We all learn by sharing what we know
Smartdog
“(A)synchronous” doesn’t have to mean multithreaded.
I’m pretty sure all they mean by that is:
the run(_:options:) call returns immediately
the session is an ongoing process (at least partly in the main run loop, since it has per-frame callbacks, but possibly also involving other threads you don’t see)
This would be in contrast calls that are “synchronous” meaning that all effects of the call complete before it returns.
I'm developing a mobile puzzle game in Unity, when I exit my game to the home screen and return back- the game continues from the same spot and it seems to be fine (without overriding onPause/onStart), am I missing something? Do I need to store variables when exit? What do people usually save? I'm afraid to have bugs in the future.
I missing something?
Yes
Do I need to store variables when exit?
Yes
I'm afraid to have bugs in the future.
Yes, you will. You will run into lost variables issues. It is your responsibly to implement this. Just because everything looks and works fine now doesn't mean anything. The behavior is different on different platforms and devices and also depends on how many apps are already running on the background + current available ram. Usually, you use a class to store all important variables in your class then serialize and save them.
See this post that explains how to do this and provides a wrapper to easily save and load any class. You have to save your game state when Unity is about to be interrupted. These are the functions that can be used to detect this and you must know about:
OnApplicationQuit()
OnApplicationPause(bool)
OnApplicationFocus(bool)
You have to decide which ones to use to save the data. Sometimes, you must use multiple of them due to the behavior of each one in each platform. It's worth reading the Doc on each one to understand what they do on each platform.
I just started studying Unity scripting and I'm having a hard time to understand why some people prefer coroutines over state machines.
I do understand that the code might be more readable for some programmers, but I can't understand why some people say that using coroutines are preferable for performance.
I'm using C# in Unity, and from what I understand the C# compiler converts the IEnumerator into a state machine.
So maybe I'm missing something here. Is it better for runtime performance to use Coroutines instead of a FSM loop for handling behavior and states? If yes, why?
Using coroutines is faster in some circumstances because you can conveniently schedule Unity to perform operations at certain intervals rather than doing them every frame, thus saving processing time. It's really the scheduling that saves time, not coroutines as such.
Take the example you highlighted (in you comment in the other answer) from the Unity documentation, where it says:
Use Coroutines. The problem with Update calls is that they happen every frame. Quite possibly checking the distance to the player could be performed only every 5 seconds. This would save a lot of processing power.
This is saying that a coroutine that uses WaitForSeconds( 5f ) will be faster then checking the distance every frame. It doesn't mean that doing so would necessarily be faster than having your own Update logic that only checks distance every five seconds.
Having said that, I wouldn't be surprised if the coroutine approach is still faster (though less dramatically so) than Update-based checking-every-five-seconds logic, because you'd still save on checking the current frame's time every frame in your game code. Yes, somewhere in Unity's engine loop this time check is still happening and being used to determine whether to go to the next coroutine step, but it's likely highly optimized and it's happening anyways, so the coroutine isn't adding as much extra time checking logic as the Update-based approach.
By the way, for a nice outline of how Unity is likely implementing coroutines, see this blog post.
You have to be careful about what you're using coroutines for. They are great for long-running operations that you don't want to hang the game.
However you have to be very careful about how often you yield in the coroutine. Every time you yield, it takes some time (multiple frames) for the coroutine to resume. If you yield too much, your coroutine will be processing slower than it needs to be. For example, I was working on a pathfinding system. I was using a coroutine to periodically yield while it was running the pathfinding algorithm. This was causing the pathfinding code to take much longer than it should have. I found it worked much faster to just do it in Update.
Coroutines are nice for doing long-running asynchronous tasks like a web request, or downloading something in the background, etc. I don't know that I would recommend using coroutines for your main game processing loop. (especially for input)
I don't think that there is a universal answer to that. It very much depends on what you are doing in your code. A badly written Coroutine might be slower than a well-written FSM and vice versa. I'd say readability and understandability of your code always wins over potential (and at this state intanglible) performance gains. If you got a specific performance issue tackle it when you encounter it. So I'd suggest you use the approach that is most intuitive to you and your team.
I've just started playing around with opengl es on the iphone the past couple of weeks and i'm looking at refactoring some of my code to use Vertex Buffer Objects(VBO). Before I do though I would like to make sure it'll be worth it. The problem is that afaik the only reason you create VBO's is to shift a chunk of data onto the graphics card so that it doesn't need to be retrieved from system ram when it's used. The iPhone however does not have any dedicated ram that I'm aware of so i'm struggling to see why I would benefit at all from using VBO's. I have seen talk around the internet with conflicting opinions and apple certainly want dev's to use it so there's probably still a reason to use them but just wanted to see if anyone on SO had an opinion to add.
I saw no performance improvement on an iPhone 3G. I moved a bunch of stuff to VBOs, but eventually backed it out as it made it more difficult for me to pursue other performance gains. It's not the quick 25% performance increase that I was hoping for.
I've read somewhere that it can make a difference on the newer hardware (3GS), but I don't have references to back that up.
It depends. (sorry).
Rob didn't see an improvement for his setup, but here is an interesting post that did see a large improvement.
The main reason to existence of VBO's is the presence of static data on 3D models. The first bottleneck you encounter is the slowness of copying data to video memory (by using the unavailable glBegin/glEnd block or glVertexPointer, glBufferData and friends).
Let's imagine the old "flying toaster" screensaver. All toasts are static (changing only the position) - why waste resources copying them every frame from CPU's memory to GPU's? Copy it once with buffers and draw it with a single command. And, depending on how you do animations, even the animated toasters can be described in a static fashion.
My first 2D game I started without VBOs. When I changed to VBOs, no difference (like Rob). But, when I refactored to use more static buffers, FPS gone from 20 to 40. Since my goal was to reach 30, I was satisfied. I had some ideas to refactor even more, leaving everything static, but I don't have time now (game is on review, next one to come).
I am writing a small game by using cocos2d. It is a shooting game. Player on one side and enemy on other side. To run the both actions of player shooting and enemy shooting do we should use threads ? Or can we do without using them. At present I am not using threads. But I can manage to do both actions of player and enemy at same time. Should I use threads compulsory good performance ?
Or am I doing wrong without using threads ? Please help me from this confusion.
Thank you.
You should use threads when it makes sense, i.e., when you would otherwise block the main (UI) thread during a time-consuming operation. Examples of expensive operations include loading images and sounds from disk and retrieving information from a network. For the event loop of a game, threads are not essential because the events in a game are not perfectly simultaneous (indeed, two operations are never simultaneous on the iPhone because it is a single-processor system). Instead, you can perform all of your game logic sequentially and update the UI as necessary. If I'm not mistaken, though, a framework like Cocos2D probably uses a dependency inversion model that calls into your client code, and as such it will create any necessary threads behind the scenes. I'd suggest looking at a tutorial on that specific framework to see what the recommended style is.