9 ms·

Godot 3's renderer design

261 points by uyoakaoma 9y ago

ognyankulev 9y ago
While scrolling fast through the long document, my eyes immediately focused on "Wait, why not Vulkan or DirectX12?" :-D tl;dr "At the end of the day, the use case where Vulkan and DirectX12 make the most sense is when you have hundreds of thousands of objects, which are all different (different geometry, textures, etc.), and which move. This is a difficult use case to achieve, even willingly."
- wlesieutre 9y ago
  The paragraph above that is relevant as well. Vulkan is only on Linux and Windows, DX12 is on Windows, Metal is on Mac and iOS. They'd have to have multiple renderers written for different APIs to cover all the platforms that they support.
  - slezyr 9y ago
    > Vulkan is only on Linux and Windows And android. I.e. everything but Mac OS, iOS.
    - EddieRingle 9y ago
      Plus you can get Vulkan on macOS with MoltenVK.
      - wlesieutre 9y ago
        I've seen that before, and while it's technically true it's also 100% useless for an open source engine.
        microcolonel 9y ago
        It may be open sourced in the future, there are stakeholders who might be willing to pay for this to happen (Google, for example, might want it for their iOS and Apple deployments).
        earenndil 9y ago
        Eh, google doesn't really need it. They don't make anything that requires high performance and cross-platform, they don't make games, and chrome is only for android so they don't need to be able to run it on ios.
        microcolonel 9y ago
        Chrome runs on OS X, where GL is deteriorating; they also have Maps and Earth on iOS.
    - pjmlp 9y ago
      On Android it is optional for 7+ devices, currently about 13% of market share. It is not available on Sony and Microsoft consoles, UWP apps. On the Nintendo Switch there is NVAPI, which provides even more low level control.
  - pjmlp 9y ago
    On Windows Vulkan is only available to desktop apps.
  - phire 9y ago
    The one problem with that plan, is apple have mostly stopped improving their OpenGL driver in favor of Metal.
    - microcolonel 9y ago
      Yeah, this really gets my goat. These days MoltenGL and MoltenVK are getting more popular. Good on the Molten* folks for making these layers, but I have a feeling they won't be used very widely unless they're basically free to license. Maybe somebody (Google?) will come around and buy them outright. Even worse, Apple's GL drivers never performed very well to begin with. Their intel drivers have been much slower than Mesa for more than half a decade, and supported fewer (super useful) extensions for about two years.
      - kvark 9y ago
        Molten folks would be happy to be open sourced as long as a sufficient gratification bonus is included. Also, Vulkan Portability initiative is relevant here - https://www.khronos.org/blog/khronos-announces-the-vulkan-portability-initiative https://www.khronos.org/blog/khronos-announces-the-vulkan-po...
      - pjmlp 9y ago
        All major engines already support Metal, or are in the process of finalizing it. Middleware makes the actual APIs kind of irrelevant. Also there is no OpenGL or Vulkan on majority of game consoles. Even on Switch, Nintendo still has their own API with much more lowere level control than Vulkan, just in case.
        kevingadd 9y ago
        This is simply not true. To begin with, the shader languages and bytecode formats are different across OpenGL and Direct3D. Consoles tend to have their own shader pipeline as well. Even if you have great abstractions in your middleware, the capabilities actually provided by the system differ, and you have to consider this. APIs and drivers remain extremely relevant, middleware or not. FWIW the PS3 (among others) actually offered OpenGL, not that you'd want to use it (the implementation was pretty bad - Apple-quality). You can also theoretically run OpenGL code on the PS4 or XBox One if you want to, since they use well-understood AMD GPUs. Fail0verflow has already booted real OpenGL on hacked PS4s (via Mesa, I believe). You can also run OpenGL on some platforms by using ANGLE to emulate specific versions of OpenGL on top of other APIs. So, ultimately the "there is no OpenGL or Vulkan" observation isn't that meaningful - if your codebase is built around OpenGL, that's not necessarily a problem at all. I don't know if I'd bother, but I'd also put money on it being possible to run ANGLE or Mesa GL on top of the PS4 graphics stack (I'm familiar with it).
  - floatboth 9y ago
    > Vulkan is only on Linux and Windows Also on FreeBSD :) https://github.com/myfreeweb/freebsd-ports-dank#mesa-with-vulkan https://github.com/myfreeweb/freebsd-ports-dank#mesa-with-vu...
- mattnewport 9y ago
  It's not necessarily the wrong choice for their use case but this explanation is a little misleading. Vulkan and DirectX 12 were designed to reduce the overhead of draw calls and to enable multithreaded dispatch. That makes it feasible to render more objects with more state changes but the efficiency benefits still apply (in theory) when rendering fewer objects, particularly on a multi core CPU. Wasting less CPU on rendering API overhead is always a good thing - if you don't use the efficiency gains to render more stuff you can use the spare CPU for something else like better physics. Both APIs are harder to use however and it's quite possible to end up less efficient than older APIs by using them badly plus current implementations can be poor, especially on mobile, so there are still good reasons not to use them.
  - deleted 9y ago
    [deleted]
- microcolonel 9y ago
  > While scrolling fast through the long document, my eyes immediately focused on "Wait, why not Vulkan or DirectX12?" :-D Well, I don't think it's architected in any way that would prevent the adoption of lower level APIs; but Godot's main markets are mobile, embedded, and web where OpenGL ES 3.0 is a low (but not the lowest) common denominator.
  - cma 9y ago
    Vulkan should help with mobile battery life though.
    - kevingadd 9y ago
      This is a false assumption. Existing GL drivers do a lot of hard work to compensate for platform-specific (or even chip-specific) quirks and limitations. If you're building on top of Vulkan or D3D12 you potentially don't get that assistance (due to the lower-level nature of the API), and you'll have to deal with a lot of that nonsense yourself. Android apps like Firefox or Dolphin already have a bunch of one-off workarounds for shader compiler bugs, etc. It's worse without a smart driver. On the other hand, the SPIR-V system used for shaders in Vulkan routes around a significant portion of bad shader compilers, so that's nice :) If you have a Vulkan app that's not tuned for your specific device, your battery life (and framerates) could easily end up worse. Vulkan and D3D12 shine in the hands of a company like EA or Ubisoft, and it's no coincidence that the Mantle spec (a precursor to Vulkan and D3D12) was basically completely designed by DICE, the developers of EA's Frostbite engine.
      - microcolonel 9y ago
        > This is a false assumption. Existing GL drivers do a lot of hard work to compensate for platform-specific (or even chip-specific) quirks and limitations. While it may be possible for GL stacks to do this, real mobile and embedded GL stacks tend to barely function at all. I highly doubt they do much more than try to extract maximum straight line performance for synthetic benchmarks within their budget. The reason Vulkan can have an outsize effect on power consumption is that it can allow renderer work to be spread across several threads. Running two cores at 60% the clock rate will typically cost considerably less power than running one at a higher frequency. This is an explicit (and accomplished) goal of mobile vendors in supporting Vulkan.
- kvark 9y ago
  Same here. While I do see a place for previous-gen graphics engines out there for the nearest time being, the provided justification does not sound too convincing. Vulkan/DX12/Metal make more sense in many ways, not just to draw thousands of different objects. For one, they allow explicit control on the memory transfers and synchronization, which leads to less performance hitches and and spikes, more predictable and stable framerate.
  - planteen 9y ago
    What's not convincing about their argument about Vulkan not being supported on mobile? In my experience with embedded systems, that is true. They even discuss working with OGLES2 where OGLES3 is unavailable. Even within OGLES3, I have seen a mix of 3.0, 3.1, and very rarely 3.2 support. "Added to that fact, Vulkan still has years to go until it's properly supported in most desktop and mobile platforms, which makes it unattractive to implement for us (as it means considerably more effort to write, debug and maintain). As for DirectX12, it's only relevant for Windows/UWP, so there is no strong incentive for us to support it as a cross-platform engine."
    - kvark 9y ago
      Sure, it's not that much available on mobile, but where it is - the benefits of a next-gen API are greater than on desktop (since you have more weaker CPU cores and stricter latency requirements). I'm not arguing to drop OGLES, not at all. DirectX12 is also relevant on XB1, where you get not many other alternatives. Would be nice to see Godot titles running on consoles, eventually.
- Mikeb85 9y ago
  Yup. By using only OpenGLES 3.0 and equivalent OpenGL, they achieve maximum compatibility while having nice enough visuals as well as good enough performance. Pragmatic decision, no point trying to compete with Unreal Engine in the visual department. That being said, people are achieving some really nice visuals in Godot 3.0 using the PBR shader and new renderer...
willvarfar 9y ago
I'm really looking forward to the proper release of Godot 3! Want to use it to get my kids into game writing, but have been holding off because Godot 2 has a custom scripting language which will be going away and I don't want to invest in that. Any idea when 3.0 ships?
- pier25 9y ago
  Their custom scripting language is the main reason for not choosing Godot. I didn't know they were replacing it in v3. Any idea what are they going to use?
  - speps 9y ago
    https://godotengine.org/article/godot-getting-more-languages https://godotengine.org/article/godot-getting-more-languages However, compared to parent: > GDScript will always be the main supported language, and our recommended choice for all Godot users. > To clarify things: since the Mono runtime is relatively heavy, and many Godot users will prefer to stick to GDScript, we intend to provide the Mono-enabled version of Godot as a separate download. They're also adding their version of visual scripting...
  - amarsahinovic 9y ago
    GDScript will not be replaced in 3.0 but they will add support for other languages, like C#. Personally, I find GDScript quite OK since you can treat it just like Python, and I think there are some interfaces that enable you to use real Python in Godot (check out their blog).
    - thehardsphere 9y ago
      Do you know how the performance of GDScript execution compares to something like Python embedded in an engine where the more costly operations are run in compiled C or C++ code? Or even how the real Python performance in Godot compares to the GDScript performance? I tried to find this out, but the one "benchmark" I found was somewhat dubious. The Godot documentation claims that GDScript has all sorts of advantages over using other scripting languages that sound qualitatively superior, but it lacks quantitative comparisons.
ravirajx7 9y ago
Someone who wish to learn about developing game and its theory can get started here. http://gameprogrammingpatterns.com/contents.html http://gameprogrammingpatterns.com/contents.html
- rootlocus 9y ago
  While I agree this is a wonderful resources, it is much less about game development than it is about design patterns. Basically, it's a gamedev flavored book about design patterns. A much better books about game development would be Game Coding Complete [0]. [0] https://www.amazon.com/Game-Coding-Complete-Fourth-McShaffry/dp/1133776574 https://www.amazon.com/Game-Coding-Complete-Fourth-McShaffry...
pjmlp 9y ago
Very interesting reading. I like specially the architecture decision of a separate render process.
mentos 9y ago
Researching Godot's multiplayer support it looks like there is not anything very comprehensive? In a separate discussion, will we ever see any sort of UDP support in the browser for client/server games? https://gafferongames.com/post/why_cant_i_send_udp_packets_from_a_browser/ https://gafferongames.com/post/why_cant_i_send_udp_packets_f...
- TeddyDD 9y ago
  Not sure if this is what you are looking for but there is high level networking API coming in Godot 3.0 http://docs.godotengine.org/en/latest/learning/features/networking/high_level_multiplayer.html http://docs.godotengine.org/en/latest/learning/features/netw...
- stcredzero 9y ago
  I have UDP semantics for my game, which has a Javascript front end and Golang servers: (Though I use node-electron processes as a WebRTC proxy.) https://news.ycombinator.com/item?id=15334726 https://news.ycombinator.com/item?id=15334726 https://news.ycombinator.com/item?id=15332187 https://news.ycombinator.com/item?id=15332187
  - mentos 9y ago
    Reading the article I linked in my first post, my understanding is that it is possible to use WebRTC for UDP _today_ but its just very difficult? "while WebRTC makes it easy to send unreliable-unordered data from one browser to another, it falls down when data needs to be sent between a browser and a dedicated server...It falls down because WebRTC is extremely complex. This complexity is understandable, being designed primarily to support peer-to-peer communication between browsers, WebRTC needs STUN, ICE and TURN support for NAT traversal and packet forwarding in the worst case." Given your experience with WebRTC stcredzero, do you think it is possible to wrap WebRTC in a class to emulate UDP? What is the hold up?
    - 3648 9y ago
      It takes some time to develop and existing implementations aren't very mature yet, e.g., https://github.com/xhs/librtcdc https://github.com/xhs/librtcdc and https://github.com/chadnickbok/librtcdcpp https://github.com/chadnickbok/librtcdcpp
microcolonel 9y ago
Here's an archive link since you probably won't be able to see the article from the original location. http://archive.is/lvKV9 http://archive.is/lvKV9
auserperson 9y ago
Still waiting... Sorry, every Godot post will have that joke.

261 points by uyoakaoma 9y ago

While scrolling fast through the long document, my eyes immediately focused on "Wait, why not Vulkan or DirectX12?" :-D tl;dr "At the end of the day, the use case where Vulkan and DirectX12 make the most sense is when you have hundreds of thousands of objects, which are all different (different geometry, textures, etc.), and which move. This is a difficult use case to achieve, even willingly."

wlesieutre 9y ago
The paragraph above that is relevant as well. Vulkan is only on Linux and Windows, DX12 is on Windows, Metal is on Mac and iOS. They'd have to have multiple renderers written for different APIs to cover all the platforms that they support.
- slezyr 9y ago
  > Vulkan is only on Linux and Windows And android. I.e. everything but Mac OS, iOS.
  - EddieRingle 9y ago
    Plus you can get Vulkan on macOS with MoltenVK.
    - wlesieutre 9y ago
      I've seen that before, and while it's technically true it's also 100% useless for an open source engine.
      - microcolonel 9y ago
        It may be open sourced in the future, there are stakeholders who might be willing to pay for this to happen (Google, for example, might want it for their iOS and Apple deployments).
        earenndil 9y ago
        Eh, google doesn't really need it. They don't make anything that requires high performance and cross-platform, they don't make games, and chrome is only for android so they don't need to be able to run it on ios.
        microcolonel 9y ago
        Chrome runs on OS X, where GL is deteriorating; they also have Maps and Earth on iOS.
  - pjmlp 9y ago
    On Android it is optional for 7+ devices, currently about 13% of market share. It is not available on Sony and Microsoft consoles, UWP apps. On the Nintendo Switch there is NVAPI, which provides even more low level control.
- pjmlp 9y ago
  On Windows Vulkan is only available to desktop apps.
- phire 9y ago
  The one problem with that plan, is apple have mostly stopped improving their OpenGL driver in favor of Metal.
  - microcolonel 9y ago
    Yeah, this really gets my goat. These days MoltenGL and MoltenVK are getting more popular. Good on the Molten* folks for making these layers, but I have a feeling they won't be used very widely unless they're basically free to license. Maybe somebody (Google?) will come around and buy them outright. Even worse, Apple's GL drivers never performed very well to begin with. Their intel drivers have been much slower than Mesa for more than half a decade, and supported fewer (super useful) extensions for about two years.
    - kvark 9y ago
      Molten folks would be happy to be open sourced as long as a sufficient gratification bonus is included. Also, Vulkan Portability initiative is relevant here - https://www.khronos.org/blog/khronos-announces-the-vulkan-portability-initiative https://www.khronos.org/blog/khronos-announces-the-vulkan-po...
    - pjmlp 9y ago
      All major engines already support Metal, or are in the process of finalizing it. Middleware makes the actual APIs kind of irrelevant. Also there is no OpenGL or Vulkan on majority of game consoles. Even on Switch, Nintendo still has their own API with much more lowere level control than Vulkan, just in case.
      - kevingadd 9y ago
        This is simply not true. To begin with, the shader languages and bytecode formats are different across OpenGL and Direct3D. Consoles tend to have their own shader pipeline as well. Even if you have great abstractions in your middleware, the capabilities actually provided by the system differ, and you have to consider this. APIs and drivers remain extremely relevant, middleware or not. FWIW the PS3 (among others) actually offered OpenGL, not that you'd want to use it (the implementation was pretty bad - Apple-quality). You can also theoretically run OpenGL code on the PS4 or XBox One if you want to, since they use well-understood AMD GPUs. Fail0verflow has already booted real OpenGL on hacked PS4s (via Mesa, I believe). You can also run OpenGL on some platforms by using ANGLE to emulate specific versions of OpenGL on top of other APIs. So, ultimately the "there is no OpenGL or Vulkan" observation isn't that meaningful - if your codebase is built around OpenGL, that's not necessarily a problem at all. I don't know if I'd bother, but I'd also put money on it being possible to run ANGLE or Mesa GL on top of the PS4 graphics stack (I'm familiar with it).
- floatboth 9y ago
  > Vulkan is only on Linux and Windows Also on FreeBSD :) https://github.com/myfreeweb/freebsd-ports-dank#mesa-with-vulkan https://github.com/myfreeweb/freebsd-ports-dank#mesa-with-vu...
mattnewport 9y ago
It's not necessarily the wrong choice for their use case but this explanation is a little misleading. Vulkan and DirectX 12 were designed to reduce the overhead of draw calls and to enable multithreaded dispatch. That makes it feasible to render more objects with more state changes but the efficiency benefits still apply (in theory) when rendering fewer objects, particularly on a multi core CPU. Wasting less CPU on rendering API overhead is always a good thing - if you don't use the efficiency gains to render more stuff you can use the spare CPU for something else like better physics. Both APIs are harder to use however and it's quite possible to end up less efficient than older APIs by using them badly plus current implementations can be poor, especially on mobile, so there are still good reasons not to use them.
- deleted 9y ago
  [deleted]
microcolonel 9y ago
> While scrolling fast through the long document, my eyes immediately focused on "Wait, why not Vulkan or DirectX12?" :-D Well, I don't think it's architected in any way that would prevent the adoption of lower level APIs; but Godot's main markets are mobile, embedded, and web where OpenGL ES 3.0 is a low (but not the lowest) common denominator.
- cma 9y ago
  Vulkan should help with mobile battery life though.
  - kevingadd 9y ago
    This is a false assumption. Existing GL drivers do a lot of hard work to compensate for platform-specific (or even chip-specific) quirks and limitations. If you're building on top of Vulkan or D3D12 you potentially don't get that assistance (due to the lower-level nature of the API), and you'll have to deal with a lot of that nonsense yourself. Android apps like Firefox or Dolphin already have a bunch of one-off workarounds for shader compiler bugs, etc. It's worse without a smart driver. On the other hand, the SPIR-V system used for shaders in Vulkan routes around a significant portion of bad shader compilers, so that's nice :) If you have a Vulkan app that's not tuned for your specific device, your battery life (and framerates) could easily end up worse. Vulkan and D3D12 shine in the hands of a company like EA or Ubisoft, and it's no coincidence that the Mantle spec (a precursor to Vulkan and D3D12) was basically completely designed by DICE, the developers of EA's Frostbite engine.
    - microcolonel 9y ago
      > This is a false assumption. Existing GL drivers do a lot of hard work to compensate for platform-specific (or even chip-specific) quirks and limitations. While it may be possible for GL stacks to do this, real mobile and embedded GL stacks tend to barely function at all. I highly doubt they do much more than try to extract maximum straight line performance for synthetic benchmarks within their budget. The reason Vulkan can have an outsize effect on power consumption is that it can allow renderer work to be spread across several threads. Running two cores at 60% the clock rate will typically cost considerably less power than running one at a higher frequency. This is an explicit (and accomplished) goal of mobile vendors in supporting Vulkan.
kvark 9y ago
Same here. While I do see a place for previous-gen graphics engines out there for the nearest time being, the provided justification does not sound too convincing. Vulkan/DX12/Metal make more sense in many ways, not just to draw thousands of different objects. For one, they allow explicit control on the memory transfers and synchronization, which leads to less performance hitches and and spikes, more predictable and stable framerate.
- planteen 9y ago
  What's not convincing about their argument about Vulkan not being supported on mobile? In my experience with embedded systems, that is true. They even discuss working with OGLES2 where OGLES3 is unavailable. Even within OGLES3, I have seen a mix of 3.0, 3.1, and very rarely 3.2 support. "Added to that fact, Vulkan still has years to go until it's properly supported in most desktop and mobile platforms, which makes it unattractive to implement for us (as it means considerably more effort to write, debug and maintain). As for DirectX12, it's only relevant for Windows/UWP, so there is no strong incentive for us to support it as a cross-platform engine."
  - kvark 9y ago
    Sure, it's not that much available on mobile, but where it is - the benefits of a next-gen API are greater than on desktop (since you have more weaker CPU cores and stricter latency requirements). I'm not arguing to drop OGLES, not at all. DirectX12 is also relevant on XB1, where you get not many other alternatives. Would be nice to see Godot titles running on consoles, eventually.
Mikeb85 9y ago
Yup. By using only OpenGLES 3.0 and equivalent OpenGL, they achieve maximum compatibility while having nice enough visuals as well as good enough performance. Pragmatic decision, no point trying to compete with Unreal Engine in the visual department. That being said, people are achieving some really nice visuals in Godot 3.0 using the PBR shader and new renderer...

willvarfar 9y ago

I'm really looking forward to the proper release of Godot 3! Want to use it to get my kids into game writing, but have been holding off because Godot 2 has a custom scripting language which will be going away and I don't want to invest in that. Any idea when 3.0 ships?

pier25 9y ago
Their custom scripting language is the main reason for not choosing Godot. I didn't know they were replacing it in v3. Any idea what are they going to use?
- speps 9y ago
  https://godotengine.org/article/godot-getting-more-languages https://godotengine.org/article/godot-getting-more-languages However, compared to parent: > GDScript will always be the main supported language, and our recommended choice for all Godot users. > To clarify things: since the Mono runtime is relatively heavy, and many Godot users will prefer to stick to GDScript, we intend to provide the Mono-enabled version of Godot as a separate download. They're also adding their version of visual scripting...
- amarsahinovic 9y ago
  GDScript will not be replaced in 3.0 but they will add support for other languages, like C#. Personally, I find GDScript quite OK since you can treat it just like Python, and I think there are some interfaces that enable you to use real Python in Godot (check out their blog).
  - thehardsphere 9y ago
    Do you know how the performance of GDScript execution compares to something like Python embedded in an engine where the more costly operations are run in compiled C or C++ code? Or even how the real Python performance in Godot compares to the GDScript performance? I tried to find this out, but the one "benchmark" I found was somewhat dubious. The Godot documentation claims that GDScript has all sorts of advantages over using other scripting languages that sound qualitatively superior, but it lacks quantitative comparisons.

ravirajx7 9y ago

Someone who wish to learn about developing game and its theory can get started here. http://gameprogrammingpatterns.com/contents.html http://gameprogrammingpatterns.com/contents.html

rootlocus 9y ago
While I agree this is a wonderful resources, it is much less about game development than it is about design patterns. Basically, it's a gamedev flavored book about design patterns. A much better books about game development would be Game Coding Complete [0]. [0] https://www.amazon.com/Game-Coding-Complete-Fourth-McShaffry/dp/1133776574 https://www.amazon.com/Game-Coding-Complete-Fourth-McShaffry...

pjmlp 9y ago

Very interesting reading. I like specially the architecture decision of a separate render process.

mentos 9y ago

Researching Godot's multiplayer support it looks like there is not anything very comprehensive? In a separate discussion, will we ever see any sort of UDP support in the browser for client/server games? https://gafferongames.com/post/why_cant_i_send_udp_packets_from_a_browser/ https://gafferongames.com/post/why_cant_i_send_udp_packets_f...

TeddyDD 9y ago
Not sure if this is what you are looking for but there is high level networking API coming in Godot 3.0 http://docs.godotengine.org/en/latest/learning/features/networking/high_level_multiplayer.html http://docs.godotengine.org/en/latest/learning/features/netw...
stcredzero 9y ago
I have UDP semantics for my game, which has a Javascript front end and Golang servers: (Though I use node-electron processes as a WebRTC proxy.) https://news.ycombinator.com/item?id=15334726 https://news.ycombinator.com/item?id=15334726 https://news.ycombinator.com/item?id=15332187 https://news.ycombinator.com/item?id=15332187
- mentos 9y ago
  Reading the article I linked in my first post, my understanding is that it is possible to use WebRTC for UDP _today_ but its just very difficult? "while WebRTC makes it easy to send unreliable-unordered data from one browser to another, it falls down when data needs to be sent between a browser and a dedicated server...It falls down because WebRTC is extremely complex. This complexity is understandable, being designed primarily to support peer-to-peer communication between browsers, WebRTC needs STUN, ICE and TURN support for NAT traversal and packet forwarding in the worst case." Given your experience with WebRTC stcredzero, do you think it is possible to wrap WebRTC in a class to emulate UDP? What is the hold up?
  - 3648 9y ago
    It takes some time to develop and existing implementations aren't very mature yet, e.g., https://github.com/xhs/librtcdc https://github.com/xhs/librtcdc and https://github.com/chadnickbok/librtcdcpp https://github.com/chadnickbok/librtcdcpp

microcolonel 9y ago

Here's an archive link since you probably won't be able to see the article from the original location. http://archive.is/lvKV9 http://archive.is/lvKV9

auserperson 9y ago

Still waiting... Sorry, every Godot post will have that joke.