https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Game_Engines_2021W_Lecture_7 2026-04-08T03:21:11Z 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_7&diff=22903&oldid=prev 2021-02-02T17:11:07Z

<p>Created page with &quot;==Resources== * [http://beagle.applearchives.com/the_posters/poster_1.html Beagle Bros quick reference poster] (with Apple II memory map) * [https://en.wikipedia.org/wiki/IRI...&quot;</p> <p><b>New page</b></p><div>==Resources==<br /> <br /> * [http://beagle.applearchives.com/the_posters/poster_1.html Beagle Bros quick reference poster] (with Apple II memory map)<br /> * [https://en.wikipedia.org/wiki/IRIS_GL SGI IRIS GL] (predecessor to OpenGL)<br /> * [http://www.sgistuff.net/funstuff/hollywood/jpark.html Jurassic Park and SGI]<br /> * Vulkan tutorial [https://vulkan-tutorial.com/Introduction introduction] and [https://vulkan-tutorial.com/Overview overview]<br /> * [https://en.wikipedia.org/wiki/Thinking_Machines_Corporation Thinking machines], maker of the CM-1, CM-2, and CM-5<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Show &amp; Tell<br /> https://shalinlathigra.itch.io/paul-cop-mall-blart<br /> https://github.com/ShalinLathigra/GlobalGameJam2021<br /> <br /> Timing issues<br /> https://github.com/godotengine/godot/issues/38981<br /> <br /> <br /> GPUs and graphics<br /> <br /> Where did it all start?<br /> <br /> Early systems had memory-mapped graphics<br /> - range of RAM that was mapped directly to the screen<br /> - change bits in this memory, screen would update<br /> - maybe have 2 ranges you could flip between<br /> - update one while changing the other<br /> (double buffering)<br /> <br /> - this meant that the CPU was involved in all graphics operations<br /> - all the math<br /> <br /> Apple II&#039;s had this sort of architecture, but other 8-bit CPUs were more capable<br /> <br /> Atari 400/800<br /> - had display lists: commands to tell what would be on the screen<br /> - had hardware sprites (player/missle graphics)<br /> <br /> Other early systems were simpler<br /> - old Mac&#039;s just had a &quot;blitter&quot; (fast memory copying)<br /> <br /> 2D accelerated graphics cards<br /> - fixed functions: draw shapes, basic textures, text<br /> - often had its own separate memory<br /> <br /> 3D graphics changed everything<br /> - need to create a model that the graphics card &quot;renders&quot;<br /> - 2D projection of 3D models<br /> - started with fixed function, but then evolved to be more general purpose<br /> <br /> This evolution in graphics has influenced graphics APIs<br /> <br /> OpenGL<br /> - open version of GL, which was developed by Silicon Graphics<br /> - hello world in OpenGL is relatively short, 5-10 lines to set up then<br /> you give your drawing commands<br /> <br /> Newer APIs are not this way, e.g. Vulkan<br /> - it takes A LOT of code to get anything working in Vulkan<br /> <br /> WHY?!<br /> <br /> With OpenGL, the driver manages the graphics card<br /> - you give commands on what to do, the driver figures out how to do it<br /> <br /> But with modern APIs like Vulkan, the application manages the card<br /> - well, manages a virtualization of it, so it can be shared between apps<br /> <br /> Big motivation is PARALLELISM<br /> - can&#039;t make sequential tasks faster simply by running on parallel hardware<br /> - instead, have to refactor to get benefit<br /> - different organizations will be efficient depending on the task<br /> - so, have to put in developer&#039;s hands<br /> <br /> With OpenGL, you have a sequential execution model<br /> - one thread/process talking to the GPU giving commands<br /> <br /> With Vulkan, parallel execution model<br /> - many threads talking to GPU at once, each giving their own commands<br /> <br /> But this means the app has to manage GPU cores and memory directly<br /> - driver just gives a basic abstraction for managing resources<br /> <br /> In other words, your app has to contain a GPU OS<br /> <br /> This is why you want to use a game engine to develop your games!<br /> - let it deal with the GPU for you<br /> <br /> Godot currently supports OpenGL in 3.x, but 4.x supports Vulkan<br /> - you can run it now, it just isn&#039;t stable or optimized<br /> <br /> Weird thing is GPUs got so powerful that people wanted to start running arbitrary code on them<br /> - GPGPU<br /> - i.e., do AI/ML or crypto mining on GPUs<br /> <br /> GPUs offer general functionality<br /> - but also have lots of graphics-specific bits<br /> <br /> I think eventually GPUs will just become parallel computation systems, and<br /> graphics part will be separated out<br /> - would allow for cleaner architectures<br /> - and more load sharing with CPU<br /> &lt;/pre&gt;</div>

Soma