Age | Commit message (Collapse) | Author |
|
This makes documentation for the Performance class 100% complete.
|
|
|
|
This makes it easier to spot syntax errors when editing the
class reference. The schema is referenced locally so validation
can still work offline.
Each class XML's schema conformance is also checked on GitHub Actions.
|
|
|
|
For the time being we don't support writing a description for those, preferring
having all details in the method's description.
Using self-closing tags saves half the lines, and prevents contributors from
thinking that they should write the argument or return documentation there.
|
|
* Fixed and redone the process to obtain render information from a viewport
* Some stats, such as material changes are too difficult to guess on Vulkan, were removed.
* Separated visible and shadow stats, which causes confusion.
* Texture, buffer and general video memory can be queried now.
* Fixed the performance metrics too.
|
|
|
|
|
|
Includes:
* MarginContainer
* NavigationPolygon
* Node
* NodePath
* OS
* PackedByteArray
* PackedScene
* PacketPeerUDP
* PCKPacker
* Performance
* PhysicsShapeQueryParameters2D
* PhysicsShapeQueryParameters3D
* PrimitiveMesh
* ProjectSettings
Co-authored-by: Aaron Franke <arnfranke@yahoo.com>
|
|
Monitor
Custom monitors can be added/removed/checked using `Performance.add_custom_monitor`/`Performance.remove_custom_monitor`/`Performance.has_custom_monitor`
The value can be viewed in the `Monitor` tab of Debugger.
Text before `/` is used to categorize the custom monitor.
`EditorPerformanceProfiler` class is created to separate logic from `ScriptEditorDebugger`
User can click on the graph of monitors to read the value at that point.
Graph includes intermediate base lines.
|
|
A few extra renames for classes which were missed in last week's PRs.
|
|
Handle removal of Pool*Array types and other recent changes.
|
|
Due to the port to Vulkan and complete redesign of the rendering backend,
the `drivers/gles3` code is no longer usable in this state and is not
planned to be ported to the new architecture.
The GLES2 backend is kept (while still disabled and non-working) as it
will eventually be ported to serve as the low-end renderer for Godot 4.0.
Some GLES3 features might be selectively ported to the updated GLES2
backend if there's a need for them, and extensions we can use for that.
So long, OpenGL driver bugs!
|
|
|
|
We already removed it from the online docs with #35132.
Currently it can only be "Built-In Types" (Variant types) or "Core"
(everything else), which is of limited use.
We might also want to consider dropping it from `ClassDB` altogether
in Godot 4.0.
|
|
- Document a few more properties and methods
- Add more information to many classes
- Fix lots of typos and gramar mistakes
- Use [code] tags for parameters consistently
- Use [b] and [i] tags consistently
- Put "Warning:" and "Note:" on their own line to be more visible,
and make them always bold
- Tweak formatting in code examples to be more readable
- Use double quotes consistently
- Add more links to third-party technologies
|
|
All 100% completed: MainLoop, Node, Object, Path, Performance,
Reference, Resource, SceneState, SceneTree, UndoRedo.
Also fixed some en_GB occurrences as the reference spelling is en_US.
|
|
Fixed plugin bindings.
|
|
Add a monitor for the orphan nodes
|
|
|
|
- Allow the user to keep track of the nodes that might leak
- Possible fix for #27103
|
|
|
|
Fix various missing arguments in bindings.
|
|
It has no practical use case and just generates noise for each alpha, beta, etc.
|
|
|
|
Also enhance RigidBody docs as per https://github.com/godotengine/godot-docs/pull/1018
and fix the version tag in all files (not really stable yet, but it makes no sense
to hardcode rc3 at this stage).
|
|
|
|
|
|
|
|
It is now "3.0-alpha" instead of "3.0.alpha.custom_build{,.mono}",
limits unnecessary diffs.
|
|
Also fix hyperlink references to same class as per the guidelines.
[ci skip]
|
|
Ensure that s/fixed_process/physics_process/ is handled properly.
[ci skip]
|
|
|
|
possible to save module files in module directories and the build system will
recognize them.
|