https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Game_Engines_2021W_Lecture_6 2026-04-08T03:15:38Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Game_Engines_2021W_Lecture_6&diff=22885&oldid=prev 2021-01-28T22:53:57Z

<p>Created page with &quot;==Notes== &lt;pre&gt; Lecture 6 --------- comments on journal Show &amp; Tell concurrency in game engines &amp; godot using gdb with godot (to debug the engine) Journal comments - many...&quot;</p> <p><b>New page</b></p><div>==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 6<br /> ---------<br /> <br /> comments on journal<br /> Show &amp; Tell<br /> concurrency in game engines &amp; godot<br /> using gdb with godot (to debug the engine)<br /> <br /> Journal comments<br /> - many of you are making good progress<br /> - but many of you seem to be very undecided in terms of project directions<br /> - many seem a bit ambitious<br /> <br /> It is important to really understand what you want to do, but you<br /> need to have reasonable goals<br /> <br /> Strategy: work on a piece of a grand vision<br /> - key differentiation<br /> - technically interesting<br /> May not be too fun on its own<br /> <br /> <br /> Concurrency<br /> - notice we saw that godot has lots of threads running<br /> - we need them to use multiple cores<br /> - but threads make life very difficult, because concurrency<br /> <br /> with lots of transistors, we get many cores<br /> <br /> can be general purpose (CPU) or special purpose (GPU, tensor cores, etc)<br /> <br /> most of the special computational units are SIMD-ish<br /> - single instruction, multiple data<br /> - so, inherently parallel<br /> <br /> Some tasks are more straighforward to parallelize<br /> - rasterization of 3D graphics<br /> <br /> Other tasks aren&#039;t<br /> - game AI, game logic<br /> <br /> So, what do we do with all the cores?<br /> - how do we coordinate activity?<br /> <br /> well, why not just have different threads work on shared data?<br /> - race conditions will lead to non-deterministic bugs<br /> <br /> We can solve race conditions with locks<br /> - when a thread accesses a data structure, it &quot;locks&quot; it, and only unlocks<br /> it when done<br /> - this is mutexes, semaphores, etc<br /> - you can&#039;t just use regular variables to do synchronization &amp; locking<br /> - BUT YOU DON&#039;T WANT TO DO THIS<br /> <br /> You want a mutithreaded-friendly architecture, not mechanisms<br /> - otherwise, uncontrolled parallelism actually leads to slower code<br /> - or it will be buggy<br /> <br /> Godot is very smart about multithreading<br /> https://godotengine.org/article/why-does-godot-use-servers-and-rids<br /> <br /> <br /> Basically, servers are how you run a thread<br /> - a server has a particular set of functionality<br /> <br /> Servers interact via messages<br /> <br /> Shared data is possible, but it has a clear thread (server) owner, and is shared<br /> via special references (RIDs), where, I think, access is by default read only<br /> <br /> Note that you don&#039;t have to think about multithreaded code in Godot most of the time, but you should be aware<br /> - don&#039;t expect variables to be instantly shared across nodes<br /> - instead, use messages (signals) to communicate changes in state<br /> &lt;/pre&gt;</div>

Soma