Open aaronfranke opened 2 years ago
I have an ongoing 4.0 port of the 3D Global Illumination demo: https://github.com/Calinou/godot-demo-projects/tree/add-global-illumination-demo-2-4.0
Edit: Pull request opened: https://github.com/godotengine/godot-demo-projects/pull/718
I have fixed the Pause demo with pull request #701 And I checked the Autoload(Singletons) demo in pull request #702 I hope I'm helping in finishing off all these tasks. I'm pretty now to contributing so please tell me when I'm doing things wrong!
Edit: Had some more time so decided to fix the Translation demo as well with pull request #704 The Control Gallery Demo also got fixed/adjusted so the layout is correct again with previous version. This is done in pull request #705
@Calinou I wonder if it makes sense to discuss here what to do with the Godot4 c# demo examples. Should there be discussions among Godot4 mono users or we wait until Godot4 dotnet6 is merged into the master?
@voylin Do you do Godot4 c#? Thank you for volunteering.
@GeorgeS2019 Porting C# demos will have to wait until the .NET 6 work is merged in master
. Until this happens, the API is too unstable for porting to be worth it.
@GeorgeS2019 That's a good point, I added a new emoji to this tracker to reflect this status β.
I've been trying to get some of the demo's fixed but 2D Lights as Mask and 2D Lights and Shadows are not possible yet. There are some rendering issues with light2D which make the demo's not work.
I've been trying to get some of the demo's fixed but 2D Lights as Mask and 2D Lights and Shadows are not possible yet. There are some rendering issues with light2D which make the demo's not work.
Indeed, see https://github.com/godotengine/godot/issues/55806.
I just tested the voxel game and it seems to work without problems (no debugger errors nor anything seemingly wrong rendering wise) on alpha 7
@voylin Do you do Godot4 c#? Thank you for volunteering.
@GeorgeS2019 Sorry for the late reply, hadn't seen the message. I am willing to test the c# stuff as well, but we will have to wait until the beta I guess. Like Calinou said, .NET 6 stuff should first be merged.
2D Physics Test demo is having a bug which is occurring because of find_children. Issue godotengine/godot#54939 has to be solved first. That demo should also have the tilemap icon as one of the tests uses the Tilemap.
I just tested the voxel game and it seems to work without problems (no debugger errors nor anything seemingly wrong rendering wise) on alpha 7
@alex9099 The voxel demo still has some rendering bugs. @aaronfranke worked on this demo in #694 But when testing it I found rendering issues especially when breaking blocks in the flat space, not all the faces on the sides don't get updated. This demo will probably need to wait until the beta releases before it can be checked of the list.
All these need to be rechecked with Godot 4 beta or newer. Probably most of them are broken again now.
Tried Bullet Shower(tagged β
) on master build and got: Line 59:Function "update()" not found in base self.
Built-in 3to4 Converter didn't help either.
I'm going through the 4.0-dev
demos to update them as we speak.
This one-liner (run in the repository root) makes it easy to go through all demos in the editor one-by-one:
for demo in **/*.godot; do godot $demo; done
Multiplayer Pong: Ported to godot 4 beta 5 -> https://github.com/godotengine/godot-demo-projects/pull/792
I have noticed that simply opening and running the demo projects on Godot 4.0b10 causes diffs in some scenes. It can be simple stuff like certain attributes have changed place or bigger stuff like removed attributes. Should these changes be committed as we find them or is there a plan to go through and commit all these scene-diffs caused by Godot 4.0 at one time later on?
I have noticed that simply opening and running the demo projects on Godot 4.0b10 causes diffs in some scenes. It can be simple stuff like certain attributes have changed place or bigger stuff like removed attributes. Should these changes be committed as we find them or is there a plan to go through and commit all these scene-diffs caused by Godot 4.0 at one time later on?
I think we can do this once 4.0 gets closer to release, as some bug fixes may still cause changes to occur in scene files.
I tried to run Platformer 2D and it failed immediately due to API change in Game.gd. I could fix the pure script errors but the project is buggy after that (incorrect behavior). I suppose it's worth doing a first PR just for the scripting error fixing, but since I haven't forked the repo yet I'll just drop my notes here for now:
OS.window_fullscreen = not OS.window_fullscreen
becomes
toggle_fullscreen()
where the function is defined as:
func toggle_fullscreen():
if DisplayServer.window_get_mode() not in \
[DisplayServer.WINDOW_MODE_FULLSCREEN, DisplayServer.WINDOW_MODE_EXCLUSIVE_FULLSCREEN]:
DisplayServer.window_set_mode(DisplayServer.WINDOW_MODE_FULLSCREEN)
else:
DisplayServer.window_set_mode(DisplayServer.WINDOW_MODE_WINDOWED)
get_tree().set_input_as_handled()
becomes
get_viewport().set_input_as_handled()
However, I noticed that both are mentioned in https://github.com/godotengine/godot/blob/master/editor/project_converter_3_to_4.cpp (with the subtlety that fullscreen has two variants and the converter only cares about exclusive fullscreen, so user would need a bit of manual work after the auto-conversion to get the exact behavior they want), which is itself used by command godot4 --convert-3to4
.
I suspect that because only the gist converted script https://gist.github.com/aaronfranke/79b424226475d277d0035b7835b09c5f was run, the newest changes in project_converter_3_to_4.cpp have not been taken into account. So before I start forking the project and converting things manually, maybe we should try to run the latest --convert-3to4 on the projects that still need it to see how far we can automatically update things?
I think this is also a good idea to spot what --convert-3to4 can do and what it can't, and for anything that it didn't convert, we should decide if: a. the missed conversion is simple enough to be integrated into project_converter_3_to_4.cpp b. the missed conversion requires human interaction to decide subtle edge case and wanted behavior, in which case it should be added to some migration guide (like https://gist.github.com/WolfgangSenff/168cb0cbd486c8c9cd507f232165b976 but I think this one is unofficial, so we could do the same with an official one; on a personal note, this gist receives a lot of comments and seems to be a good basis to work from)
At the end, we would have a compilation of all the manual things we did to upgrade the demo projects that would contribute to this migration guide.
@hsandt You are welcome to convert with any of these means, and submit any improvements you'd like to the converter. Just make sure that the final PR you submit has been hand-checked to have only good changes.
For 2D demos using the tilemap:
In Platformer 2D, I noticed this tilemap break:
due to Rendering Texture Origin being by default (0, 0) which means centered, causing tiles with Texture Region Size not matching TileSet Tile Size to have a representative area (with orange borders inside the green rectangle) to be misaligned.
I'm gonna fix the Texture Origin to some value so that the orange box matches the top of the tile, but it would be easier with some Texture Origin anchor direction I think (an enum with values: Center (current), Top-left, Top-middle, Top-right, Middle-left, Middle-right, Bottom-left, Bottom-middle, Bottom-right).
Or maybe the better way of doing this is to just split the big 32x64 tile into two parts of 32x32? I'm doing this in this in my own project (and also using auto-tile even with slopes, see https://github.com/godotengine/godot-proposals/discussions/6157).
For now I'll just fix the offset for minimal change, but I'd like to know the purpose of the demo to know better how I should use Godot 4's new features. Basically, are we demonstrating the tilemap too and trying to do things nicely in this demo, or are we just demonstrationg platforming, leaving TileSet demonstration to some other future TileMap demo?
I opened a new branch for Demo Platformer 2D porting: https://github.com/hsandt/godot-demo-projects/tree/4.0-dev-platformer
I will send a PR when I get something decent to play. Unless you prefer that I regularly send small PR as long as there is some visible improvement?
For now I'll just fix the offset for minimal change, but I'd like to know the purpose of the demo to know better how I should use Godot 4's new features. Basically, are we demonstrating the tilemap too and trying to do things nicely in this demo, or are we just demonstrationg platforming, leaving TileSet demonstration to some other future TileMap demo?
I'd say the demo should mostly be about platforming. Correct TileSet configuration is nice, but not essential for this kind of demo. Eventually, we should have a separate demo showcasing procedural 2D level generation with TileSets + TileMaps (most likely with a top-down/three-quarter view).
I opened a new branch for Demo Platformer 2D porting: hsandt/godot-demo-projects@
4.0-dev-platformer
I will send a PR when I get something decent to play. Unless you prefer that I regularly send small PR as long as there is some visible improvement?
You could open a draft PR now, or wait later and open a full PR directly. I personally prefer opening a draft PR as soon as I have something workable, so someone else can continue the work in case I no longer have time to complete it.
Maybe a good idea to remove the visual scripting ones as the folder has already been deleted from the branch and the visual scripting has been removed from the engine in 4.0
Will this script be updated again once 4.0 is released? I will have some spare time at the end of this month and would be able to go over some of these projects to see if I can check/fix the demo projects for 4.0, would be helpful to see here which ones aren't finished yet.(probably quite some work to keep this list up to date but just asking to check)
You could open a draft PR now, or wait later and open a full PR directly. I personally prefer opening a draft PR as soon as I have something workable, so someone else can continue the work in case I no longer have time to complete it.
Here you go. BTW should I prefix all my commits with [4.0] instead of [3to4] ? I changed convention between my commits and my PR title (maybe it doesn't matter if you squash the whole thing, but it will if you preserve the full commit history).
If you have trouble with the camera being too zoomed out in your demo, mind that the Zoom factor convention has been reversed: it now zooms in when the value increases, zooms out when the value decreases. So you have to reverse the value: in the case of 2D platformer, I changed (0.5, 0.5) -> (2.0, 2.0).
Godot 3 demo
Godot 4 demo before change
Godot 4 demo after change
Still wrong offset, but proper zoom
EDIT: offset is now fixed, it was a bad local change to position that kept restoring even after git revert + Reload scene in Godot. I should probably report this as an editor bug, in fact.
EDIT: OK, I just found out it was in the offical guide: https://docs.godotengine.org/en/latest/tutorials/migrating/upgrading_to_godot_4.html
I'll make sure to read the rest, it could help me a lot on other features to upgrade.
OLD remark below:
I suppose it could be added to --convert-3to4, but since the property name is not changing, it is particularly difficult to decide what to do, unless you are certain that you are actually converting a Godot 3 project. Basically, since the change is about reversing values, it is not idempotent, so you cannot use --convert-3to4 multiple times, guaranteeing no further changes.
I suppose we could add an option --force-convert-3to4 or something that will convert values this way (maybe only if project is actually using Godot 3; this won't work for people who started converting their project with an older version of the converter, unfortunately).
Or we could just show a warning when Camera zoom values != (1, 1) are detected (in scene or in script; in script, we could even add a comment above).
But if it's too complicated, we could add this to some upgrading guides so developer can just do it manually. For now I'll just comment on the two unofficial guides I know (https://gist.github.com/WolfgangSenff/168cb0cbd486c8c9cd507f232165b976 and https://www.reddit.com/r/godot/comments/tsxgnj/migrating_from_3x_to_40/).
3D/MaterialTesters with 4.0 RC6 on my computer give me this:
importing assets (_sandrough.jpg) stuck Γ 94%, CPU is 100% use (the decrease in CPU graph comes from a change of affinity from all to only 2/8 cores), then I decide to kill Godot.
Trying to reimport it directly from project list makes Godot stuck at "park.hdr" 0%, still 100% CPU usage, then finally project is loaded after several minutes:
I don't call this working actually.
For the record, it's on an Asus G750 JH with a core i7 and a GeForce GTX 780M, I know it's far from being the best available these day, still it's not yet a low-end computer. (tool used is System Informer)
Trying to reimport it directly from project list makes Godot stuck at "park.hdr" 0%, still 100% CPU usage, then finally project is loaded after several minutes:
This could be due to https://github.com/godotengine/godot/issues/61948. That said, all *.hdr.import
files in the demo already have compress/mode=0
, which indicates they're using lossless compression and not VRAM compression. This can be seen in the Import dock:
I've tried removing the .godot/
folder then reimporting the demo locally, it successfully imports in less than 10 seconds with 4.0.rc 8208060c2. Are you using a self-compiled editor build? If so, make sure it was built with optimizations.
I don't call this working actually.
I have to remind you that we have a Code of Conduct. Please stay constructive.
I've checked all the import settings after the project is reopened in the editor, all are using VRAM compression, including HDR backgrounds, except one.
Only _sandshine.jpg texture use lossless mode, it's 1024x1024 RGB8 texture, no mipmap using ~3MB memory, I don't believe it could be responsible for the import delay alone. And I don't know also if settings has been somehow modified automatically by the editor as I did not change anything not delete the .godot folder inside the project.
By the way, opening the project again is as quick as it is expected. And to answer your question, no, I'm using official 64bits build (v4.0.rc6.official [0cd148313]).
I've done more testing on RC6 build:
platformer 3D failed (it looks like there is a regression), I just run the project, then I get this error right away, with a sounds looping while the debugger is running:
physicsTest (3D) also have at least one case of failure:
with tests/functional tests/collision pairs using collider type "capsule" and shape type "capsule":
To reproduce the error, run the project, select the test "functional tests/collision pairs", select "test options" menu, click on "collider type" "capsule (3)" then "shape type" capsule checkbox => error occurred. (it's happened for pretty much every choices, I use box, sphere, convex/concave polygon) In fact, selecting the second option trigger the issue.
and there are a lot's of errors:
So, how do we publish the demos already ported to Godot 4.0, now that it's out? I'm thinking in particular about 2D platformer which recently reached a decent state thanks to https://github.com/godotengine/godot-demo-projects/pull/851
Only sand_shine.jpg texture use lossless mode, it's 1024x1024 RGB8 texture, no mipmap using ~3MB memory, I don't believe it could be responsible for the import delay alone. And I don't know also if settings has been somehow modified automatically by the editor as I did not change anything not delete the .godot folder inside the project.
That texture isn't used anywhere in the project. It could be removed at this point: https://github.com/godotengine/godot-demo-projects/pull/869
Platformer3D still fail with the same error (see my previous report above) with latest stable release (v4.0.stable.official [92bee43ad]).
Platformer3D still fail with the same error (see my previous report above) with latest stable release (v4.0.stable.official [92bee43ad]).
The Platformer 3D demo needs updating to account for recent breaking changes in AnimationTree: https://github.com/godotengine/godot/pulls?q=is%3Apr+sort%3Aupdated-desc+transition_request+is%3Aclosed
Note that merely changing /current
to /transition_request
isn't enough, as it'll break the jumping animation and cause an error to be spammed every frame.
The Platformer 3D demo needs updating to account for recent breaking changes in AnimationTree: https://github.com/godotengine/godot/pulls?q=is%3Apr+sort%3Aupdated-desc+transition_request+is%3Aclosed
Note that merely changing
/current
to/transition_request
isn't enough, as it'll break the jumping animation and cause an error to be spammed every frame.
ok thanks. The first post by @aaronfranke need to be updated accordingly as it shows the demo is fully working with zero issue (check mark + checkbox checked).
I guess we have too check all demos again on the stable release.
Thanks for the reminder @InfiniteProductions. I have reset the tracker to have all boxes unchecked to ensure we re-check everything. Contributors such as @Calinou, please re-check anything that's known to be working.
I have started to check demos with latest 4 release, @aaronfranke I've sent you some emails (on the address of your github profile) don't know if you've received them, anyway, this is a cleaner file with all test results I've got so far, with no filtering to let you decide if a demo is ok or not by the expected standards.
The Audio Generator Demo seems broken in Godot 4.0. The buffer fills, but does not seem to delete as it plays. The audio generator makes a boop, but then won't accept any more frames. Any help would be much appreciated.
@jgalbertus you may need to be more specific.
Tested with v4.0.1.stable.official [cacf49999] on Windows, frame count increase and decrease as tone is played, I just add some print statement with _tofill value.
Hey :) What would be the best way to help? The list at the top is still completely blank. How is the process of porting projects to G4? Just open a PR? Where will the G3 versions of the demos live? Sorry if this has been answered or planned somewhere and I just ask the obvious questions...
@RPicster the status has been reset a few weeks ago by @aaronfranke, I've tested again a bunch of demos with various 4.0 release along the way, there was quite a rush on releases and I couldn't catch up and redo all tests for every releases as it should be done, I've fill a file with all the results and status I've got, see my reply above from 3 weeks ago.
If you find an issue and/or have a fix, do not hesitate to fill a PR. You could also test the demos I didn't test or test those which have been checked first again with the last release. I just report editor message from import and runtime warning/error + if it's work or not.
It looks like releases process is slowing down, it would leave us time to test all 89 or so on the very last release if there are enough people to test I guess.
@InfiniteProductions Ok! Thanks for getting back to me. Now how is support for the 3.x demos planned? 3.x is still LTS, so the demos should not be hidden in some branch or old commit from my pov. Would it make sense to handle them in separate repos?
You're welcome.
I've no idea about the support for 3.x demos.
3.x is still LTS, so the demos should not be hidden in some branch or old commit from my pov. Would it make sense to handle them in separate repos?
Branches are not hiding places, there is no point making a separate repository whereas branches are just the right way to handle this case. You can switch to any branch any time.
There's are 3.x
and 3.5
branches now. While we recommend focusing on the master
branch, you can still create new demos for the 3.x
branch, and we can cherry-pick changes compatible with 3.5.x to the 3.5
branch.
Continuous 4.0.x releases is making demos never reach any stability.
Waiting for Godot 4
has become Waiting for Godot 4 Demos
.
Demos aren't few ranks behind Godot. They are few laps behind.
Lack of minimalistic but ready demos for things like 'websocket-minimal' is really make it hard for Devs understand how to use them or understand the new changes. Porting manually becomes harder too.
One drastic idea I can think off is temporary halting Godot's new 2-week release cycle and finishing as much demo upgrades as possible. And resume normal cycle once the demos are in passable state. Then, they can then be improved over time slowly. Making we can even set aside some time for it once every quarter/semester/year for demo-upgrade.
BTW, I am not saying there isn't progress or trying to be rude but maybe we need find a different way than current. Just like above Release-Break idea.
Maybe we need to arrange the demo list from least complex to most complex first.
@Anutrix
Godot is a community effort, FIRST, organize what is basic and missing in Godot4 and raise awareness in the community to get someone making it works in Godot4.
If you are not coding, keep hammering to make others to make the demo(s) happen.
@Anutrix
Maybe we need to arrange the demo list from least complex to most complex first.
If you have an idea to share. => Do it so the Godot management can choose your idea and integrate it.
One drastic idea I can think off is temporary halting Godot's new 2-week release cycle and finishing as much demo upgrades as possible. And resume normal cycle once the demos are in passable state. Then, they can then be improved over time slowly. Making we can even set aside some time for it once every quarter/semester/year for demo-upgrade.
This is exactly what I did back in January 2023 :slightly_smiling_face:
The list in OP is outdated βΒ a lot of demos could be checked as working in 4.0.2, but they need to be tested first. Also, please review pull requests and test them locally.
I believe some coordination would be more than welcome in order to made progress all together without stepping on each other foot :). Maybe take charge of some testing (5, 10, or more demos) on a given version & architecture, report then have a regularly updated post like the tracker, but maybe something every willing participant can update via pull requests.
Issues could be created and assigned to people, but maybe it would need another project just for that, it may worth it although.
@Anutrix I used to be on top of things, but I no longer have an abundance of free time like I used to, so I can't work on the demos. Someone needs to step up and actually do the work. It could be you, or someone you know. Or you could raise awareness on community channels.
There are a lot of people on places Discord that say they want to contribute, and then tell them that Godot needs people to contribute to the demos, but so far nobody has stepped up to actually do the work. I have even offered to pay people money to work on the demos and still nobody has stepped up.
One thing that stops me from updating official demos is what amount of changes is okay and what counts as stable. Do I need to it to be running in all 3 rendering drivers. Is running with few warnings are fine?. Should I test with .NET version of Godot too?, etc. I still don't know the answer to some of these questions.
I think many contributors gets discouraged because they don't know what should be basic tests/requirements when they make demo fixes or upgrades. In order words, 'Is my changes for 'Official Demos' good enough?'.
It's much harder than making changes in https://github.com/godotengine/godot code. There we just need fix the bug and check for stability before starting with draft MR.
Here, just opening a file will make changes. For example, on just opening websocket_chat
in Godot 4.0.2, we see this diff:
$ git diff
diff --git a/networking/websocket_chat/project.godot b/networking/websocket_chat/project.godot
index 68cd0394..44581c17 100644
--- a/networking/websocket_chat/project.godot
+++ b/networking/websocket_chat/project.godot
@@ -8,22 +8,6 @@
config_version=5
-_global_script_classes=[{
-"base": "Node",
-"class": &"WebSocketClient",
-"language": &"GDScript",
-"path": "res://websocket/WebSocketClient.gd"
-}, {
-"base": "Node",
-"class": &"WebSocketServer",
-"language": &"GDScript",
-"path": "res://websocket/WebSocketServer.gd"
-}]
-_global_script_class_icons={
-"WebSocketClient": "",
-"WebSocketServer": ""
-}
-
[application]
config/name="WebSocket Chat Demo"
This scares me as a contributor. Some FAQs in Official Docs saying 'Minor changes in project.godot when opening the project is expected' would be encouraging.
Btw. I was looking for demo guidelines. Do we have any guidelines, FAQs or similar page for 'Contributing to Godot Demo Projects'? The reason my first contribution to a public open-source project was Godot Engine was because of its amazing 'https://docs.godotengine.org/en/latest/contributing/ways_to_contribute.html' section. It even helped me contribute to non-godot public projects.
Can we have something something similar for the Godot Demo Projects
? We can start with a simple FAQ page too.
Lastly, I'm interested in getting websocket demos working. I will make an MR if and when I succeed. It will most probably be rough but I guess it can be fixed on first review by maintainer. If all goes well, I will try making more MRs.
This issue tracks the progress of porting the Godot demo projects to Godot 4.0. This list is in alphabetical order by folder path.
β and a checked box means that the demo is fully ported and working.
π§ means that the demo still needs to be ported manually.
π means that there are engine (not project) bugs that show up in this project. Projects that have bugs but the cause is unknown don't get π.
π means that there are minor bugs such as errors printing in the console.
π means that there is a bug with rendering (possibly a problem with the project).
π means that there is a bug with scripting (can be GDScript/C#/VisualScript).
π½ means that this project uses TileMap. 3.x tile data doesn't work in master.
π₯ means that opening the editor with this project causes the engine to crash.
[x] β Bullet Shower
[x] β Dodge the Creeps
[x] β Hierarchical Finite State Machine
[x] β GD Paint
[x] β HDR for 2D (renamed to Glow in 2D due to https://github.com/godotengine/godot/issues/54122)
[x] β Hexagonal Game
[x] β Scene Instancing Demo
[x] β Isometric Game
[x] β Kinematic Character 2D
[x] β 2D Lights as Mask
[x] β 2D Lights and Shadows
[x] β Navigation Polygon 2D https://github.com/godotengine/godot-demo-projects/pull/955
[x] β Grid-based Pathfinding with Astar
[x] β 2D Particles
[x] β Physics-Based Platformer 2D
[x] β 2D Physics Tests https://github.com/godotengine/godot-demo-projects/pull/962
[x] β Platformer 2D
[x] β Pong with GDScript
[x] β JRPG Demo https://github.com/godotengine/godot-demo-projects/pull/922
[x] β Screen Space Shaders
[x] β Skeleton2D Demo
[x] β 2D Shaders for Sprites
[x] β Tween Demo
[x] β 3D Global Illumination
[ ] π 3D Inverse Kinematics
[x] β Kinematic Character 3D
[x] β Material Testers
[x] β 3D Navigation Mesh
[x] β 3D Physics Tests
[x] β Platformer 3D
[x] β RigidBody Character 3D
[x] β Truck Town
[x] β Volumetric Fog
[x] β Voxel Game https://github.com/godotengine/godot-demo-projects/pull/965
[x] β 3D Waypoints
[x] β BPM Sync Demo
[x] β Audio Device Changer Demo
[x] β Audio Generator Demo
[x] β Audio Mic Record Demo
[x] β Audio MIDI Piano Demo
[x] β Audio Spectrum Demo
[x] β BIDI and Font Features
[x] β Control Gallery
[x] β Drag and Drop (GUI)
[x] β Input Mapping GUI https://github.com/godotengine/godot-demo-projects/pull/1024
[x] β Multiple Resolutions
[x] β Pseudolocalization Demo (should use
canvas_items
stretch mode)[x] β RegEx (Regular Expressions)
[x] β Rich Text Label with BBCode
[x] β Signed Distance Field Font (renamed to Multi-channel Signed Distance Field font) https://github.com/godotengine/godot-demo-projects/pull/1024
[x] β GUI Theming Override Demo
[x] β Translation Demo
https://github.com/godotengine/godot-demo-projects/pull/930https://github.com/godotengine/godot-demo-projects/pull/1024[ ] π§ UI Mirroring Demo https://github.com/godotengine/godot-demo-projects/pull/974
[x] β Autoload (Singletons)
[x] β Background Thread Loading Demo
[x] β Multiple threads loading
[x] β Scene Changer
[x] β Saving and Loading (Serialization)
[x] β Loading in a Thread
[x] β 2.5D Demo with GDScript
[x] β Joypads Demo
[x] β Matrix Transform https://github.com/godotengine/godot-demo-projects/pull/978
[x] β OpenSimplexNoise Viewer (renamed to Noise Viewer as 4.0 uses FastNoiseLite)
[x] β Operating System Testing
[x] β Pause Demo https://github.com/godotengine/godot-demo-projects/pull/1024
[x] β Window Management
[x] β Android In-App Purchases https://github.com/godotengine/godot-demo-projects/pull/1024
[x] β Interactive Cubes
[x] β Multitouch View
[x] β Accelerometer, Magnetometer and Gyro Demo
[ ] π§ 2.5D Demo with C#
[x] β Android in-app purchases with C# https://github.com/godotengine/godot-demo-projects/pull/1104
[ ] π§ Dodge the Creeps with C# https://github.com/godotengine/godot-demo-projects/pull/1000
[ ] π§ Pong Multiplayer with C#
[x] β Pong with C# https://github.com/godotengine/godot-demo-projects/pull/966
[x] β Multiplayer Bomber https://github.com/godotengine/godot-demo-projects/pull/987
[x] β Pong Multiplayer
[ ] π§ WebRTC Minimal Connection
[ ] π§ WebRTC Signaling Example
[x] β WebSocket Chat Demo
[x] β WebSocket Minimal Demo
[x] β WebSocket Multiplayer Demo
[x] β Plugin Demos https://github.com/godotengine/godot-demo-projects/pull/1024
[x] β 2D in 3D Demo
[x] β 3D in 2D Demo
[x] β 3D Viewport Scaling https://github.com/godotengine/godot-demo-projects/pull/891
[x] β Dynamic Split Screen
[x] β GUI in 3D Demo
[x] β Screen Capture