Since I'm at it. I'm going to write a brief history of how video game music playback happened on consoles on the technical side. This is a topic I love and you' ll see this is quite fascinating!

So, how did this start? (thread 🧵👇). 8 bit systems just had square (also called pulse) waves. This was just a simple oscillator moving dc from - to +. Some hw had quirks (envelopes, analog filters, basic dac, etc), Maybe tri, noise (for perc) or saw wave, but that was it..

Did you know? The original version of Godot (before it was open sourced) used the Squirrel programming language. ()..
What happened with it? Where did it go? Read on below.. (🧵👇) squirrel-lang.org
Squirrel is very similar to the Lua programming language () but it has some fundamental differences:
- Friendlier C style syntax
- Class support
- No GC
- Easier to bind

I much prefer it over Lua, myself, but It never got much traction..lua.org

Did you know? Common knowledge says that normal maps can be in OpenGL or DirectX format, and that different game engines/DCCs support different normal map formats.. but this is not quite true and more on the myth side.
Want to know why? Read below! (🧵👇). In truth, shader code in all game engines look more or less the same for processing the normalmap. A tangent basis is generated using normal/tangent/binormal and the normal map is just multiplied by it.
Notice, nothing is "negated" or flipped. It's a 3x3 matrix mult everywhere..

One of the things that makes me the the most proud in Godot 4 is also the least visible of them all: The engine foundation.

Godot 4 has now by far one of the best (if not the best) foundations you can find in a game engine... (thread blow🧵👇) This enormous amount of work took part from 2018 to 2022, the time it took Godot 4 to be made. The whole engine core was in large part redone, helping fix a tremendous amount of bottlenecks/design dead ends, while still keeping the foundation relatively simple..

Implemented an occlusion aware trilinear voxel filter in HDDAGI. This makes the reflections look a lot more believable (it looks like a low quality video version of the scene). This also has significant advantages quality wise... 🧵👇 First, this removes a lot of high frequency information from the scene, reducing the rays needed to converge (noise). But also, one of the devil's hidden in the details in HDDAGI is that every voxel _already_ has the full GI information in real-time, which is computed cheaply..

Ever wondered where the general design of Godot comes from? (all is nodes, even scenes are nodes).
Ariel and I were tech leads in several companies, and tech consultants for many, many others.
We worked with several game engines, our own, other's in-house or commercial ones..🧵👇 After working with almost a dozen projects, there is one thing we started to notice in all of them:

Developers will tend to fight the game engine and work around it.

Time and time again, we saw a client's project, we saw a hard struggle against the engine..

The best piece of advise I can give to those moving from Unity to Godot is: You have to imagine Godot "Scene Tree" as "A tree of components without entities". This has two quirks:

- Its much cleaner to understand scenes at a glance
- Composition is far more flexible.

Thread🧵 You don't need multiple scripts per node for behaviors, add more child nodes with scripts.
Also, prefabs or scene composition as a concept do not exist. You can simply instantiate or inherit any scene anywhere else. You can also make the instance editable and do local changes..

Want to understand in depth why the Unity debacle and why it is critical that FOSS becomes the de facto business model for the game industry?

Please make sure to read on!🧵.. To begin, you have to understand what is the "whole product" concept is:

There are many variations of it, but the main idea is as follows..en.wikipedia.org/wiki/Whole_pro…

While on the topic of switching software. I started doing 3D modelling far before most artists today. In 1994, I learned 3D Studio 2.0 and even back then I used this to make videogames. I was very comfortable with 3D Studio, but in the late 90s I moved to Linux..🧵 Of course, while working on Linux was a blast for me as a programmer, doing 3D on it was super hard. There were some FOSS projects at the time but nothing came close to 3D Studio. Until Blender came out..

I made this graphic to explain how I see in my mind the difference between proprietary and FOSS innovation.
FOSS is everywhere and relies on the collective intelligence, while proprietary can focus investment better and advance faster in specific areas.. but.. 🧵 While it seems proprietary innovation has an edge, FOSS can also catch up very fast, so proprietary software innovations often have a limited window to profit until FOSS alternatives appear and displace them. Unless they keep innovating and reinventing themselves, of course..

Letting aside that a lot of developers felt (rightfully) offended with this meme, I think few people realize why this change happened or what is behind this. In my opinion the following are the reasons why the industry came to be like this: 🧵

https://twitter.com/ozols_aldis/status/1654430539397599237

1. The main event that changed everything was the rise of digital marketplaces. Before them, if you wanted to publish (or even get investment for) a game, you had to go through a complex process of lobbying for publishers with retail access. That strong gatekeeping is gone now..

This is probably a good example of how Godot is just designed different to most other game engines. In most existing engines, if you want to start taking advantage of multiple cores to optimize your game logic, you have basically two choices: 🧵

https://twitter.com/reduzio/status/1650158232009097221

The first one is to use Jobs. Jobs is basically using threads yourself but sugar-coated with things like dependencies. It is still a very low level solution, requires large rewrite, and does not solve most of the thread-related problems such as race conditions, IPC..

With @godotengine my feeling is that it succeeds by being written backwards to most of the literature you can find on game engine topics. Due to this, it is of little interest to most seasoned engine programmers, it attracts a different kind of developers instead..🧵 If you read on how to make a game engine, you will actually find very precise material:
- ECS
- Data Oriented
- GPU driven rendering
- Render Graphs
- Complex memory management
- etc.
But this is not how development is done in Godot..

One of the most demanded features in Godot is terrain support, so I want to clear some misunderstandings regarding its future availability on the engine.

If you are interested in this being supported in Godot, read this thread! 🧵 Unlike other features provided built-in, terrain is _very_ high level. More often than not because its not just terrain alone. You want to be able to draw foliage, complex materials, water, manage object instancing, LOD strategies, non heightmap geometry, trigger logic, etc..

Article attempts to make it clear, but just in case:
Godot is NOT aiming to become an AAA engine.
It aims to be an Indie/AA engine that is be easy to use and has graphics as beautiful as any other commercial engine..
Does this mean it can't be eventually used for AAA? 🧵

https://twitter.com/godotengine/status/1615052594640031750

No. AAA engines are either custom engines made from the ground up, or commercial engines that are massively changed to fit a incredibly large game and team.
Even most AAA titles made with Unreal (if not all) do very significant modifications to it..

A weak point in the upcoming Godot 4 (where many users have issues with) is physics, where we had to revert to work further on Godot Physics (our own) and drop Bullet. Many suggested Jolt, but this won't cut it either. I think it was never entirely clear why we have to do this.. Reasons are very technical and, ultimately, are because Godot is a _very_ general purpose game engine where users do all sorts of things. As such, it needs extremely precise collisions to not run into corner cases. Bullet and Jolt use approximations that will not always work..

One notable thing that happened in Godot 4 development cycle is all the backlash we got due to removing the "xxx_degrees" properties (which will come back btw). A lot of users were disconcerted by this, but it was all a big misunderstanding, resulting from an early mistake..🧵 Godot always did all the mathematics in radians, because this is the standard in pretty much all technology. Math functions read and write radians, so exposing properties in degrees would be counter productive.
Of course, for _editing_ rotation values, degrees is always easier..

Since I see this asked a lot, I will try my best to explain why the upcoming @godotengine foundation can't offer Console ports. There is a lot of detail I can't say because it requires signing NDAs with the console manufacturers, but trying my best in this 🧵. 1) License incompatibility: Even if we now have our own entity and we could theoretically register as console developers, there is a license incompatibility that makes it impossible to publish the source code of console ports into GitHub and integrate it with the rest of Godot.

I've recently heard from a couple of developers that some publishers are wary of taking in games made with Godot.

While this odd stance is changing for the better (there were multiple commercially successful games made with Godot the past two years, with known publishers).. 🧵 I think it's fair to understand a bit better what the publisher business model is, so developers can be a bit more wary and understanding.
I will try to give some of my experience with this on this thread (published many games for mobile/desktop/console using Godot in the past):

This is obviously Godot 4.1 material, but on the rendering side, we are contemplating having the following options towards the future, which makes more sense given the Godot user base: 1) A "compatibility" renderer, similar to a mix between GLES2 and GLES3 in Godot. Features/performance more similar to GLES2 but running on GLES3. This will run in very old phones, and PCs > 2005 (DX10 level). This is currently a work in progress by @john_clayjohn..

Have you ever heard:

"FOSS Project X is doing great, but can't compete with the monetary resources commercial company Y is pouring into their commercial product"

Even if it sounds like common sense, this is a big fallacy.

Why is this? Will try to explain in 🧵. While its true that a company may have more resources committed, there are fundamental differences that tilt the scale in favor of a FOSS project that is doing well. I will proceed to list them: