Unity lies to you about null
What is the difference between component == null, component is null, and !component?
What is the difference between component == null, component is null, and !component?
Early last year, I wrote a blog post which explained how Unity's coroutines work. In my conclusion, I expressed that I underestimated the level of wizardry they involved, so much so that it went far beyond the scope of the article. I figured it was time to perhaps elaborate on that, and show you a glimpse of Unity's game loop and how the coroutine system works in the engine (at least, my interpretation of it.)
Dear friend,
Well, let's get the awkwardness out of the way. My name's Oliver. What's yours?
Oh wait… right… this isn't so much a conversation as it is a safe destination for me to enact my tendencies to portray my chronic verbal diarrhoea as if I've taken textual laxatives.
I recently wrote a post which explained how Brackeys' Save & Load system could be fixed so that it isn't victim to a major security flaw regarding BinaryFormatter, by instead using BinaryWriter and BinaryReader. This guide will explain how to write a better, portable, more scalable save & load system from the ground up.
Buckle your seatbelts, we have a lot to cover.
Coroutines in Unity are a way to run expensive loops, or delays in execution, without having to involve multithreading.
That's right – although it's commonly believed that coroutines are multithreaded operations, they in fact run on the
main thread. But have you ever asked yourself why coroutines return IEnumerator? What does that even mean? We'll take
a
look at how they work, and I hope to explain just how genius they are.