Client interpolation pump is moved AFTER the physics tick, after physics objects have been moved.
This is necessary because the `current` transform is also updated during the pump.
No actual functionality yet
Actual subtween functionality implemented
Added documentation for Tween.tween_subtween and SubtweenTweener
Implemented some additional functions
`set_ease`, `set_trans`, and `set_delay`
Documentation only for `set_delay` so far, since I have tested it
Removed set_ease and set_trans
Upon further investigation, the way they are implemented for Tween doesn't appear to work here
Fixed indentation in documentation
Reset subtween when parent loops
Fix return type of `SubtweenTweener.set_delay`
Add notes to documentation
Apply suggestions from code review
Co-authored-by: Tomasz Chabora <kobewi4e@gmail.com>
Apply some suggested changes
- Remove excessive documentation
- Add Tween constructor that takes in SceneTree
- Make `SubtweenTweener::subtween` public so that `Tween` doesn't have to be a friend class
Remove unneeded friend class SceneTree
Remove superfluous documentation describing subtween behavior
Apply suggestions from code review
Co-authored-by: Tomasz Chabora <kobewi4e@gmail.com>
Apply suggestions from code review
Co-authored-by: Thaddeus Crews <repiteo@outlook.com>
Apply suggestions from code review
Co-authored-by: A Thousand Ships <96648715+AThousandShips@users.noreply.github.com>
Early return from `tween_subtween` if the subtween is `null`
- Tweak property hint ranges for some networking settings to ensure
the minimum values don't break the debugger entirely.
- Ensure shader time rollover is set to at least 1, as 0 causes a division by
zero to occur.
All relevant project settings are now covered by a range hint.
Adds 3D fixed timestep interpolation to the rendering server.
This does not yet include support for multimeshes or particles.
Co-authored-by: lawnjelly <lawnjelly@gmail.com>
Adds fixed timestep interpolation to the rendering server (2D only).
Switchable on and off with a project setting (default is off).
Co-authored-by: lawnjelly <lawnjelly@gmail.com>
This small in-engine documentation change aims to make it easier to
discover ways to handle pixel art aesthetics.
- I have moved 2D pixel snapping settings out of "Advanced." This now matches other pixel-art-friendly settings for
GUI Snapping and Default Texture filtering.
- I've added notes to the project settings and Sprite/AnimatedSprite sources to hint users towards better understanding of why pixelated sprites may not work correctly and what to do about it. This should help users make informed decisions for their needs.
Context: Proper handling of pixel art in Godot is routinely frustrating for new users: I, like others, assumed that Godot would act on pixels, not subpixels, when I was working a pixel art game. I was confused when my interpolations would appear blurry, and when pixel textures would be distorted for no apparent reason (this was because of centering).
I had naively thought that setting Linear interpolation would be the single "it's a pixel art game" toggle, but that only hid the underlying issues until later. I had no idea there was a snap-to-pixel option because it was hidden in the Advanced options, since my default assumption was that a pixel art game would want no subpixels at all.
Some references for the frustration:
- https://github.com/godotengine/godot/issues/82696
- https://www.reddit.com/r/godot/comments/fah25e/best_way_to_achieve_pixel_perfect_rendering/
- https://shaggydev.com/2021/09/21/project-setup-for-pixel-art/
Previously the `p_reversed` parameter didn't influence the order
in a correct way.
Also script overridden _notification functions were not called in
the correct order.
To fix this some `notification` functions had to add a `p_reversed`
parameter.
This made it necessary to adjust cpp-bindings.
Co-authored-by: David Snopek <dsnopek@gmail.com>
This is needed to allow 2D to fully make use of 3D effects (e.g. glow), and can be used to substantially improve quality of 2D rendering at the cost of performance
Additionally, the 2D rendering pipeline is done in linear space (we skip linear_to_srgb conversion in 3D tonemapping) so the entire Viewport can be kept linear.
This is necessary for proper HDR screen support in the future.
