We've made several updates to improve our codebase and application performance.
- Clang format was applied for better readability and consistency, aiding other developers in understanding and contributing to the code.
- We resolved issues that were causing visual script compilation failure. The visual script now compiles successfully, ensuring application functionality.
- Broken sections within the codebase were fixed, improving overall stability.
- Built-in functions from the visual script were removed to simplify the code and enhance readability.
- Generic search performance was improved to provide faster results, enhancing user experience.
- Missing flow nodes were added to the Visual Script, ensuring all necessary components are present for correct functioning.
In an effort to streamline the codebase:
- `VisualScriptComment` class and related code were removed, reducing complexity and improving maintainability.
- Error messages were optimized for quicker feedback when errors occur.
- Licenses were updated to reflect recent changes, ensuring legal compliance and project transparency.
- The `get_global_name()` override in `visual_script.h` was fixed, and `TYPE_BUILTIN_FUNC` in `visual_script_expression.h` was removed, improving code functionality.
- Search logic was refactored to avoid double searching, enhancing performance.
- Documentation was updated to reflect recent changes, providing accurate information to users and developers.
- Property selection logic in `VisualScriptPropertySelector` was refactored for easier understanding and modification.
- Code was refactored to avoid variable shadowing, improving readability and reducing potential errors.
- `.clang-format` and `.clang-tidy` configuration files were added to ensure consistent code styling.
To make the code more robust and easier to understand:
- Variable names were corrected for clarity, and error handling in `visual_script_expression.cpp` was improved.
- Function and variable names were refactored for better readability and maintainability.
- Member editing logic in `VisualScriptEditor` was simplified.
- Name variables were updated to be unique, avoiding potential conflicts and errors.
- The `VisualScriptSubCall` class was refactored for simplicity and ease of understanding.
For macOS workflow:
- It was updated to use the latest version and correct path for installing Vulkan SDK, enabling the application to leverage the latest features and improvements from the Vulkan SDK.
- Mac Vulkan SDK was installed to support Vulkan-based functionalities.
Lastly, we made necessary changes to pass CI/CD tests, ensuring the code quality and stability of the application.
Implement built-in classes Vector4, Vector4i and Projection.
* Two versions of Vector4 (float and integer).
* A Projection class, which is a 4x4 matrix specialized in projection types.
These types have been requested for a long time, but given they were very corner case they were not added before.
Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity.
**Q**: Why Projection and not Matrix4?
**A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
- Add support for explicit values in properties using `PROPERTY_HINT_FLAGS`
that works the same way it does for enums.
- Fix enums and flags in VisualScriptEditor (it wasn't considering the
explicit value).
- Use `PROPERTY_HINT_FLAGS` for C# enums with the FlagsAttribute instead
of `PROPERTY_HINT_ENUM`.
* Map is unnecessary and inefficient in almost every case.
* Replaced by the new HashMap.
* Renamed Map to RBMap and Set to RBSet for cases that still make sense
(order matters) but use is discouraged.
There were very few cases where replacing by HashMap was undesired because
keeping the key order was intended.
I tried to keep those (as RBMap) as much as possible, but might have missed
some. Review appreciated!
Adds a new, cleaned up, HashMap implementation.
* Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing).
* Keeps elements in a double linked list for simpler, ordered, iteration.
* Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much
for performance vs keeping the key, but helps replace old code).
* Uses a more modern C++ iterator API, deprecates the old one.
* Supports custom allocator (in case there is a wish to use a paged one).
This class aims to unify all the associative template usage and replace it by this one:
* Map<> (whereas key order does not matter, which is 99% of cases)
* HashMap<>
* OrderedHashMap<>
* OAHashMap<>
These typedefs don't save much typing compared to the full `Ref<Resource>`
and `Ref<RefCounted>`, yet they sometimes introduce confusion among
new contributors.
Constructors are more accessible.
Basic type methods are now based on ClassDB and not registerd_node_names.
Selecting search_classes now automatically changes the scope.
* Very old macros from the time Godot was created.
* Limited arguments to 5 (then later changed to 8) in many places.
* They were replaced by C++11 Variadic Templates.
* Renamed methods that take argument pointers to have a "p" suffix. This was used in some places and not in others, so made it standard.
* Also added a dereference check for Variant*. Helped catch a couple of bugs.
This reverts commit 48a1cb7c96.
As discussed in #57725 and clarified in #57788, `SNAME` is not meant to be used
everywhere but only in critical code paths. For theme methods specifically, it
was by design that only getters use `SNAME` and not setters.
